RE: accesskey (replacement/enhancement) requirements list

Hi Gregory,

Some thoughts:

-          Sighted keyboard-only users would benefit from the ability to see an overlay of the available access keys on the UI.

-          (4) and (9) seem to be pointing at the need to get a global view of available access key with descriptions (if provided)...if descriptions aren’t provided (as they often won’t be I expect), maybe descriptions could be built from the semantics of the elements pointed to.

-           One thing that always concerns me about access key is when authors put accesskeys into prose – as in help files (this would get thrown off by a cascade or user over-rides). One possibility would be to give the author the ability to put in placeholders into their prose that points to an ID...and then that placeholder would get the calculated access key value (like dynamic figure references in Word processors).

Cheers,
Jan

--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/

Faculty of Design | OCAD University

From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Gregory J. Rosmaita
Sent: August 26, 2010 12:54 PM
To: w3c-wai-ua@w3.org
Subject: accesskey (replacement/enhancement) requirements list


aloha!

here is a listing of the PF requirements for keyboard access in HTML5
-- note that there is a wiki version of this information at

http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements


which contains background information and links not included in this
post...

--- BEGIN PF KEYBOARD REQUIREMENTS FOR HTML5 ---
Requirement 1: A device independent means to activate an access command.

Requirement 2: Ability for an author to define a default access command
mapping, and for a user to override the default mapping.

Requirement 3: Access commands should default to focus behaviour,
ability for authors to specify whether the default behaviour focuses
or activates the target, and for a user to overwrite any author
specified or default behaviour.

Requirement 4: Ability for an author to provide a description for an
access command assignment.

Requirement 5: Ability to specify the target elements that will respond
to an access command, based on their id reference.

Requirement 6: Ability to specify target elements in terms of their
role, or implied ARIA semantics for the role if not overridden by
ARIA.

Requirement 7: Ability to specify a custom order for cycling through
multiple objects attached to a single access command.

Requirement 8: As long as the document is loaded in the browser, user
agents must be able to return the user to their previous place in the
navigation sequence.

Requirement 9: Access command mappings should be available at the
beginning of the document.

--- END PF KEYBOARD REQUIREMENTS FOR HTML5 ---


related resources:

[1] Access Key Replacement (HTML A11y TF wiki page)
http://www.w3.org/WAI/PF/HTML/wiki/Access


[2] is accesskey irretrievably broken as an attribute?
http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements


[3] proposed first draft of "Access Element: Enabling Generic Document
Accessibility"
http://lists.w3.org/Archives/Public/www-archive/2010May/att-0020/access-element-20100519.html