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/access key requirements
Requirements for Accesskey Replacement in HTML5
Accesskey Replacement Requirements
- author: Rich Schwerdtfeger
- trackerID: PF WG Action 167
- source: Action Item 167 - Rich Define requirements for access key replacement
Note: While there is an active Discussion page for the Accesskey Replacement Requirements page, edit rights are limited to members of the HTML5 Accessibility Task Force. To comment upon the contents of these pages if you are not a member of the task force, please email your comments to firstname.lastname@example.org, a publically archived emailing list.
The PF working group has a number of requirements which we feel mandate a replacement of access key in HTML 5:
- We need a device independent way to assign an access key. Access key, today, requires the author to set a pre-defined key yet this key may or may not work on certain browsers, operating systems, and/or devices. Therefore, we would like the ability to request a key mapping but have the user agent make the assignment.
- For backward compatibility we would like the author to be able to assign a "suggested" access key mapping.
- Access key does not clearly define whether activating it will cause a focus change or an activation of the target. We would like the ability to specify which action is performed.
- We would the ability for the author to provide a description with the access key assignment. This is a glaring omission in access key today. Today, even if the author does assign an access key, the user agent has no way of conveying to the user what it is for.
- We would like to be able to specify the target elements to respond to the access key based on their id reference. This allows the author to define a set of targets to be navigated to in order. The user agent would be responsible for cycling through these in DOM order.
- We would like to be able to specify the target elements in terms of their role. This allows the author to define a set of targets to be navigated to in order. The user agent would be responsible for cycling through these in DOM order.
- We would like the ability to optionally specify an order, beyond DOM order, by which to cycle through the focused DOM elements.
- User agents must maintain as to where the user is in the navigation sequence based similar to they do with tabindex so long as the page is loaded in the browser.
- We would like to access the access key mappings at the beginning of the document. This way, some DOM-based assistive technologies can quickly access the access mapping shortcuts vs. having to walk the DOM
The XHTML access module meets all of these requirements with the exception of document ordering. If possible, we would like HTML 5 to synchronize whatever solution is derived with the XHTML 2 working group whose own access element is being consumed by XHTML 2, the XHTML Role Attribute Module, Device Independent Authoring Language (DIAL), and SMIL.
It should be noted that there has been a concern, by John Foliot, regarding allowing the author to assign a key due to device dependency issues highlighted above.