GNOME Bugzilla – Bug 654724
Orca doesn't read access keys on webpages using firefox
Last modified: 2011-12-14 11:37:27 UTC
This is a very old problem but still not fixed :-(. When navigating through webpages orca doesn't read accesskeys. I blind person can only use access keys on webpages if he/she knows these. Searching the mailinglist archives of orca showed that this issue was mentioned but nobody answered where the problem must be fixed. Maybe it's a firefox issue?
We cannot present access keys if we don't know what they are. Therefore I have opened a mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=672092 In the meantime, we get the access keys from WebKitGtk, so I'd like to go ahead an implement this functionality for Epiphany. Questions about the desired user interaction: 1. Should it be presented automatically and for all verbosity levels? 2. I'm assuming it would be presented after the object. But what string should be presented? In other words, if it's the foo link and the assigned accesskey is f and the browser requires pressing Alt+Shift along with the access key, which of the following should Orca say: a. Foo link, f b. Foo link, access key: f c. Foo link, Alt+Shift+f d. Foo link, access key: Alt+Shift+f e. Something else :-) Let me know and I'll get it done for Epiphany in the meantime and then we can do the same thing for Firefox once Mozilla fixes their bug. Thanks!
Also (duh), braille presentation specifications please.
For speech output you could eg use "speak object mnemonics". Orca has also a speech verbosity setting. if speechd.verbosity = "verbose" && speak obj-Mnemonics = true, then orca should say foo link alt+shift+f if verbose = "brief" && obj-Mnemonics = true, orca should say foo link f If verbose = "brief && obj-mnemonics = false, orca should announce the accesskey In braille orca should present the accesskey deppending on verbosity setting and abbreviated rolenames. I am not sure what the best representation is but I.ll add my thoughts later on it. BTW.: in epiphany the letter of the accesskey seems allready available.
I fully agree with Halim (comment 3.) The way Orca announces access keys should depend on the "read access keys" setting in Orca and the configured speech verbosity. I personally would actually prefer "foo, link, f", but there are probably enough guys out there who need the "alt-shift" to be announced as well.
(In reply to comment #3) > BTW.: in epiphany the letter of the accesskey seems allready available. If you mean made available by Orca: for widgets yes it seems like it is. Yay! Not for links though. This should be an easy enough tweak to make.
So I've improved the speech presentation of access keys for WebKitGtk content (including Epiphany) following what Halim described in comment 3. See bug 654795. The Mozilla bug which blocks this bug has a patch, so hopefully we'll have a fix for that, and might just start doing the right thing automatically. In the meantime, we need to sort out braille presentation. And it occurs to me that access keys *might* have an implication for bug 588875. In particular, there's nothing that states that the access key needs to be a letter in the label for a widget. So we cannot just underline some letter. Do we want to handle access keys differently? Or do we want to have a consistent presentation in braille regardless of the source of the shortcut?
bug 672092 should be fixed, so shouldn't this bug become un "blocked"?
(In reply to comment #7) > bug 672092 should be fixed, so shouldn't this bug become un "blocked"? ?
(In reply to comment #8) > (In reply to comment #7) > > bug 672092 should be fixed, so shouldn't this bug become un "blocked"? > > ? Actually it should become closed as NOTGNOME. :) I just tested with the latest firefox and without changing Orca, we now present access keys in speech. We have bug 588875 for braille-related issues.