- From: Sueann Nichols <ssnichol@us.ibm.com>
- Date: Fri, 16 Oct 2009 14:53:13 -0400
- To: WAI-AUWG List <w3c-wai-au@w3.org>
- Message-ID: <OF70C84BCB.11D36ED0-ON85257651.00679ABE-85257651.0067BFD0@us.ibm.com>
PRINCIPLE A.3: Editing views must be operable
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.
Current A.3.1.1
A.3.1.1 Keyboard: All functionality of the authoring tool is operable
through a keyboard interface without requiring specific timings for
individual keystrokes, except where the underlying function requires input
that depends on the path of the author's movement and not just the
endpoints. (Level A)
SN Comment – the “underlying function requires input that depends on the
path of the author's movement and not just the endpoints” doesn’t seem
clear. Is the issue the need for timing?
Recommend re-wording:
A.3.1.1 Keyboard: All functionality of the authoring tool is operable
through a keyboard interface and does not require specific timings for
individual keystrokes. An exception is where the underlying function
requires input that depends on the path of the author's movement and not
just the endpoints, and timing of keystrokes is required to support the
function. (Level A)
Note 1: The movement path exception relates to the underlying function, not
the input technique. For example, if using handwriting to enter text, the
input technique (handwriting) requires path-dependent input, but the
underlying function (text input) does not.
Current text:
Note 2: This does not forbid and should not discourage providing mouse
input or other input methods in addition to keyboard operation.
Recommended change
Note 2: This does not prohibit or discourage providing mouse input or
other input methods in addition to keyboard operation.
· Intent of the Success Criterion A.3.1.1:
The intent of this success criterion is to ensure that, wherever
possible, authoring tools can be operated through a keyboard or
keyboard interface. Examples of "specific timings for individual
keystrokes" include situations where authors would be required to
repeat or execute multiple keystrokes within a short period of time
or where a key must be held down for an extended period before the
keystroke is registered. The phrase "except where the underlying
function requires input that depends on the path of the author's
movement and not just the endpoints" is included to separate those
things that cannot reasonably be controlled from a keyboard.
· Examples that meet the Success Criterion:
·
o Drag-and-drop feature:
An authoring tool that includes a drag-and-drop feature for
adding widgets to web content also includes allows the same
widgets to be added from a menu that can be operated with the
keyboard.
o Drawing feature:
An authoring tool has a drawing feature that enables authors to
create, size, position and rotate drawing objects from the
keyboard.
· Related Resources:
o N/A
A.3.1.2 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 the Success Criterion A.3.1.2:
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. The user
might be able to move focus to the object (e.g., by "tab" key), but
is then unable to move the focus out using the keyboard because
keyboard control has passed to the embedded application.
· Examples that meet the Success Criterion:
o 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. In addition, when keyboard focus is in
the authoring tool's WYSIWYG editing view, authors can restore
focus to the authoring tool's menus at any time (i.e., by
pressing the "alt" key).
SN Comment: Remove “by the developer” – just needs to be tested,
don’t need to specify who does it.
o Non-web-based authoring tool:
A non-web-based authoring tool has a user interface that has
been thoroughly tested to ensure that no keyboard traps exist.
In addition, when keyboard focus is in the authoring tool's
WYSIWYG editing view, authors can restore focus to the
authoring tool's menus at any time (i.e., by pressing the "alt"
key).
o
o 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. In addition, because the authoring tool relies on
the authors' user agents to render the web content being
edited, the authoring tool can rely on a feature in the user
agent (that is cited in the conformance claim) which restores
focus to the address bar.
SN Comment: Remove “by the developer” – just needs to be tested,
don’t need to specify who does it.
o Web-based authoring tool:
A web-based authoring tool has a user interface that has been
thoroughly tested to ensure that no keyboard traps exist. In
addition, because the authoring tool relies on the authors'
user agents to render the web content being edited, the
authoring tool can rely on a feature in the user agent (that is
cited in the conformance claim) which restores focus to the
address bar.
o
· Related Resources:
o N/A
A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts.
(Level AA)
· Intent of the Success Criterion A.3.1.3:
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 that meet the Success Criterion:
o Non-web-based authoring tool:
An authoring tool provides keyboard shortcuts for menu of 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.
o 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:
o 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]
A.3.1.4 Customize Keyboard Access: The author(s) can customize keyboard
access to the authoring tool. (Level AAA)
· Intent of the Success Criterion A.3.1.4:
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 that meet the Success Criterion:
o Non-web-based authoring tool:
An 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).
o Web-based content management system:
A 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.
o 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:
o N/A
Guideline A.3.2 [For the authoring tool user interface] Provide authors
with enough time. [Return to Guideline]
Rationale: Some authors who have difficulty typing, operating the mouse, or
processing information can be prevented from using systems with short time
limits or requiring a fast reaction speed, such as clicking on a moving
target.
Recommended update:
Rationale: Some authors who have difficulty typing, operating the mouse, or
processing information can be prevented from using systems with time limits
or requiring a fast reaction speed, such as clicking on a moving target.
A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to
a time limit (e.g., an authenticated session expires), then the author(s)
have the global option to ensure that the web content being edited is
saved. (Level A)
Note: For web-based authoring tools, this applies to any web content that
has already been submitted to the server by the user agent.
· Intent of the Success Criterion A.3.2.1:
The intent of this success criterion is to ensure that the work an
author has produced is saved in the event that an authoring session
is ended due to a time limit. This is especially important for some
authors with disabilities who may take longer to accomplish tasks.
· Examples that meet the Success Criterion:
o Web-based content management system:
A content management system has a login timeout function that
automatically logs authors out after 20 minutes of inactivity.
The authors' work is automatically saved before they are logged
out for inactivity and a numerically incremented file name is
used in order to avoid overwriting authors' previously saved
versions.
o Wiki:
A wiki has an auto-save feature that can be turned on by
authors. The auto-save feature always saves before a login
timeout.
· Related Resources:
o N/A
A.3.2.2 Timing Adjustable: For each time limit that is set by the authoring
tool, at least one of the following is true: (Level A)
· (a) Turn off: The author(s) are allowed to turn off the time limit
before encountering it; or
· (b) Adjust: The author(s) are allowed to adjust the time limit before
encountering it over a wide range that is at least ten times the
length of the default setting; or
· (c) Extend: The author(s) are warned before time expires and given at
least 20 seconds to extend the time limit with a simple action (for
example, "press the space bar"), and the author(s) are allowed to
extend the time limit at least ten times; or
· (d) Real-time Exception: The time limit is a required part of a
real-time event (e.g., a collaborative authoring system), and no
alternative to the time limit is possible; or
· (e) Essential Exception: The time limit is essential and extending it
would invalidate the activity; or
· (f) 20 Hour Exception: The time limit is longer than 20 hours.
· Intent of the Success Criterion A.3.2.2:
The intent of this success criterion is to ensure that authoring
tools provide authors with disabilities adequate time to perform
their tasks. Any process that happens without author initiation after
a set time or on a periodic basis is a time limit. This includes
partial or full updates of the screen (for example, page refresh), or
the expiration of a window of opportunity for an author to react to a
request for input. It also includes user interface functionality that
is advancing or updating at a rate beyond the author's ability to
read and/or understand it. In other words, animated, moving or
scrolling information introduces a time limit. Generally, turning off
time limits is better than customizing the length of time limits,
which is better than requesting more time before a time limit occurs.
In some cases, however, it is not possible to change the time limit
(e.g., a collaborative authoring session) and exceptions are
therefore provided for those cases.
· Examples that meet the Success Criterion:
o Web-based content management system:
A content management system has a login timeout function that
automatically logs authors out after 20 minutes of inactivity.
One minute before the automatic log out, the system notifies
authors that the log out will occur unless they cancel the
notification (meeting (c)). The system also includes a
preference setting that lets authors set the timing of the
notification up to 10 minutes before the automatic logout
(meeting (b)).
o Real-time collaborative editing system:
A collaborative editing system allows multiple authors to edit
the same web content document simultaneously. An integral part
of the real-time collaborative activity is that any author may
edit or delete what others have just authored (meeting (d)).
· Related Resources:
o N/A
A.3.2.3 Moving Targets: If a user interface component is moving (e.g.,
animated vector graphic), then the author(s) have the option to stop the
movement. (Level A)
· Intent of the Success Criterion A.3.2.3:
The intent of this Success Criterion is to ensure that authors are
not prevented from using the authoring tool by a requirement for fast
reactions.
· Examples that meet the Success Criterion:
o Timeline-based authoring tool:
A timeline-based interactive web content editor has an
indicator of the current position on the timeline that authors
can click and drag. When the interactive web content is being
previewed, the indicator moves along the timeline which can
make it difficult to target with the mouse. In this case,
authors can stop the indicator from moving with the "Stop"
button.
· Related Resources:
o N/A
Guideline A.3.3 [For the authoring tool user interface] Help authors avoid
flashing that could cause seizures.[Return to Guideline]
Rationale: Flashing can cause seizures in authors with photosensitive
seizure disorder.
A.3.3.1 Static View Option: If an editing view renders time-based content
(e.g., animations), the author(s) have the global option of rendering only
the initial state of time-based web content. (Level A)
· Intent of the Success Criterion A.3.3.1:
The intent of this success criterion is to ensure that authors with
photosensitive seizure disorder can use the authoring tool to open
time-based web content without risk.
· Examples that meet the Success Criterion:
o Blog:
A blogging tool allows authors to import of video files.
Authors have the option to turn off an auto-play feature so
that the video files are not played until a "Play" button is
activated.
o WYSIWYG web page editor:
A WYSIWYG editing view is capable of rendering Javascript in
real time. Authors have the option to turn off the real time
rendering feature, so that the Javascript is not rendered until
a "Play" button is activated.
· Related Resources:
o N/A
Sueann Nichols
877-202-9272 (t/l) 930-0636
ssnichol@us.ibm.com
IBM Human Ability & Accessibility Center
http://www.ibm.com/able
Received on Friday, 16 October 2009 19:09:45 UTC