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

Hi all,

Here's another kick at the "A.3.1 Keyboard Access" can. Basically, I 
have folded things back into one requirement (I'm assuming we will also 
have a Level-AAA requirement without the exception):

A.3.1.1 Keyboard Access (Minimum): All functionality of the *authoring 
tool* is operable through a *keyboard interface*, except for *freehand 
drawing*. (Level A)

Note 1: The *freehand drawing* exception relates to the underlying 
function, not the input method. For example, using handwriting to enter 
text is not freehand drawing because the underlying function is text input.

Note 2: This should not be interpreted as discouraging mouse input or 
other input methods in addition to the *keyboard interface*.

Glossary:

*freehand drawing*
An *authoring action* in which *content* is created or modified on the 
basis of continuously recording data (e.g., location, speed, pressure, 
angle) from a pointing device (e.g., mouse, stylus). Freehand drawing 
does not include other uses of pointing devices, such as setting 
endpoints, drag-and-drop or entering text via a handwriting recognition 
system. Setting the properties (e.g., color, line thickness) of freehand 
drawn content objects as a whole, as opposed to individually recorded 
data points, would also not be considered freehand drawing.

*keyboard interface*
An interface used by software to obtain keystroke input. A keyboard 
interface can allows keystroke input even if particular devices do not 
contain a conventional keyboard (e.g., a touchscreen PDA can have a 
keyboard interface built into its operating system to support onscreen 
keyboards as well as external keyboards that may be connected). 
Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as 
operation through a keyboard interface because these emulators use 
pointing device interfaces, not keyboard interfaces.


Cheers,
Jan





> Hi all,
> 
>  From yesterday's call, it seems there is a desire to simplify...how 
> about this:
> 
> (1) Reworking of 3.1.2
> 
> 3.1.2 Drawing Keyboard Access (Minimum): *Drawing functionality* meets 
> all of the following conditions: (Level A)
> (a) The *drawing functionality* uses only *drawing objects*, rather than 
> non-selectable representations.
> (b) All *drawing objects* are selectable through a *keyboard interface*.
> (c) All *drawing object properties*, except those associated with 
> individual data points on a *drawn path*, are editable through a 
> *keyboard interface*.
> 
> ed. note: (c) means that properties such as the color and thickness of 
> the line would still need to be keyboard operable
> 
> 
> (2) Removing 3.1.4
> 
> (3) Keeping 3.1.6 for specialized tools that can be designed to provide 
> precision editing at the level of the "drawn path" data points. (Level AAA)
> 
> (4) Rework Definitions:
> 
> *drawing functionality*
> Authoring tool user interface functionality in which authors add or 
> modify graphical representations of content, even if the underlying 
> content being edited is not a graphic. Examples include using "handles" 
> to re-size shapes graphics editor, using a freehand "airbrushing" tool, 
> laying out div element in a WYSIWYG webpage editor, adding freehand 
> waveform visualizations in an audio editor.
> 
> *Drawing objects*
> Graphical representations of content that remain independently 
> selectable objects, in contrast to the non-selectable graphical 
> representations that are employed by some simple paint applications. 
> *Drawing object properties* are the properties of drawing objects, such 
> as position information, line color, fill color, transparency, text 
> label, etc. Some drawing objects incorporate a *drawn path*, which 
> consists of data sampled during freehand drawing, such as pointer 
> location or stylus pressure, angle etc.
>

Received on Wednesday, 13 January 2010 22:11:34 UTC