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 10775 - how is user to decide which set of access keys to use?
Summary: how is user to decide which set of access keys to use?
Status: VERIFIED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: Gregory J. Rosmaita
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on: 10888 23613
Blocks: 10773
  Show dependency treegraph
 
Reported: 2010-09-27 17:55 UTC by Gregory J. Rosmaita
Modified: 2013-10-23 19:59 UTC (History)
9 users (show)

See Also:


Attachments

Description Gregory J. Rosmaita 2010-09-27 17:55:39 UTC
QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
   If specified, the value must be an ordered set of unique
   space-separated tokens, each of which must be exactly one Unicode code
   point in length.
UNQUOTE

PROBLEM 1: how does the user know that more than one set of access keys
is available?

PROBLEM 2: how does the user select the set of access keys to use?

PROBLEM 3: can the use switch from one set of access keys to another
should the first set be too complicated to use?  if so, how?

PROBLEM 4: when using more than one token to assign an accesskey to 
a unique element, must all the accesskey values contain the same number 
of tokens in order for the accesskey values to validate?  

PROBLEM 5: why use the phrase "unique space-separated tokens"? 
"unique space-seperated characters, each of which must be exactly
one unicode point in length"
Comment 1 Ian 'Hixie' Hickson 2010-09-28 06:54:42 UTC
Please file one problem per bug.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Invalid use of bug system.

Looking at the specific problems:

PROBLEM 1: There is no set of access keys, just one key per accesskey'ed element.

PROBLEM 2: The user agent selects the access key, not the user.

PROBLEM 3: There are no "sets" of access keys.

PROBLEM 4: no

PROBLEM 5: the phrase "unique space-separated tokens" implies certain conformance requirements described in the infrastructure section.
Comment 2 Gregory J. Rosmaita 2010-09-30 14:23:20 UTC
(In reply to comment #1)
in response to comment #0
>>PROBLEM 1: how does the user know that more than one set of access keys
>>is available?

the editor replied:

> Status: Rejected
> Change Description: no spec change
> Rationale: Invalid use of bug system.
> 
> Looking at the specific problems:
> 
> PROBLEM 1: There is no set of access keys, just one key per accesskey'ed
> element.

QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute"
  If specified, the value must be an ordered set of unique
  space-separated tokens, each of which must be exactly one Unicode code
  point in length.
UNQUOTE

are you saying that a single element may have multiple accesskeys that 
act as synonyms? -- in other words, accesskey="S @ 1" assigned to an 
element would be triggered by either the character capital-S the at-sign 
or the numeral 1?

is the user agent or assistive technology supposed to inform the user of all of the options available as an accesskey for an element?

if so, how precisely does the cascade work?  first token, second token, third
token?  if i use the first token for one element and the second for another,
both will cause the expected action for the individual elements for which they 
have been assigned when the accesskey is invoked?
Comment 3 Ian 'Hixie' Hickson 2010-09-30 18:45:42 UTC
I'll add a bunch of non-normative text to the spec to explain how this works more clearly, since the current text is clearly not understandable enough. Sorry for making it so opaque.
Comment 4 Ian 'Hixie' Hickson 2010-10-07 22:42:34 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: see comment 3
Comment 5 contributor 2010-10-07 22:50:56 UTC
Checked in as WHATWG revision r5596.
Check-in comment: Explain accesskey better.
http://html5.org/tools/web-apps-tracker?from=5595&to=5596
Comment 6 Martin Kliehm 2010-10-26 15:56:31 UTC
Bug triage subteam adding dependency on 10888 as a master bug for accesskey bugs
Comment 7 Martin Kliehm 2010-12-21 15:39:32 UTC
Reviewed the changed non-normative spec text for the Accessibility TF bug-triage sub-team, and I believe it does the job, therefore verifying the fixed state. @Gregory, if you are satisfied with the solution, please close the bug.
Comment 8 Michael Cooper 2011-01-18 16:29:26 UTC
Bug triage sub-team does not think this needs to be a TF priority. Assigning to
Gregory to address recommendation in comment 7.