This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23612 - problems with button example for accesskey
Summary: problems with button example for accesskey
Status: RESOLVED FIXED
Alias: None
Product: HTML.next
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, a11y_focus
Depends on: 10782
Blocks: 10888 23613
  Show dependency treegraph
 
Reported: 2013-10-23 19:47 UTC by Mark Sadecki
Modified: 2016-04-11 13:40 UTC (History)
10 users (show)

See Also:


Attachments

Description Mark Sadecki 2013-10-23 19:47:07 UTC
+++ 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 (&#8984;N)". On 
another, it might become "Compose (Alt+&#8679;+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 (&#8984;N)</samp>". On another, it might become
   "<samp>Compose (Alt+&#8679;+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">&#8984;</abbr>N)</samp>"
   "<samp>Compose (Alt+<abbr title="UpArrow">&#8679;</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?
Comment 1 Charles McCathieNevile 2014-12-18 14:55:46 UTC
(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 (&#8984;N)</samp>". On another, it might become
>    "<samp>Compose (Alt+&#8679;+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">&#8984;</abbr>N)</samp>"
>    "<samp>Compose (Alt+<abbr title="UpArrow">&#8679;</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.
Comment 2 Charles McCathieNevile 2016-04-11 13:40:43 UTC
The example deals with accessKeyLabel, and was removed when we removed that for lack of implementation...