Re: Thinking about ATAG2 Guideline A.3.1 Enhance keyboard access to authoring features

Hi all,

As per my action item...

Since my attached drafts haven't being going through I have 
copy-and-pasted the relevant sections below (I have also sent the drafts 
to Jeanne to see if she can upload them somewhere before the call). 
Alternatively, I will send everyone copies at the start of the call:



Implementing Guideline A.3.1 [For the authoring tool user interface] 
Enhance keyboard access to authoring features. [Return to Guideline]

Rationale: Some authors with limited mobility or visual disabilities are 
not able to use a mouse, and instead require full keyboard access.

Implementing Success Criterion A.3.1.1 Non-Drawing Keyboard Access: All 
functionality of the authoring tool, except drawing functionality, is 
operable through a keyboard interface (Level A)
Note: For drawing functionality, see success criterion A.3.1.2.

Intent of Success Criterion A.3.1.1:
The intent of this success criterion is to ensure that any authoring 
tool functionality that is not involved with drawing does not 
necessarily require the use of a mouse, but instead can be operated 
using a keyboard or an assistive technology that makes use of a keyboard 
interface, such as onscreen scanning keyboards and voice recognition 
systems. Drawing functionality is handled separately (by success 
criteria A.3.1.2, A.3.1.4 and A.3.1.6) in order to make finer 
distinctions within this large and diverse class of user interface 
mechanisms.

Examples of Success Criterion A.3.1.1:
Drag-and-drop feature:
An authoring tool allows authors to open documents by drag-and-drop into 
the authoring tool window. The same operation can be performed from the 
menus using the keyboard.

Related Resources for Success Criterion A.3.1.1: For web-based authoring 
tools, see WCAG 2.0 (including "Understanding WCAG 2.0" 
[WCAG20-UNDERSTANDING] and " How to Meet WCAG 2.0"), especially Success 
Criterion 2.1.1.


Implementing Success Criterion A.3.1.2 Drawing Keyboard Access 
(Minimum): The following drawing functionality (if present) is operable 
through a keyboard interface: (Level A)
(a) inserting new drawing objects; and
(b) selecting drawing objects; and
(c) removing drawing objects; and
(d) moving drawing objects; and
(e) modifying the overall size of drawing objects; and
(f) rotating drawing objects; and
(g) adding/editing text for drawing objects.

Note 1: It is possible to implement keyboard access directly (e.g., 
keyboard-driven manipulation of drawing objects) or indirectly (e.g., 
keyboard editing of drawing object property values).
Note 2: This success criterion should not be interpreted as discouraging 
mouse input or other input methods in addition to keyboard operation.

Intent of Success Criterion A.3.1.2:
The intent of this success criterion is to ensure that basic drawing 
functionality does not necessarily require the use of a mouse, but 
instead can be operated using a keyboard or an assistive technology that 
makes use of a keyboard interface, such as onscreen scanning keyboards 
and voice recognition systems. The basic set of functionalities includes 
the operations that would be required for basic layout editing tasks, 
such as laying out div elements in a web page or editing an office 
layout. While this success criterion is a lesser requirement than WCAG 
success criterion 2.1.1, success criterion A.3.1.4 is equivalent to the 
WCAG 2.0 success criterion and success criterion A.3.1.6 goes a step 
beyond the WCAG 2.0 requirements.

The intent of the note is to clarify that there are various ways that 
drawing functionality can be made accessible, depending on the existing 
authoring tool user interface. This success criterion should not be 
interpreted as discouraging mouse input or other input methods in 
addition to keyboard operation.

Examples of Success Criterion A.3.1.2:
Keyboard manipulation of drawing objects:
A multimedia authoring tool allows authors to navigate the selection 
focus between all of the drawing objects on the canvas. Once an object 
is selected, it can be manipulated with keyboard-driven menu commands, 
some of which have keyboard shortcuts (e.g., arrow keys to move the 
object, etc.). New drawing objects can also be added from the 
keyboard-driven menus.
Keyboard manipulation of drawing object properties:
A multimedia authoring tool does not include keyboard access to the 
drawing canvas directly, but instead provides a keyboard accessible list 
of drawing objects that allows a keyboard editable property page to be 
brought up. The property page includes properties such as "top", "left", 
"wifth", "height", "rotation", "label". When these properties are 
adjusted, the objects on the canvas are updated accordingly. New drawing 
objects can be added from the keyboard-driven menus.

Related Resources for Success Criterion A.3.1.2:
N/A


Implementing Success Criterion A.3.1.3 Avoiding Content Keyboard Traps: 
The authoring tool prevents keyboard traps as follows: (Level A)
(a) In the authoring tool user interface: If keyboard focus can be moved 
to a component using the keyboard, then focus can be moved away from 
that component using standard keyboard navigation commands (e.g., TAB 
key); and
(b) In editing views that render content: If an editing view (e.g., 
WYSIWYG view) renders web content, then a documented keyboard command is 
provided that will always restore keyboard focus to a known location 
(e.g., the menus).

Intent of Success Criterion A.3.1.3:
The intent of this success criterion is to ensure that neither the 
authoring tool's own user interface nor any rendered web content within 
editing views "traps" keyboard focus. This is a common problem when an 
interactive object is embedded in the web content. Authors might be able 
to move focus to the object (e.g., by using the "tab" key), but the 
authors are then unable to move the focus out using the keyboard, 
because keyboard control has passed to the embedded application.
Examples of Success Criterion A.3.1.3:
Non-web-based authoring tool:
A non-web-based authoring tool has a user interface that has been 
thoroughly tested by the developer to ensure that no keyboard traps 
exist. If authors open web content containing keyboard traps in the 
WYSIWYG editing view, the authoring tool allows authors to restore 
keyboard focus to the authoring tool's menus at any time using the "alt" 
keystroke, which the authoring tool never passes to the content being 
edited.
Web-based authoring tool:
A web-based authoring tool has a user interface that has been thoroughly 
tested by the developer to ensure that no keyboard traps exist. If 
authors open web content containing keyboard traps, the authoring tool 
relies on a feature in the authors' user agent (user agent is cited in 
the conformance claim) which always restores keyboard focus to the 
address bar.

