W3C home > Mailing lists > Public > public-html-a11y@w3.org > July 2010

Keyboard Access Requirements Recommendation from PF

From: Janina Sajka <janina@rednote.net>
Date: Thu, 22 Jul 2010 12:34:55 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20100722163455.GH2478@sonata.rednote.net>
The WAI Protocols and Formats Working Group is forwarding the
following requirements for keyboard access functionality in HTML 5 to
the HTML-A11Y Task Force. These requirements were unanimously adopted by
PF at its regular weekly teleconference on Wednesday 21 July 2010:
http://www.w3.org/2010/07/21-pf-minutes

PF thanks Léonie Watson and Gregory Rosmaita for helping pull these
requirements together. Thanks to Joseph Scheuhammer for helping us
clarify our meaning. Thanks also to everyone who participated in our WBS
on these requirements, and to Richard Schwerdtfeger who created our
first requirements draft lo these many months ago.

Explanatory note:

The term "access command" is defined as a means of (1) invoking a
command or function of a web application, or (2) moving focus to the
element allowing a subsequent gesture to activate that element's
associated command or function.  Furthermore, a set of access commands
defines a navigational sequence among the command elements.

Note that "access command" is more general than the legacy concept of
"accesskey", and emphasizes access to functionality.  As such it is
intended to distance these requirements from the legacy deployment and
poor reputation of "accesskey" as defined by HTML 4x.


 
Requirement 1: A device independent means to activate an access command.

Explanatory notes:
	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, the ability for the user to request a key mapping, and have the user agent make the assignment, is essential.

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

Explanatory notes: -
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.

Explanatory notes:
	If no user or author behaviour is specified, a clear default should be used, in most cases this would default to a focus behaviour.

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

Explanatory notes:
	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.

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

Explanatory notes:
	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.

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

Explanatory notes:
	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. References:
http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria  

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

Explanatory notes: -
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.

Explanatory notes: 
	As an example, @tabindex is used to define a navigational
sequence
that allows users to move focus forwards and backwards among a set of
elements.

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

Explanatory notes:
	This way, some DOM based assistive technologies can quickly access the mapping shortcuts versus having to walk the DOM.
 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Thursday, 22 July 2010 16:35:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:13 GMT