- From: <bugzilla@jessica.w3.org>
- Date: Wed, 23 Oct 2013 19:59:21 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23613
Bug ID: 23613
Summary: Access Command Requirements for HTML5
Product: HTML.next
Version: unspecified
Hardware: All
URL: http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requireme
nts_revision
OS: All
Status: NEW
Keywords: a11y, a11ytf, a11y_focus
Severity: normal
Priority: P2
Component: default
Assignee: chaals@yandex-team.ru
Reporter: mark@w3.org
QA Contact: public-html-bugzilla@w3.org
CC: cooper@w3.org, ian@hixie.ch,
laura.lee.carlson@gmail.com, mike@w3.org,
oedipus@hicom.net, public-html-a11y@w3.org,
public-html-admin@w3.org,
public-html-wg-issue-tracking@w3.org, robin@w3.org,
w3c@kliehm.com
Depends on: 23612, 10779, 10780, 10782, 10888, 11140
Blocks: 23611, 10772, 10774, 10775, 10776, 10777, 10778,
10905, 10994
+++ This bug was initially created as a clone of Bug #10888 +++
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.
BACKGROUND:
The WAI Protocols and Formats Working Group has forwarded the following
requirements for keyboard access functionality in HTML 5 to the HTML
A11Y Task Force which did not have any objections to these requirements
and which asked that these requirements be logged as a bug.
Potential Uses of Access Command
The following are potential uses of access command as easy to define
shortcut keys:
* Moving keyboard focus to specific form controls or widgets
(shortcut key)
* This is important where someone need to fill out forms
on a frequent basis and there are certain controls that
the user needs to go to quickly to reduce the time to
fill out the form.
* Form submission
* Moving focus to a specific link
* Activation of a specific link (go to another resource or location
in the same resource)
* Move focus to a nav element or to a link in a nav element
* Starting and stopping playing audio and video
* Incrementing the time line of audio and video
* Incrementing the playback rate of an audio or video resource
* In drag and drop picking up a specific dragable item
* In drag and drop moving focus to a specific droppable location
ACCESS COMMAND REQUIREMENTS
Requirement 1: A device independent means to activate an access command.
* Explanatory Note for Requirement 1: @accesskey, 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
* UA implementation note: the default access mapping and user
override mapping must be sharable and storable.
Requirement 3: Access commands should default to focus behaviour;
Explanatory note for Requirement 3: If no user or author behaviour is
specified, a clear default should be used, in most cases this should
default to a focus behaviour.
* UA Implementation Notes
* user agents must allow users to specify whether the default
behaviour focuses or activates the target;
* the default access mapping and user override mapping must
be sharable and storable.
Requirement 4: Ability for an author to provide a description for an
access command assignment; the user agent should recognize and describe
user overrides;
* Explanatory note for Requirement 4: This is a glaring omission
in @accesskey today. Today, even if the author does assign an
accesskey, the user agent has no way of conveying to the user
what it is for. Descriptions could be built from the semantics
of the elements pointed to.
* UA Implementation Note: Such descriptions should be storable and
sharable;
Requirement 5: Ability to specify the target elements that will respond
to an access command, based on their id reference.
* Explanatory note for Requirement 4: 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 note: 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:
Annotations for Assistive Technology Products (ARIA) from the
HTML5 editor's draft
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.
* Explanatory notes for Requirement 8: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 note 1 for Requirement 9: Some DOM based assistive
technologies coulg quickly access the mapping shortcuts versus
having to walk the DOM. Descriptions could be built from the
semantics of the elements pointed to.
* Explanatory note 2 for Requirement 9: Additionally, a user
should be able to designate a specific keyboard layout so that
the user agent can respond appropriately to user input
PF thanks Léonie Watson and Gregory Rosmaita for helping pull these
requirements together. Thanks to Joseph Scheuhammer for helping us
clarify our meaning, and Jon R. Gunderson, for providing use cases.
Thanks also to everyone who participated in our WBS on these
requirements, and to Richard Schwerdtfeger who created our first
requirements draft many many months ago. Thanks to the members of
the User Agent Accessibility working group for reviewing and
contributing to these requirements on a very tight schedule.
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 23 October 2013 19:59:23 UTC