This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.

Access/HTML5 Accesskey Bugs

From HTML accessibility task force Wiki
Jump to: navigation, search


Accesskey Bugs Logged Against HTML5

Meta Bug - Access Command Requirements



Bugs marked as NEW


Bugs marked as ASSIGNED


Bugs marked RESOLVED FIXED


  • HTML WG Bug 10775 - how is user to decide which set of access keys to use?
    • marked RESOLVED FIXED, citing: http://html5.org/tools/web-apps-tracker?from=5595&to=5596
      • status: the HTML Accessibility Task Force needs to review the following quotes from the 18 March 2011 Editor's Draft which follow to ensure that this bug has been adequately addressed; of pariticular concern is that there is no stipulation that when a UA or user chooses a set of accesskeys, that that set of accesskeys will be uniformly applied (no mixing of accesskey strings: once a set of accesskeys is chosen, the user agent must them limit the accesskey values to those that match the position of the initially chosen accesskey)


If specified, the value must be an ordered set of unique space-separated tokens that are case-sensitive, each of which must be exactly one Unicode code point in length.

In the following example, a variety of links are given with access keys so that keyboard users familiar with the site can more quickly navigate to the relevant pages: 

<nav>
<p>
<a title="Consortium Activities" accesskey="A" href="/Consortium/activities"
     >Activities</a> |
<a title="Technical Reports and Recommendations" accesskey="T" href="/TR/"
     >Technical Reports</a> |
<a title="Alphabetical Site Index" accesskey="S" href="/Consortium/siteindex"
     >Site Index</a> |
<a title="About This Site" accesskey="B" href="/Consortium/"
     >About Consortium</a> |
<a title="Contact Consortium" accesskey="C" href="/Consortium/contact"
     >Contact</a>
</p>
</nav>

In the following example, the search field is given two possible access keys, "s" and "0" (in that order). A user agent on a device with a full keyboard might pick Ctrl+Alt+S as the shortcut key, while a user agent on a small device with just a numeric keypad might pick just the plain unadorned key 0: 

<form action="/search">
 <label>Search: <input type="search" name="q" accesskey="s 0"></label>
 <input type="submit">
</form>

In the following example, a button has possible access keys described. A script then tries to update the button's label to advertise the key combination the user agent selected. 

<input type=submit accesskey="N @ 1" value="Compose">
...
<script>
 function labelButton(button) {
   if (button.accessKeyLabel)
     button.value += ' (' + button.accessKeyLabel + ')';
 }
 var inputs = document.getElementsByTagName('input');
 for (var i = 0; i < inputs.length; i += 1) {
   if (inputs[i].type == "submit")
     labelButton(inputs[i]);
 }
</script>
On one user agent, the button's label might become "Compose (⌘N)". On another, it might become "Compose (Alt+⇧+1)". If the user agent doesn't assign a key, it will be just "Compose". The exact string depends on what the assigned access key is, and on how the user agent represents that key combination.



Bugs marked RESOLVED WONTFIX

  • HTML WG Bug 10772 - accesskey and an ordered set of unique space-separated tokens
    • marked RESOLVED WONTFIX "Status: Rejected / Change Description: no spec change / Rationale: A "word" is just used to mean the same as token -- a string of characters with no whitespace (no word separators). This is pretty common practice in the industry."
      • status: the word "word" no longer appears in the HTML5 draft definition of accesskey.
      • to do: ensure that this is true in the next public working draft



REPLACE WITH:

4. Fallback:

A. if the user agent assigns a key combination of its own as an element's assigned access key,
A1. the user agent MUST notify the user what accesskeys have been assigned to which elements;
A2. such an assignment MUST not conflict with author-defined accesskeys; this means that the author-defined access keys MUST be omitted from the collection of keys available for the user-agent to assign;

B. Abort these steps

To which the editor replied:

1.1: The spec makes allowances for that already, by exposing the key to the DOM and by suggesting that access keys be made known in the menus. Doing more than that would be requiring UI, which is inappropriate.

1.2: I disagree; the user agent is the _user's_ agent, not the author's, and can therefore ignore the author's wishes if the user so desires (or if the user agent's implementor supposes that the user would so desire).


  • HTML WG Bug 10776 - accesskey value token subsets
    • marked RESOLVED WONTFIX: "Status: Rejected / Change Description: no spec change / Rationale: No, it only means to skip the steps for the one bogus value, not for the whole attribute. There might be more values after this one."
      • status:



  • HTML WG Bug 10778 - use element.accessKeyLabel to generate list of available accesskeys
    • marked RESOLVED WONTFIX: "Status: Rejected / Change Description: no spec change / Rationale: That doesn't make any sense. The user agents are the ones that generate accessKeyLabel, how would they use it to do anything?"
      • status: despite the "won't fix", what was requested can be found in the 18 March 2011 Editor's Draft: "User agents can provide users with a list of the keyboard shortcuts, but authors are encouraged to do so also. The accessKeyLabel IDL attribute returns a string representing the actual key combination assigned by the user agent."


  • HTML WG Bug 10779 - triggering the Action of the command via accesskey
    • marked RESOLVED WONTFIX: "Status: Rejected / Change Description: no spec change / Rationale: I don't understand why the proposed text is any less "oblique". It seems to just say the exact same thing but with some additional meaningless fluff (e.g. "check if the command's Hidden state facet is false (visible)"). Regarding the additional consideration, I don't understand what is being requested. Also, please file just one issue per bug.


(exerpt from GJR's bug description)

This should be stated less obliquely:

When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command

  1. check if the command's Hidden state facet is false (visible)
  2. check if the command's Disabled state facet is false (enabled)
  3. if the command's Hidden and Disabled state facets are false, trigger the Action of the command.


ADDITIONAL CONSIDERATION:

The above prose should be followed DIRECTLY by a note denoting that accesskey activation response MUST be controlled, storable and shareable by the user through a user agent setting. If an author defines a specific action to a command, users MUST be able to override the author's suggested action, in observance of a persistent user setting. This allows the user to use a "safety" to avoid firing an event defined for an element when the accesskey defined for that element is invoked, so that a user may make an informed decision as to whether or not to activate the element or to move focus to that element in order to inspect it for pre-set triggers.



Retrieved from "https://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Access/HTML5_Accesskey_Bugs&oldid=3507"