Now that bug 959 is fixed, we can use XUL accesskey. An accesskey is an underlined letter in a form control that gives a keyboard shortcut for activating the control. The accesskey FAQ and guidelines document is at http://www.mozilla.org/projects/ui/accessibility/accesskey.html Unfortunately, all is not perfect. Crucial bugs that still need to be fixed: Bug 128608 - Accesskeys don't work for (xul) tabpanels Bug 68841 - We don't underline accesskeys for checkboxes or radiobuttons (they work, but aren't displayed correctly) However, we have enough to now start hooking these up.

Just to reiterate. It's important for anyone working on these bugs to read the FAQ: http://www.mozilla.org/projects/ui/accessibility/accesskey.html

I'd like to get bug 128987 fixed before we get too far into these. The fewer things that reference .accessKey, the fewer things that fix needs to change.

Err.... forget I said that. 128987 is wontfix.

Thanks, Aaron for pointing to this document in comment 1. I am going to review other existing bugs regarding mnemonics and make this one dependent on them. As you suggested, I change component to Keyboard Navigation, but Product: MailNews.

The first thing we need is for someone to file the rest of the bugs for this - probably one per dialog is a good idea.

I have a bunch of them for MailNews. They are going to appear here in 'Depends on' area.

For MailNews product there is no 'Keyboard Navigation' component. It is only for Browser. So, looks like that MailNews bugs won't have suggested component. But I list them here.

Quick note on something I found when fixing bug 78153. If you're trying to set or change the accesskey from js, use .accessKey not .accesskey.

Preferences accesskey people should be aware of bug 129808 - Pref panel accesskeys don't work when category tree or dialog button has focus.

There is meta bug 154249 only for Mail front end and accessibility issues - other than mnemonics.

Mass un-assigning bugs assigned to Aaron.

The URL provided in the bug description (http://www.mozilla.org/projects/ui/accessibility/accesskey.html) was 404 so I removed it. Also, it seems a recent update (FF14? FF14.0.1?) broke accesskey on Mac. Expected: ctrl-accesskey works. e.g. on any MediaWiki site like Wikipedia, microformats.org etc.: * ctrl-e to edit, then * ctrl-p to preview * or ctrl-s all regardless of focus-state (which element on the page is focused etc.) Actual behavior in FF14.01/MacOSX Lion: ctrl-option-accesskey *sometimes* works, e.g. on any MediaWiki site like Wikipedia, microformats.org etc. * control-accesskey combinations noted above FAIL (do nothing). * ctrl-option-e to edit * ctrl-option-p to preview FAILS regardless of what element is focused. * ctrl-option-s to save FAILS. If you click somewhere on the page to unfocus/defocus a text field which might be active (e.g. the textarea), then this works. Such unfocusing should not be necessary either. There may be multiple regressions occurring here. Noting all this in this bug because this is the *only* result when you search Bugzilla for "accesskey" (no list of results, just directly takes you to this bug).

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information