Where an HTML element has an ACCESSKEY, if a character (case-insensitively) equivalent to the accesskey is present in the element's label, that character should be underlined by default. (I suggest a 2px-thick underline, so as to allow the accesskey for links to be visible over the top of their existing default underline.) Without such highlighting, the ACCESSKEY attribute is pretty much useless, because the user has no idea which key is the accesskey for a given element. If the author is forced to manually apply presentational formatting to each accesskey, then accesskey highlighting will be inconsistent between pages, confusing the user -- and such formatting would be lost if (for example) the language of the page was translated between the source and the user, even if a character matching the accesskey was still present in the translated version. I'm thinking this will probably require the implementation of a :-moz-accesskey selector, to find and mark the accesskey in an element so a CSS rule can get at it.

Reassigning to Attinasi and marking future.

Marking target milestone: ACCESSKEY is useless without a visual indication...

Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.

qa contact updated.

SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.

Seems related to bug 68841 - underline accesskey in XUL checkboxes and radio buttons. The XUL checkboxes and radio buttons use XUL:label for the text, which use layout\html\base\src\nsAreaFrame. XUL accesskeys are not styleable, we just underline them. I'm sure this will be shot down -- but can we just do the same for HTML accesskey? It's a lot better than having no emphasis/discoverability. I think making it styleable will make it into a very difficult project, not worth the effort in my opinion.

> XUL accesskeys are not styleable, we just underline them. > I'm sure this will be > shot down -- but can we just do the same for HTML accesskey? I think that's the way it should be done - the simple underlining of the key is a widely understood GUI standard. If it's changed any other way, then people will just end up getting confused eg, 'why's this letter bright red on a blue background? weird'

Agreed. Even the CSS3 UI working draft doesn't mention a selector for keyboard accelerators, so this would be overkill. A basic underlining implementation is better than nothing, despite it clashing with hyperlinks. This would put Mozilla further ahead of (at least) IE and Konqueror for accessability.

Okay, I have underlining working. In XUL menus and buttons we append sometimes accesskeys in parenthesis, depending on what language the UI is rendered in, for example: File(_F_) This also happens if the accesskey letter isn't found in the prompt. To see this all over Mozilla, you can manually set the pref in prefs.js: user_pref("intl.menuitems.alwaysappendacceskeys", "true"); (Yes I know they misspelled it, but that's what you have to call it.) Note that we don't support this in XUL checkboxes or radio buttons, since those use HTML for rendering. The question is, do we need to support this feature for HTML as well? I might have to spin off another bug for that.

I have a patch for this in bug 68841

Hmmm ... links are a bit of a problem, since they're already underlined. After a little experimenting, I found that doubling the thickness of the underline for the accesskey letter in a link looks pretty good. Does anyone think this is a reasonable solution?

Best solution for the job, really. Is there some way to make it check whether underlines have been disabled with css and only do a normal thickness underline then? I'm not sure whether that particularly matters though.

Yes, I would actually do the double thickness underline for anything that had underlining, not by checking if it was a link or not.

I have an issue 167566 that deals with Access Keys as well. Basically it lists the AccessKey in the Page Info screen. The idea is that if you frequent a page, then you could memorize the AccessKey. Have fun...

We shouldn't forget that although accesskeys make convient short-cut keys they are primarily aimed at making the web more accessible to people without mice, especially those using screen reader or braille technology. Many users that really need accesskeys can not actually see and highlighting, so web developers should be encouraged to use a standard set of accesskey through out sites. These should be published somewhere obvious (recently I have been putting a link to a list of accesskeys after the skip-nav) so all accesskey users can access them. Adding visual clues to accesskeys will most likely cause them to be used only as shortcut keys without the guide which disabled users so badly need.

Tom Croucher says "Adding visual clues to accesskeys will most likely cause them to be used only as shortcut keys without the guide which disabled users so badly need." I would argue just the opposite: adding a visual cue means that more people (i.e., not just people with disability interfaces) will use them, which is more people that will say "Why don't use 'standard' key bindings?" (assuming that such a notion ever arises), or at least "Hey, put in accesskeys, they're GRRRRRREAT!"

I think there should be several ways to find out the accesskeys in effect on a particular page. Any combination of: * Show them in a tab off of the Page Info window, and/or in the many applicable places in the existing tabs of the Page Info window! * Show them in a tooltip/popup/whatchamacallit when focussing/hovering-over the applicable elements! * Show them in the status bar when focussing/hovering-over the applicable elements! * Show them in the (little-known?) Element Properties window for the applicable elements! * Show them via some double-underlining of the letters in the applicable elements, or some other cleverness! I bet that in the meantime, at least some of this could be implemented in a Firebird Extension. I'd do it right now if I had any experience doing that at all. But I'm not too proud to beg!

For the first four of those suggestions: If someone has to use the mouse, or do something else with the keyboard, in order to discover the access key for a particular element, the entire point of accesskeys (speed of access) is lost. That leaves underlining, which is (1) one method and (2) my original proposal.

It is true that the main point of HTML accesskeys is obviated if the /only/ way(s) to find out the keyboard shortcuts is thru using the mouse. But /none/ of the alternative methods I suggested rely on mousing -- one can bring up the page-info window, or focus an element, or bring up the focussed element's properties window without ever touching a mouse. I think underlining the accesskey'd elements is a good thing and should be the primary means of pointing out HTML accesskeys; but there is no advantage in that being the only way. I stand by all of my other suggestions /as well/, particularly as most/all of them seem trivial to implement.

> For the first four of those suggestions: If someone has to use the mouse, or do > something else with the keyboard, in order to discover the access key for a > particular element, the entire point of accesskeys (speed of access) is > lost. I thought the first priority of access keys was as an assistive technology for the disabled (not that the rest of your point is wrong). See also bug 303192 comment 28 for how konqueror does it -- although per comment 15 , I'm realizing that konqueror's implementation seems better suited for sighted people with motor disabilities and have problems using a mouse, than for the visually impaired (who would benefit from a more standardized set of access keys).

Mass un-assigning bugs assigned to Aaron.

This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.