Related Resources for Success Criterion A.3.1.3: For web-based authoring 
tools, see WCAG 2.0, especially Success Criterion 2.1.2.


Implementing Success Criterion A.3.1.4 Drawing Keyboard Access 
(Intermediate): Any drawing functionality of the authoring tool is 
operable through a keyboard interface, except where the input depends on 
any characteristics of the path of the author's movement other than the 
endpoints. (Level AA)
Note 1: It is possible to implement keyboard access directly (e.g., 
keyboard-driven manipulation of drawing objects) or indirectly (e.g., 
keyboard editing of drawing object property values).
Note 2: This success criterion should not be interpreted as discouraging 
mouse input or other input methods in addition to keyboard operation.

Intent of Success Criterion A.3.1.4:
The intent of this success criterion is to extend the requirements in 
success criterion A.3.1.2 to cover a greater range of drawing 
funtionality. For example, a common drawing functionality that is 
covered by this success criterion is the manipulation of individual 
control points on curves and other drawing objects. The phrase "except 
where the input depends on any characteristics of the path of the 
author's movement other than the endpoints" is included to exclude those 
tasks that involve continuously recording data points from the path of 
pointer-based or stylus-based actions. The data points might be simple 
x-y coordinates or the pressure and angle in the case of a stylus. 
Making such features accessible to keyboard use falls outside what is 
practical for an intermediate requirement.

Examples of Success Criterion A.3.1.4: Keyboard manipulation of complex 
shapes:
A multimedia authoring tool allows drawing objects to be manipulated by 
independently-movable control points along their surfaces. The authoring 
tool allows the authors to use the keyboard to move selection focus 
between these individual control points and then manipulate the position 
of the control points.

Related Resources for Success Criterion A.3.1.4:
N/A


Implementing Success Criterion A.3.1.5 Keyboard Shortcuts: The authoring 
tool provides keyboard shortcuts. (Level AA)

Intent of Success Criterion A.3.1.5:
The intent of this success criterion is to ensure that authors using a 
keyboard interface can more easily access commonly used functions of the 
authoring tool in a manner that is appropriate to the operating 
environment (i.e., desktop systems generally have more keystrokes 
available to be assigned as shortcuts than mobile devices).

Examples of Success Criterion A.3.1.5:
Non-web-based authoring tool:
A non-web-based authoring tool provides keyboard shortcuts for its menu 
functions as well as access keys in the design of its menus and dialog 
boxes. The choice of shortcut keys follows platform conventions.
Social networking application on a mobile device:
A social networking application on a mobile device has only a very few 
keyboard shortcuts available on its targeted devices. These few keyboard 
shortcuts are used for the most commonly accessed functions of the 
application (e.g., home, list of friends).

Related Resources for Success Criterion A.3.1.5:
The following is a non-exhaustive list of keyboard shortcut conventions 
for various platforms: @@JS to complete@@
Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
Mac OS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]


Implementing Success Criterion A.3.1.6 Drawing Keyboard Access 
(Enhanced): Any drawing functionality of the authoring tool is operable 
through a keyboard interface. (Level AAA)
Note 1: It is possible to implement keyboard access directly (e.g., 
keyboard-driven manipulation of drawing objects) or indirectly (e.g., 
keyboard editing of drawing object property values).
Note 2: This success criterion should not be interpreted as discouraging 
mouse input or other input methods in addition to keyboard operation.

Intent of Success Criterion A.3.1.6:
The intent of this success criterion is to establish an enhanced 
requirement for fully inclusive drawing functionalities. While some 
"high-end" drawing features, such as a "watercolor painting" that 
continuously sampled the path, pressure and pressure of a stylus would 
be extremely challenging to make fully keyboard accessible, other less 
complex functions might be practical.

Examples of Success Criterion A.3.1.6:
Keyboard-driven "freehand" drawing:
A multimedia authoring tool has a mode that allows "freehand" lines to 
be drawn in increments, letting the author use the keyboard to choose 
the angle and length of the next incremenent, after which the shape is 
smoothed.

Related Resources for Success Criterion A.3.1.6:
N/A@@JT any pointers here?


Implementing Success Criterion A.3.1.7 Customize Keyboard Access: The 
author(s) can customize keyboard access to the authoring tool. (Level AAA)

Intent of Success Criterion A.3.1.7:
The intent of this success criterion is to ensure that authors using a 
keyboard interface have the ability to remap the authoring tool's 
keyboard shortcuts in order to avoid keystroke conflicts, use familiar 
keystroke combinations and optimize keyboard layout (e.g., for one 
handed use).

Examples of Success Criterion A.3.1.7:
Non-web-based authoring tool:
A non-web-based authoring tool has a keyboard setup utility that lists 
all of the available keyboard shortcuts and allows authors to associate 
each with any of the authoring tool's commands (e.g., all of the menu 
commands).
Web-based content management system:
A web-based content management system has a keyboard setup utility that 
allows authors to change the access keys that are available during 
authoring. These access key rebindings are for the authors' use only and 
do not affect the web content being edited.
Social networking application on a mobile device:
A social networking application has a keyboard setup utility that allows 
authors to change their keyboard shortcuts for the site. The remapping 
is saved in site cookies.

Related Resources for Success Criterion A.3.1.7:
N/A

Received on Monday, 30 November 2009 17:08:35 UTC