GNOME Bugzilla – Bug 759188
Support clicking on items when enter is pressed in Firefox
Last modified: 2018-02-14 14:23:05 UTC
It would be nice if pressing Enter on clickable items triggered a click. For instance, The Syncthing web interface (http://syncthing.net) has a number of items that are clickable but that aren't marked up as links. That these *should* be links or buttons is without doubt, but unfortunately there is often a substantial gap between that which should be and that which is. :) NVDA does send clicks when the folder/server headings are focused and Enter is pressed, but I don't know if there is a difference in what Firefox exposes on Windows and Linux that might make this impossible. But this is definitely a behavior I'm sorely missing under Linux. I've tried flat review, but though I route the pointer to the headers and simulate a click, I can't seem to open these content areas. Thanks.
The problem with Orca taking over Enter include the following: 1. Should Orca synthesize a click or use the Action interface? If you think the former, there is already Orca's command to synthesize a mouse click. No routing is needed. And it works whether you're in flat review or not. (When it wasn't working, that was due to a bug in Firefox which has since been fixed in Firefox. And binding click synthesis to Enter would have just meant Orca was taking over an oft-used key and preventing it from doing anything.) If the latter, what if there are multiple actions? Which one should Orca choose? It might not even be able to reliably use the action name to know what the action did. 2. What if the page author has created a custom experience in which Enter does something specific to the content? Yes, Orca could only take over Enter if you are in browse mode. But what if the content is not really a web app and needs to be read in browse mode? Furthermore, if Orca changed the author's intended interaction, that author could report the change as an Orca bug. And I'd have to agree with them. Yes, I realize that NVDA does this. That is not my fault. <smiles> Because you can synthesize a click now that the Firefox bug is fixed, I prefer to not take over the Enter key so that Enter does what Enter will do for all users. Sorry!
(In reply to Joanmarie Diggs (IRC: joanie) from comment #1) > Yes, I realize that NVDA does this. That is not my fault. <smiles> > > Because you can synthesize a click now that the Firefox bug is fixed, I > prefer to not take over the Enter key so that Enter does what Enter will do > for all users. Sorry! Do you mean you will not accept patch if someone else code the function? It's really difficult for user to ask for clickable item and to choose the button, mostly if NVDA does the job. You should know that we don't teach flat review because most of users have capabilities to do complicated stuff. Maybe we could take the exact same behavior than NVDA does? Best regards.
I don't think taking over the Enter key is a good idea. It's not that I cannot code the functionality; it's that I don't think we should have that functionality. That said, Hypra could certainly maintain such functionality. Before too long, I hope to make these sorts of things more modular in which case doing so would be easier.
(In reply to Joanmarie Diggs (IRC: joanie) from comment #3) > I don't think taking over the Enter key is a good idea. It's not that I > cannot code the functionality; it's that I don't think we should have that > functionality. Maybe if you think it's not the Orca role, could it be possible to ask Firefox guys to make clickable elements activated with the keyboard? > That said, Hypra could certainly maintain such functionality. Before too > long, I hope to make these sorts of things more modular in which case doing > so would be easier. We don't think maintaining specific code for Hypra is a good idea. I assume we could discuss together to find a way to make the user experience as good as and as simple as possible. It's the meaning of my below proposal :). IMO, The current behavior is really complicated for the beginning user, I assume it's why the NVDA guys have take this decision. Best regards.
This resolution feels a bit odd to me. I acknowledge that, from an ideological perspective, implementing this may not make sense. As a screen reader user, though, I think it is fairly expected behavior. Further, NVDA and others clearly have an algorithm that works, and they aren't being overwhelmed by web app developers who suddenly care enough about accessibility to file bug reports against screen readers that their apps are broken, vs. just doing the work on their end to fix their access issues. IOW, if they care enough to track the issue down to a given screen reader's behavior, they'll have an easier time just making their apps behave well in the first place, obviating the need to blame you. :) Further, that mouse routing/clicking works in Firefox nightly is debatable. I'd argue that it has gotten better, but it certainly isn't fixed in all cases. I'm not trying to pit one screen reader against another, but if NVDA has an algorithm that works and isn't getting them overwhelmed with web developers who suddenly give a damn about accessibility, why would that happen to Orca? :) Thanks.
My guess about why NVDA did it was that JAWS did it. Furthermore, if you have a virtual buffer, then you're not in the web page. I assume that this also has something to do with why Windows screen readers do this. Orca doesn't have a virtual buffer. You're in the page you're reading. If you want to click on something with the mouse, Orca has a key for that. It just isn't Enter. On the other hand if you want to use Enter and have Enter work like it would for other users, then good news: Orca isn't taking over that key. For what it's worth, I understand the sentiment behind making the user experiences similar. But I don't think that should mean Orca must do everything that NVDA does for that reason. And I fundamentally disagree with this change. So what I can do is try to make it easier for people and downstreams to change this -- e.g. through moving some of this functionality to plugins.
I just noticed something which was said and want to be sure we're clear about something: (In reply to Alex ARNAUD from comment #2) > It's really difficult for user to ask for clickable item and to choose the > button, Huh? A user should be able to move to the thing (just like in NVDA) and press KP Slash, Orca's command to synthesize a click. You don't have to ask for a clickable item. You don't have to press any button. The only thing you have to do, if you really want to click on it, is press a single key (just like in NVDA). That key is, however, not Enter. With this in mind, is it really so difficult for users?
(In reply to Nolan Darilek from comment #5) > Further, that mouse routing/clicking works in Firefox nightly is debatable. > I'd argue that it has gotten better, but it certainly isn't fixed in all > cases. If you have specific test cases so I can reproduce and debug them, please email them to the mailing list. If there is in issue in the clicking code, I'd like to fix it.
I can certainly try, but they're usually in web apps with a certain amount of state (I.e. login required, on specific screens, etc.)
(In reply to Joanmarie Diggs (IRC: joanie) from comment #7) > I just noticed something which was said and want to be sure we're clear > about something: > > (In reply to Alex ARNAUD from comment #2) > > > It's really difficult for user to ask for clickable item and to choose the > > button, > > Huh? A user should be able to move to the thing (just like in NVDA) and > press KP Slash, Orca's command to synthesize a click. You don't have to ask > for a clickable item. You don't have to press any button. The only thing you > have to do, if you really want to click on it, is press a single key (just > like in NVDA). That key is, however, not Enter. Right point, It works since the recent changes about scroll text made by Samuel for Hypra and so the community. It's a little bit less user friendly than enter but it's acceptable indeed. Sorry for the misunderstanding. Best regards.