chaals / accesskey Goto Github PK

Backwards compatibility needs to be addressed explicitly. Ideally a web site that put an access key on an element and also had a bare key listener for that same key shouldn't break. Or if you think it should break, explicitly say so and explain why the impact is minimal.

The HTML 4 and HTML5 specifications do not explain what to do if the same accesskey value is used for two different elements. Since this does happen, that should be fixed.

Suggest removing the title attributes from the first example in 5.5.2 (The accesskey attribute).

In this context the title attribute is more hinderance than help. It isn't well accessibility supported in general, isn't supported on touch devices at all, and can seriously inconvenience magnifier users. More info here:
http://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/

This might be an edge case, but possibly something to consider...

On Windows (and possibly other platforms) there are third party applications that set system-wide keyboard shortcuts. An example being the (small) collection of GUI-less Twitter clients used by screen reader users on Windows.

Is it reasonable to allow one attribute to carry multiple functions - e.g. Voice, keyboard, etc?

Raised by Rodney Rehm

Here are some examples of real-world shortcuts implemented by existing web apps:

• 'C' to compose a new message in Gmail/Inbox
• Ctrl+Shift+C to do a Word Count in Google Docs
• Shift+A to "reply all" in Yahoo Mail
• 'L' to like the current story on Facebook
• '/' to focus the search box on Twitter
• 'C' to create an issue on GitHub

It doesn't sound like any of these apps could switch to accesskey, because accesskey only supports the browser modifier keys.

Is there any reason accesskey couldn't be expanded to support key combinations with modifier keys explicitly, like Shift+A or Ctrl+Shift+C?

In the opening paragraph of the rationale, suggest linking through to the HTML5 and HTML4 accesskey definitions.

The spec says that when a user presses the access key, the user agent must focus the target element, but it may trigger the action of the command.

Why?

If user agents are allowed to not trigger the action of the command, then authors can't rely on accesskey as a replacement for existing shortcuts that trigger actions. That will result in authors sticking with JavaScript key handlers rather than switching to accesskey.

I propose that we require user agents to trigger the action of the command if accesskey is placed on an activatable element. That will make it more useful to authors and encourage its adoption.

The proposal needs to explain what is wrong with the current spec / implementation and why we need this replacement.

For javascript developers, knowing what accesskey is used, not just what is specified, would enable better conflict management by allowing finer-grained decisions on what accesskeys to request.

The current implementation state of accessKeyLabel seems pretty sad anyway, so it is unlikely that a change would break much.

How do different UAs factor into the processing model defined in 5.5.3 (Processing model)?

If the browser handles the processing, which ultimately seems likely since it'll have to update the accessKeyLabel based on the assigned accesskey, is the intention that it'll negotiate with any AT running at the time? If not, how/where does the hand-off between the browser and AT take place in the processing model?

Most development now starts br using JS to provide primitives for testing. Why not do that here?