This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #10782 +++ QUOTE 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. UNQUOTE PROBLEM 1: The user should be the ultimate arbiter of which accesskey to apply, not the user agent The exact string depends on which of the suggested access key sets is in use, and upon how the user agent represents the key combinations that comprise that set of accesskeys. PROBLEM 2: there are characters used in the last paragraph that are not exposed when using a screen reader -- in particular: "<samp>Compose (⌘N)</samp>". On another, it might become "<samp>Compose (Alt+⇧+1)</samp>" since the use of special characters constitutes ascii art, the character entities should be glossed using ABBR as follows: "<samp>Compose (<abbr title="Command-Key">⌘</abbr>N)</samp>" "<samp>Compose (Alt+<abbr title="UpArrow">⇧</abbr>+1)</samp>" such extended characters should NOT be used in UA notifications, as the values expressed using symbolic characters will not be read by a screen reader -- it is better for the UA to report "CommandKey+N" and "ALT + UpArrow + 1" PROBLEM 3: currently, the draft states: "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." PROPOSED: If a user has set their user agent to use a specific key or key combination as accesskey modifiers, or if no modifier key has been pre-set as a default by the user agent, the user agent must not assign a specifc key, but simply report "Compose". The exact string depends on what the assigned access key is, and on how the user agent represents that key combination. PROBLEM 4: how does the user notify the script which set of access keys that user wishes to use?
(In reply to Mark Sadecki from comment #0) > +++ This bug was initially created as a clone of Bug #10782 +++ > PROBLEM 1: The user should be the ultimate arbiter of which accesskey > to apply, not the user agent Yes, but this is a problem of implementation in the user agent, although the specification should make it clear that this is an important issue. I'll raise a separate bug. > PROBLEM 2: there are characters used in the last paragraph that are > not exposed when using a screen reader -- in particular: > > "<samp>Compose (⌘N)</samp>". On another, it might become > "<samp>Compose (Alt+⇧+1)</samp>" > > since the use of special characters constitutes ascii art, the > character entities should be glossed using ABBR as follows: > > "<samp>Compose (<abbr title="Command-Key">⌘</abbr>N)</samp>" > "<samp>Compose (Alt+<abbr title="UpArrow">⇧</abbr>+1)</samp>" This problem still exists. > PROBLEM 3: currently, the draft states: "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." > > PROPOSED: > If a user has set their user agent to use a specific key or key > combination as accesskey modifiers, or if no modifier key has been > pre-set as a default by the user agent, the user agent must not > assign a specifc key, but simply report "Compose". The exact string > depends on what the assigned access key is, and on how the user agent > represents that key combination. This doesn't seem to be a good solution. On the other hand, the idea that authors should be responsible for providing information about an activation method controlled by the browser seems ridiculous. The whole example, and the idea behind it that the user interaction behaviour is not the responsibility of the browser, is broken and needs to be fixed. > PROBLEM 4: how does the user notify the script which set of access > keys that user wishes to use? That is again a user agent implementation issue - the user should not notify the script, but only the browser. The script in this example doesn't set the key, it merely repeats what the browser reports to it as the activation method.
The example deals with accessKeyLabel, and was removed when we removed that for lack of implementation...