7.1
Use all applicable operating system and accessibility standards and
conventions (Priority 1 for standards and conventions that are essential to
accessibility; Priority 2 for those that are important to accessibility;
Priority 3 for those that are beneficial to accessibility).
The techniques for this checkpoint include references to checklists and
guidelines for a number of platforms and to general guidelines for accessible applications.Checkpoint 7.1
The
techniques for this checkpoint include references to checklists and
guidelines for a number of platforms and to general guidelines for accessible applications. This list
does not cover all requirements for all platforms, and items may not apply to
some software. In addition, not all of the guidelines and checklists for
application accessibility are prioritized according to their impact on
accessibility. For instance, the priorities in "The Microsoft Windows
Guidelines for Accessible Software Design" [MS-SOFTWARE] are partially
determined by a logo requirement program. Therefore, developers may need to
compare the documents they are using to other UAAG 1.0 [UAAG10] that has a priority
system that is directly compatible with the priorities in [ATAG10]. Also, when user
interfaces are built as Web content, they should follow the Web Content
Accessibility Guidelines 1.0 [WCAG10]. [Required] @@
- Following Standards
- Draw text and objects using system conventions.
- Make mouse, keyboard, and API
activation of events consistent.
- Provide a user interface that is "familiar" (to system
standards, or across platform).
- Use system standard indirections and APIs wherever
possible.
- Ensure all dialogs, subwindows, etc., satisfy these
requirements.
- Avoid blocking assistive technology functions (sticky/mouse
keys, screenreader controls, etc.) where possible.
- Configurability
- Allow users to create profiles.
- Allow control of timing, colors, sizes, input/output devices
and media.
- Allow users to reshape the user interface - customize
toolbars, keyboard commands, etc.
- Input Device Independence
- Provide Keyboard access to all functions.
- Document all keyboard bindings.
- Provide customizable keyboard shortcuts for common
functions.
- Provide logical navigation order for the keyboard
interface.
- Avoid repetitive keying wherever possible.
- Provide mouse access to functions where possible.
- Icons, Graphics, Sounds
- Provide graphical (text) equivalents for sound warnings.
- Allow sounds to be turned off.
- Provide text equivalents for images/icons.
- Use customizable (or removable) colors/patterns.
- Ensure high contrast is available (as default setting).
- Provide text equivalents for all audio.
- Use icons that are resizable or available in multiple
sizes.
- Layout
- Do not rely on color alone for meaning. Use color for
differentiation, in combination with accessible cues (text
equivalents, natural language, etc.).
- Position objects and their related text labels in a
consistent and obvious manner (labels before objects is
recommended).
- Group related controls.
- Ensure default window sizes fit in screen.
- Allow for window resizing (very small to very large).
- User Focus
- Clearly identify the user focus (and expose it via API).
- Viewing content (i.e., moving the focus to a new point)
should not cause unexpected events.
- Allow user control of timing (i.e., delays, time-dependent
response, etc.)
- Allow for navigation between as well as within windows.
- Documentation
- Provide documentation for all features of the tool.
- Ensure that help functions are accessible.
References:
- Guidelines for specific platforms include:
- Java:
"IBM Guidelines for Writing Accessible Applications
Using 100% Pure Java" [JAVA-ACCESS]
R. Schwerdtfeger, IBM Special Needs Systems.
- X Windows:
"An ICE Rendezvous Mechanism for X Window System
Clients" [ICE-RAP],
W. Walker. A description of how to use the ICE and RAP
protocols for X Window clients.
- MS Active Accessibility:
"Information for Developers About Microsoft Active
Accessibility" [MSAA]
Microsoft Corporation.
- X Windows:
"The Inter-Client communication conventions manual"
[ICCCM]. A
protocol for communication between clients in the X
Window system.
- Lotus Notes:
"Lotus Notes accessibility guidelines" [NOTES-ACCESS]
IBM Special Needs Systems.
- Java:
"Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
IBM Special Needs Systems.
- Java Swing:
"The Java Tutorial. Trail: Creating a GUI with JFC/Swing" [JAVA-TUT].
An online tutorial that describes how to use the Swing
Java Foundation Class to build an accessible User
Interface.
- Macintosh:
"Macintosh Human Interface Guidelines" [APPLE-HI]
Apple Computer Inc.
- MS Windows:
"The Microsoft Windows Guidelines for Accessible
Software Design"c [MS-SOFTWARE].
- Guidelines for specific software types include:
- Authoring Tools:
"The Three-tions of Accessibility-Aware HTML Authoring
Tools" [ACCESS-AWARE],
J. Richards.
- User Agents:
"User Agent Accessibility Guidelines (Working Draft)" J.
Gunderson, I. Jacobs eds. (This is a work in progress)
[UAAG10]
- General guidelines for producing accessible software
include:
- Microsoft:
"Accessibility for applications designers" [MS-ENABLE]
Microsoft Corporation.
- Trace:
"Application Software Design Guidelines" [TRACE-REF]
compiled by G. Vanderheiden. A thorough reference
work.
- Sun:
"Designing for Accessibility" [SUN-DESIGN]
Eric Bergman and Earl Johnson. This paper discusses
specific disabilities including those related to hearing,
vision, and cognitive function.
- EITAAG:
"EITAAC Desktop Software standards" [EITAAC]
Electronic Information Technology Access Advisory
(EITACC) Committee.
- US Sept. of Education:
"Requirements for Accessible Software Design" [ED-DEPT] US
Department of Education, version 1.1 March 6, 1997.
- IBM:
"Software Accessibility" [IBM-ACCESS]
IBM Special Needs Systems
- "Towards Accessible Human-Computer Interaction"
[SUN-HCI]
Eric Bergman, Earl Johnson, Sun Microsytems 1995. A
substantial paper, with a valuable print
bibliography.
- "What is Accessible Software" [WHAT-IS]
James W. Thatcher, Ph.D., IBM, 1997. This paper gives a
short example-based introduction to the difference
between software that is accessible, and software that
can be used by some assistive technologies.
7.2 Allow the author to change
the presentation within editing views
without affecting the document markup. [Priority 1]
This allows the author to edit the document according to personal
requirements, without changing the way the document is rendered when
published.Checkpoint
7.2
-
-
For tools with editing views, the author must have the ability to
change the fonts, colours, sizing, etc. within the editing view,
independently of the ability to control the markup that is actually
produced.
- For tools that display the source structure of a document using
graphic representations of tags, provide the author with the option of
displaying the text of the elements, instead (i.e., <html> rather
than ).
-
An authoring tool that offers a "rendered view" of a document, such as
a browser preview mode, may provide an editing view whose presentation
can be controlled independently of the rendered view.
- A WYSIWYG editor may allow an author to specify a local style sheet,
that will override the "published" style of the document in the editing
view.
- Allow the author to create audio style sheets using a graphical
representation rather than an audio one (with accessible
representation, of course).
7.3 Allow the author to edit all properties of
each element and
object in an accessible fashion. [Priority 1]
Checkpoint
7.3
- Allow the author to individually edit each attribute of the elements
in an HTML or XML document, for example, through a menu. This must
include the ability to add and edit later, values for all valid
attributes. (Suggested)
For tools that graphically represented element start and end tags,
text equivalent must be provided in order to be accessible to assistive
technologies that render text as Braille, speech, or large
print.(Suggested)
An authoring tool may offer several editing views of the same
document, such as a source mode that allows direct editing of all
properties.(Suggested)
For a site management tool, allow the author to render a site map in
text form (i.e., as a structured tree file).(Suggested)
Allow the author to specify that alternative information (or
identifiers such as a URI or filename) are rendered in place of images
or other multimedia content while editing.(Suggested)
Include attributes / properties of elements in a view of the
structure.(Suggested)
Provide access to a list of properties via a "context menu" for each
element.(Suggested)
7.4 Ensure that the editing view
allows navigation via the structure of the document in an accessible fashion.
[Priority 1]
Checkpoint
7.4
- To minimally satisfy this checkpoint, allow navigation from element
to element.(Suggested)
Allow the author to navigate via an "outline" or "structure" of the
document being edited. This is particularly important for people who
are using a slow interface such as a small Braille device, or speech
output, or a single switch input device. It is equivalent to the
ability provided by a mouse interface to move rapidly around the
document.(Suggested)
In a hypertext document, allow the author to navigate among links
and active elements of a document.(Suggested)
For time-based presentations (i.e., SMIL), allow the author to navigate
temporally through the presentation.(Suggested)
For an image expressed in a structured language (i.e., SVG), allow the
author to navigate regions of the image, or the document
tree.(Suggested)
Implement the HTML "accesskey"
attribute, and activate
it in editing views.(Suggested)
7.5 Enable editing of the
structure of the document in an accessible fashion. [Priority 2]
Checkpoint
7.5
-
An authoring tool may offer a structured tree view of the document that
allows the author to move among, select and cut, copy or paste elements
of the document.(Suggested)
A WYSIWYG
tool may allow elements to be selected, and copied or moved while
retaining their structure.(Suggested)
A tool may allow transformation from one element type to another, such
as (Suggested):
- HTML:
Paragraphs to lists and back
- HTML:
BR
to P
- SMIL:
Transformations between
switch
, excl
,
and par
- HTML:
FONT
(deprecated) into heuristically determined
structure
- MathML:
Transformations between semantic and presentation markup
- SVG:
g
to symbol
- Lists of lists to tables and back
- Giving a structural role to a part of an element, such as an SVG
g
or an HTML p
element
7.6 Allow the author to search
within editing
views. [Priority 2]
Checkpoint
7.6
-
Allow the user to search for a sequence of characters as a minimal
measure for meeting this checkpoint.[Required]
@@
More powerful searches can include the ability to perform searches that
are case sensitive or case-insensitive, the ability to replace a search
string, the ability to repeat a previous search to find the next or
previous occurrence, or to select multiple occurrences with a single
search.(Suggested)
The ability to search for a particular type of structure is useful in a
structured document, structured image such as a complex SVG image,
etc.(Suggested)
In an image editor, the ability to select an area by properties (such
as color, or closeness of color) is useful and common in middle range
and high end image processing software.(Suggested)
The ability to search a database for particular content, or to
search a collection of files at once (a simple implementation of the
latter is the Unix function "grep") is an important tool in managing
large collections, especially those that are dynamically converted into
Web content.(Suggested)
The use of metadata (per WCAG 1.0 [WCAG10]) can allow for
very complex searching of large collections, or of timed presentations.
Refer also to the paper "A Comparison of Schemas for Dublin Core-based
Video Metadata Representation" [SEARCHABLE] for
discussion specifically addressing timed multimedia
presentations.(Suggested)