This document provides guidelines for designing user agents that lower barriers to Web
accessibility for people with disabilities. User agents include browsers and other types
of software that retrieve and render Web content. A user agent that
conforms to these guidelines will
promote accessibility through its own user interface and through other internal
facilities, including its ability to communicate with other technologies
(especially assistive technologies).
Furthermore, all users, not just users with disabilities, should find
conforming user agents to be more usable.
In addition to helping developers of browsers and media players, this
document will also benefit developers of assistive technologies because it
explains what types of information and control an assistive technology may
expect from a conforming user agent. Technologies not addressed directly by
this document (e.g., technologies for braille rendering) will be essential to
ensuring Web access for some users with disabilities.
The "User Agent Accessibility Guidelines 2.0" (UAAG 2.0)
is part of a series of accessibility guidelines published by the W3C Web
Accessibility Initiative (WAI).
May be Superseded
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be
found in the W3C technical reports index at
http://www.w3.org/TR/.
W3C First Public Draft of UAAG 2.0
This is a First Public Working Draft of "UAAG 2.0". For more information, please see the UAAG 2.0 Requirements Document.
The Working Group expects for this document to become a
Working Group Note until such time as the group is recharted to produce
Recommendations under the W3C Patent Policy. At that point,
the group anticipates advancing it to W3C Recommendation
status.
Substantial changes since UAAG 1.0 include: (1) numerous clarifications and additions to the guidelines and success criteria as per the UAAG 2.0 Requirements Document, (2) restructuring the document into five principles similar to those used by WCAG 2.0 and ATAG 2.0, (3) adopting the three-priority level per guideline structure of WCAG 2.0 and ATAG 2.0, and (4) integrating the draft into a single document with streamlined introductory material.
The Working Group seeks feedback on the following points for this draft:
- Is the new organization of this document clear and understandable?
- Do these success criteria appear to cover the areas of greatest need with regard to browser and media player accessibility?
- Based on these preliminary success criteria, are there any concerns about implementation feasibility?
- Are there areas in which the new draft is lacking?
Comments on this working draft are due on or before 14 April 2008. Comments on the draft should be sent to public-uaag2-comments@w3.org (Public Archive).
Should UAAG 2.0 become a W3C Recommendation, it will supersede UAAG 1.0. Until that time User Agent Accessibility Guidelines 1.0 (UAAG 1.0) [UAAG10] is
the stable, referenceable version. This Working Draft does not supersede
UAAG 1.0.
Web Accessibility Initiative
This document has been produced as part of the W3C Web
Accessibility Initiative (WAI). The goals of the UAWG are discussed
in the Working Group charter.
The UAWG is part of the WAI
Technical Activity.
No Endorsement
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Patent Disclosures
This document was produced by a group operating under the 5
February 2004 W3C Patent Policy.
This document is informative only.
W3C maintains a public
list of any patent disclosures made in connection with the deliverables
of the group; that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual
believes contains Essential
Claim(s) must disclose the information in accordance with section
6 of the W3C Patent Policy.
Editing Styles:
- newly-approved-text: New changes to this draft
- proposed-text: Proposals that have not been accepted
- @@editor-notes@@: Notices from the editor(s).
This section is informative.
This document specifies requirements that, if satisfied by
user agent developers, will lower barriers
to accessibility.
A separate document, entitled "Implementation Techniques for User Agent Accessibility
Guidelines 2.0" (the "Techniques document" from here on) will be produced at a later date. It will provide
suggestions and examples of how each success criteria might be satisfied. It also
includes references to other accessibility resources (such as platform-specific
software accessibility guidelines) that provide additional information on how a
user agent may satisfy each success criteria. The techniques in the Techniques
document are informative examples only,
and other strategies may be used or required to satisfy the success criteria. The
UAWG expects to update the Techniques document more
frequently than the current guidelines. Developers, W3C Working Groups, users,
and others are encouraged to contribute techniques.
In this document, the term "user agent" is used in two
ways:
- The software and documentation components that together, conform to the requirements of this
document. This is the most common use of the term in this document and is the
usage in the guidelines.
- Any software that retrieves and renders Web content for users. This may
include Web browsers, browser extensions, media players, plug-ins,
and other programs — including assistive technologies —
that help in retrieving and rendering Web content.
Components of Web Accessibility
Web accessibility depends not only on accessible user agents, but also on the availability of accessible content, a factor that is greatly influenced by the accessibility of authoring tools. For an overview of how these components of Web development and interaction work together, see:
Levels of Conformance
User Agents may claim conformance
to UAAG 2.0 at one of three conformance levels. The level achieved depends
on the level of the success
criteria that have been satisfied. The conformance
levels are:
- UAAG 2.0 Conformance at Level "A"
The user agent satisfies all of
the Level A success criteria.
- UAAG 2.0 Conformance at Level "Double-A"
The user agent satisfies all of
the Level A and Level
AA success criteria.
- UAAG 2.0 Conformance at Level "Triple-A"
The user agent satisfies all of
the success criteria.
Other Issues
One of the goals of this document is to ensure that the requirements are compatible with other software design practices. However, this document does not purport to be a complete guide to good software design. For instance, the general topic of user interface design for computer software exceeds the scope of this document, though some user interface requirements have been included because of their importance to accessibility.
This document promotes conformance to other specifications as part of
accessible design (see Principle 1). Conformance to specifications makes it easier to design
assistive technologies, and helps ensure the implementation of built-in
accessibility functions.
This document also includes some requirements to implement an accessibility
feature that may only be optional in another specification. In rare cases, a requirement in UAAG 2.0 may conflict with a requirement in
another specification. UAAG 2.0 does not define a process for resolving such
conflicts. The authors of this document anticipate that developers will
consider accessibility implications in determining how to resolve them.
Installation is an important aspect of both accessibility and general
software usability. On platforms where a user can install a user agent, the
installation (and update and removal) procedures need to be accessible. Furthermore, the
installation procedure should provide and install all components necessary to
satisfy the requirements of this document, since the risk of installation
failure increases with the number of components (e.g., plug-ins) to be installed.
This document does not include a success criteria requiring that installation
procedures be accessible. Since this document considers installation to be part
of software usage, the different aspects of installation (e.g., user interface,
documentation, and operating environment
conventions) are already covered by the complete set of success criteria.
Some of the requirements of this document may have security implications,
such as communication through APIs, and allowing programmatic read and write
access to content and user interface control. This
document assumes that features required by this document will be built on top
of an underlying security architecture. Consequently, unless permitted
explicitly in a success criteria, this document grants no conformance
exemptions based on security issues.
Developers should design user agents that enable communication with trusted
assistive technologies. Sensitive information that the user agent can access
through the user agent's user interface should also be available to assistive
technologies through secure means. For instance, if the user types a password
in the user agent user interface, do not communicate substitute characters
(such as asterisks) through an API, but rather the real password, properly
encrypted.
This document emphasizes the goal of ensuring that users, including users
with disabilities, have control over their environment for accessing the Web.
Key methods for achieving that goal include: optional self-pacing,
configurability, device-independence, interoperability, direct support for both
graphical and auditory output, and adherence to published conventions.
This document also acknowledges the importance of author preferences and the
proper implementation of specifications. However, this document includes
requirements to override certain author preferences when the user would not
otherwise be able to access that content.
Many of the requirements in this document give the user additional control
over behavior that would otherwise occur automatically. For instance, there is
a requirement to allow configuration to not open a viewport automatically
and one that requires user confirmation before submitting a form. This type of manual configuration option may be essential for some
users with disabilities, since automatic behavior may be disorienting or
interfere with navigation.
This document includes requirements for users with a variety of
disabilities, in part because some users may have more than one disability. In
some cases, it may appear that two requirements contradict each other. For
instance, a user with a physical disability may prefer that the user agent
offer more automatic behavior (to reduce demand for physical effort) than a
user with a cognitive disability (for whom automatic behavior may cause
confusion). Thus, many of the requirements in this document involve
configuration as one way to ensure that a functionality designed to improve
accessibility for one user does not interfere with accessibility for another.
Also, since a default user agent setting may be useful for one user but
interfere with accessibility for another, this document prefers configuration
requirements to requirements for default settings. Finally, there may be some
cases where, for some content, a feature required by this document is
ineffective or causes content to be less accessible, making it imperative that
the user be able to turn off the feature.
To avoid overwhelming users with an abundance of configuration options, this
document includes requirements that promote ease of configuration and
documentation of accessibility features.
Many requirements in this document promote different kinds of
independence:
- Input and output device independence. This document includes some
requirements to promote device-independence natively, as well as requirements
for interoperability with assistive technologies that provide complementary
input and output functionalities.
- Spatial independence. Some users may not navigate effectively in
two-dimensional visual space
(e.g., users who do not use a pointing device) or may be constrained to one
temporal dimension (e.g., users of audio-only output).
- Temporal independence. Some users (e.g., users with a physical or cognitive
disability) may not be able to interact with content that changes over time, or
interaction with content that is time-sensitive.
In meeting the goals of users with disabilities, user agent developers will
also improve access to the Web for users in general. For example, users without
disabilities:
- may have a text-only screen, a small screen, or a slow Internet connection
(e.g., via a mobile phone browser). These users are likely to benefit from the
same features that provide access to people with low vision or blindness.
- may be in a situation where their eyes, ears, or hands are busy or
interfered with (e.g., driving to work or working in a noisy environment).
These users are likely to benefit from the same features that provide access to
people who cannot use a mouse or keyboard due to a visual, hearing, or physical
disability.
- may not understand fluently the natural language of spoken content. These
users are likely to benefit from the same visual rendering of
text equivalents that make spoken
language accessible to people with a hearing disability.
The UAWG expects that software which satisfies the requirements of this
document will be more flexible, manageable, extensible, and beneficial to all
users. For example, a user agent architecture that allows programmatic access
to content and the user interface will encourage software
modularity and reuse, and will enable operation by scripting tools and
automated test engines in addition to assistive technologies.
UAAG 2.0 Guidelines
PRINCIPLE 1. Follow applicable specifications and conventions
Guideline 1.1 Observe operating environment conventions [Techniques]
Level A Success Criteria for Guideline 1.1
- 1.1.1 Follow and Cite Conventions: Operating environment conventions are followed and the convention sources are cited for all of the following:
- (a) Input: Keyboard, mouse, etc. including non-interference with keyboard accessibility features of the operating environment (e.g., StickyKeys, SlowKeys, browser link navigation)@@7.2 in UAAG10@@
- (b) Content Focus and User Interface Focus @@7.1 in UAAG10@@
- (c) Selection, and @@7.1 in UAAG10@@
- (d) Product installation.@@7.3 in UAAG10@@
Level AA Success Criteria for Guideline 1.1
- 1.1.2 Follow and Cite Conventions: Operating environment conventions are followed and the convention sources are cited for all of the following:
Level AAA Success Criteria for Guideline 1.1
- (No level AAA success criteria for Guideline 1.1)
Guideline 1.2 Support accessibility
features of technologies [Techniques]
Level A Success Criteria for Guideline 1.2
- 1.2.1 Accessibility Features: The accessibility features listed in the "technology accessibility features benchmark" @@Ed: Definition of this term will likely let claimant specify these in the conformance claim@@ are implemented for all technologies listed in the conformance profile.@@8.1 in UAAG10@@
Level AA Success Criteria for Guideline 1.2
- (No level AA success criteria for Guideline 1.2)
Level AAA Success Criteria for Guideline 1.2
- (No level AAA success criteria for Guideline 1.2)
Guideline 1.3 Render content according to
specification [Techniques]
Level A Success Criteria for Guideline 1.3
- 1.3.1 Follow Specifications: Render content according to the technology specification. This includes any accessibility features of the technology (see Guideline 1.2) . @@2.1 in UAAG10@@
Level AA Success Criteria for Guideline 1.3
- 1.3.2 Handle Unrendered Technologies: If the user agent does not render a technology, it allows the user to choose a way to handle content in that technology (e.g., by
launching another application or by saving it to disk).@@NEW@@
Level AAA Success Criteria for Guideline 1.3
- (No level AAA success criteria for Guideline 1.3)
Note: When a rendering requirement of another specification contradicts a
requirement of UAAG 2.0, the user agent may disregard the rendering requirement
of the other specification and still satisfy this guideline.
PRINCIPLE 2. Facilitate access
by assistive technologies
Guideline 2.1 Programmatic access to HTML/XML infoset [Techniques] @@6.1 NEEDS WORK@@
Level A Success Criteria for Guideline 2.1
- 2.1.1: Programmatic read access to XML content is provided by making available all of the information items defined by the W3C XML Infoset [INFOSET].
- 2.1.2: Programmatic read access to HTML
content is provided by making available all of the
following information items defined by the W3C XML Infoset
[INFOSET]:
- (a) Document Information item: children, document element, base URI, charset
- (b) Element Information items: element-type name, children, attributes, parent
- (c) Attribute Information items: attribute-type name, normalized value, specified, attribute type, references, owner element
- (d) Character Information items: character code, parent element
- (e) Comment Information items: content, parent
- 2.1.3: If the user can modify the state or value of a
piece of HTML or XML content through the user interface (e.g., by checking a
box or editing a text area), programmatic read access to the current
state or value is available with the same degree of write access programmatically as
is available through the user interface.
Level AA Success Criteria for Guideline 2.1
- (No level AA success criteria for Guideline 2.1)
Level AAA Success Criteria for Guideline 2.1
- (No level AAA success criteria for Guideline 2.1
Guideline 2.2 DOM access to HTML/XML content [Techniques] @@6.2 NEEDS WORK@@
Level A Success Criteria for Guideline 2.2
- 2.2.1: Access to the content required in guideline 2.1 is provided by conforming
to the following modules of the W3C Document Object Model
(DOM) Level 2 Core
Specification [DOM2CORE] and exporting bindings
for the interfaces they define:
- (a) for HTML: the Core module
- (b) for XML: the Core and XML modules
- 2.2.2: As part of satisfying Success Criterion 2.2.1:
- (a) In Java and ECMAScript operating environments: the normative
bindings specified in the DOM Level 2 Core Specification [DOM2CORE] are exported, or
- (b) In other operating environments: the exported bindings (e.g., C++) are
publicly documented.
Level AA Success Criteria for Guideline 2.2
- (No level AA success criteria for Guideline 2.2)
Level AAA Success Criteria for Guideline 2.2
- (No level AAA success criteria for Guideline 2.2)
Normative inclusions and exclusions @@from UAAG10@@
- Refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about
which versions of HTML, XML, Java, and
ECMAScript are covered. Appendix
D contains the Java bindings and Appendix E contains the ECMAScript bindings.
- The user agent is not required to export the bindings outside of the user
agent process (though doing so may be useful to assistive technology
developers).
@@Note: This guideline stands apart from guideline 2.1 to emphasize
the distinction between what information is required and how to provide access
to that information. Furthermore, the DOM Level 2 Core Specification does not
provide access to current states and values referred to in provision three of guideline 2.1. For HTML
content, the interfaces defined in [DOM2HTML] do provide access to
current states and values.
Guideline 2.3 Programmatic access to non-HTML/XML
content [Techniques] @@6.3 NEEDS WORK@@
Level A Success Criteria for Guideline 2.3
- 2.3.1: For content
other than HTML and XML, structured programmatic read access to
content is provided.
- 2.3.2: If the user can modify the state or value
of a piece of non-HTML/XML content through the
user interface
(e.g., by checking a
box or editing a text area), programmatic read access to the current
state or value is allowed with the same degree of write access programmatically as
is available through the user interface.
- 2.3.3: As part of satisfying Success Criterion 2.3.1, at least one
API is implemented, according
to this API cascade:
- (a) The API is defined by a W3C Recommendation, or the API is
publicly documented and designed to enable interoperability with assistive
technologies.
- (b) If no such API is available, or if available APIs do not enable the user
agent to satisfy the requirements,
Level AA Success Criteria for Guideline 2.3
- (No level AA success criteria for Guideline 2.3)
Level AAA Success Criteria for Guideline 2.3
- (No level AAA success criteria for Guideline 2.3)
Normative inclusions and
exclusions @@from UAAG10@@
- "Structured programmatic access" means access through an API to recognized
information items of the content (such as the information items of the XML
Infoset [INFOSET]). Plain text has little
structure, so an API that provides access to it will be correspondingly less
complex than an API for XML content. For content more structured than plain
text, an API that only provides access to a stream of characters does not
satisfy the requirement of providing structured programmatic access. This
document does not otherwise define what is sufficiently structured access.
- An API is considered "available" if the specification of the API is
published (e.g., as a W3C Recommendation) in time for integration into a user
agent's development cycle
Note: This guideline addresses content not covered by
guidelines 2.1 and 2.2.
Guideline 2.4 Programmatic access to
information about rendered content [Techniques] @@6.4 NEEDS WORK@@
Level A Success Criteria for Guideline 2.4
- 2.4.1: For graphical user agents, the bounding dimensions and coordinates of rendered graphical objects are made available. Coordinates
are relative to the point of origin in the graphical environment (e.g.,
with respect to the desktop), not the viewport.
- 2.4.2: For graphical user agents, the following information is available about each piece of rendered text:
- (a) font family
- (b) font size
- (c) foreground and,
- (d) background colors.
- 2.4.3: As part of satisfying provisions one and
two of this guideline, least one API is implemented according to the API cascade
described in Success Criterion 2.3.3 .
Level AA Success Criteria for Guideline 2.4
- (No level AA success criteria for Guideline 2.4)
Level AAA Success Criteria for Guideline 2.4
- (No level AAA success criteria for Guideline 2.4)
Note: User agents should provide programmatic access to
additional useful information about rendered content that is not available
through the APIs required by guidelines 2.2 and 2.3, including the correspondence (in both directions)
between graphical objects and their source in the document object, and information
about the role of each graphical object.
Guideline 2.5 Programmatic operation of user agent
user interface [Techniques] @@6.5 NEEDS WORK@@
Level A Success Criteria for Guideline 2.5
- 2.5.1: Programmatic read access is provided to user agent user interface
controls, selection, content focus, and user interface focus.
- 2.5.2: If the user can modify the state or value of a user agent user interface
control (e.g., by checking a box or editing a text area), programmatic read access is allowed to the current state or value with the same
degree of write access programmatically as is available through the user
interface.
- 2.5.3: As part of satisfying 2.5.1 and 2.5.2, implement at least one API according to the API cascade
described in in Success Criterion 2.3.3.
Level AA Success Criteria for Guideline 2.5
- (No level AA success criteria for Guideline 2.5)
Level AAA Success Criteria for Guideline 2.5
- (No level AAA success criteria for Guideline 2.5)
Note: APIs used to satisfy the requirements of this
guideline may vary. For instance, they may be independent of a particular
operating environment (e.g., the W3C DOM), or the conventional APIs for a
particular operating environment, or the conventional APIs for programming
languages, plug-ins, or virtual machine
environments. User agent developers are encouraged to implement APIs that allow
assistive technologies to interoperate with multiple types of software in a
given operating environment (e.g., user agents, word processors, and
spreadsheet programs), as this reuse will benefit users and assistive
technology developers. User agents should always follow operating environment
conventions for the use of input and output APIs.
Guideline 2.6 Programmatic notification of changes [Techniques] @@6.6 NEEDS WORK@@
Level A Success Criteria for Guideline 2.6
Level AA Success Criteria for Guideline 2.6
- (No level AA success criteria for Guideline 2.6)
Level AAA Success Criteria for Guideline 2.6
- (No level AAA success criteria for Guideline 2.6)
Normative inclusions and exclusions @@from UAAG10@@
- The user agent is not required to provide notification of changes in the rendering of content (e.g., due to an animation effect or an effect
caused by a style sheet) unless the document object is modified as part
of those changes.
- Conformance
profile labels: Selection
- Conformance detail: For both content and user agent
Note: For instance, provide programmatic notification when
user interaction in one frame causes automatic changes to content in
another.
Guideline 2.7 Conventional keyboard APIs [Techniques] @@6.7 NEEDS WORKs@@
Level A Success Criteria for Guideline 2.7
Level AA Success Criteria for Guideline 2.7
- (No level AA success criteria for Guideline 2.7)
Level AAA Success Criteria for Guideline 2.7
- (No level AAA success criteria for Guideline 2.7)
Note: An operating environment may define more than one
conventional API for the keyboard. For instance, for Japanese and Chinese,
input may be processed in two stages, with an API for each stage.
Guideline 2.8 API character encodings [Techniques]@@6.8 NEEDS WORK@@
Level A Success Criteria for Guideline 2.8
- 2.8.1: For an API implemented to satisfy
requirements of this document, the character encodings required for
that API are supported.
Level AA Success Criteria for Guideline 2.8
- (No level AA success criteria for Guideline 2.8)
Level AAA Success Criteria for Guideline 2.8
- (No level AAA success criteria for Guideline 2.8)
Normative inclusions and exclusions @@from UAAG10@@
- Conformance detail: For both content and user agent
Note: Support for character encodings is an important part
of ensuring that text is correctly communicated to assistive technologies. For
example, the DOM Level 2 Core Specification [DOM2CORE], section 1.1.5
requires that the DOMString type be encoded using UTF-16.
Guideline 2.9 DOM access to CSS style sheets [Techniques] @@6.9 NEEDS WORK@@
Level A Success Criteria for Guideline 2.9
- (No level A success criteria for Guideline 2.9)
Level AA Success Criteria for Guideline 2.9
- 2.9.1: For user agents that implement Cascading Style Sheets
(CSS), programmatic access to style sheets is provided by
conforming to the CSS module of the W3C Document Object Model
(DOM) Level 2 Style
Specification [DOM2STYLE] and exporting
bindings for the interfaces it defines.
- 2.9.2: As part of satisfying 2.9.1 of this
guideline:
- (a) In the Java and ECMAScript operating environments: the normative
bindings specified in the CSS module of the DOM Level 2
Style Specification [DOM2STYLE] are exported, or
- (b) In other operating environments: the exported bindings (e.g., C++) are
publicly documented.
Level AAA Success Criteria for Guideline 2.9
- (No level AAA success criteria for Guideline 2.9)
Normative inclusions and exclusions @@from UAAG10@@
- For the purposes of satisfying this guideline, Cascading Style Sheets
(CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2].
- Refer to the "Document Object Model (DOM) Level 2 Style Specification" [DOM2STYLE] for information
about which versions of Java and ECMAScript are covered. Appendix B contains the Java bindings and Appendix C contains the ECMAScript bindings.
- The user agent is not required to export the bindings outside of the user
agent process.
Guideline 2.10 Timely exchanges through APIs [Techniques] @@6.10 NEEDS WORK@@
Level A Success Criteria for Guideline 2.10
- (No level A success criteria for Guideline 2.10)
Level AA Success Criteria for Guideline 2.10
- 2.10.1: For APIs implemented to satisfy the requirements of this document, programmatic exchanges proceed in a timely manner.
Level AAA Success Criteria for Guideline 2.10
- (No level AAA success criteria for Guideline 2.10)
Note: For example, the programmatic exchange of information
required by other guidelines in this document should be efficient enough to
prevent information loss, a risk when changes to content or user interface
occur more quickly than the communication of those changes. Timely exchange is
also important for the proper synchronization of alternative renderings. The
techniques for this guideline explain how developers can reduce communication
delays. This will help ensure that assistive technologies have timely access to
the document object model and other
information that is important for providing access.
PRINCIPLE 3: Ensure that the user interface is perceivable
Guideline 3.1 Provide text alternatives for non-text components [Techniques]
Level A Success Criteria for Guideline 3.1
Level AA Success Criteria for Guideline 3.1
- (No level AA success criteria for Guideline 3.1)
Level AAA Success Criteria for Guideline 3.1
- (No level AAA success criteria for Guideline 3.1)
Guideline 3.2 Provide access to alternative content [Techniques]
Level A Success Criteria for Guideline 3.2
- 3.2.1 Alert to Non-Rendered: The user has the option to be alerted to the presence of non-rendered alternative content (e.g., short text alternatives, long descriptions, captions, audio descriptions) for any given piece of rendered content. (Note: The rendered content and its non-rendered alternatives constitute the alternative content stack). @@Implied in 2.3 in UAAG10@@
- 3.2.2 Browse and Render: The user can browse the alternative content stack and render its items according to the following:
- (a) synchronized alternatives for synchronized media (e.g., captions, audio descriptions, sign language) can be rendered at the same time as their associated audio tracks and visual tracks, and @@Implied in 2.3 in UAAG10@@
- (b) non-synchronized alternatives (e.g., short text alternatives, long descriptions) can be rendered as replacements for the original rendered content. If the new item has different dimensions, then a user option controls whether the dimensions of the original content are used or the dimensions of the new content, which will cause the document to reflow accordingly.@@Implied in 2.3 in UAAG10@@
- 3.2.3 Available Programmatically: If an item in the alternative content stack is plain text (e.g., short text alternative), then it is available programmatically, even when not rendered. @@Implied in 2.3 in UAAG10@@
Level AA Success Criteria for Guideline 3.2
- 3.2.4 Simultaneous Rendering: The user has the option to simultaneously render any and all items from the alternative content stack (which will cause the document to reflow accordingly) unless the user agent can recognize a mutual exclusion (e.g. conflicting soundtracks).@@NEW@@
- 3.2.5 Configurable Default Rendering: The user has the option to set preferences for which items in an alternative content stack will be rendered by default. @@2.9 in UAAG10@@
Level AAA Success Criteria for Guideline 3.2
- (No level AAA success criteria for Guideline 3.2)
@@New Technique 3.2.5=User agents should expose configuration choices in as highly visible a fashion as is practical such as on a menu entry or dialog settings devoted to accessibility@@.
Guideline 3.3 Provide control of content that may reduce accessibility [Techniques]
Note: The guideline only applies to images, animations, video, audio, etc. that the user agent can recognize.
Level A Success Criteria for Guideline 3.3
- 3.3.1 Background Image Toggle: The user has the option to hide/show background images@@DEFINE@@ (i.e., images that are rendered on the base background). @@3.1 in UAAG10@@
- 3.3.2 Audio Load-Only: The user has the option to load audio content such that it does not play until explicit user
request.@@NEW@@
- 3.3.3 Animation Load-Only: The user has the option to load animation content (including video
or animated images) such that the first frame is displayed, but the animation content is not played until explicit user
request.@@NEW@@
- 3.3.4 Execution Toggle: The user has the option to turn on/off the execution of executable content that would not normally be contained within a particular area (e.g., Javascript).@@3.4 in UAAG10@@
- 3.3.5 Execution Placeholder: The user has the option to render a placeholder instead of executable content that would normally be contained within an on-screen area (e.g., Applet, Flash), until explicit user
request to execute.@@NEW@@
- 3.3.6 Unavailable Content: If a resource is unavailable, render the next item on the alternative content stack, if any. Otherwise render a placeholder.@@NEW@@
- 3.3.7 Retrieval Progress: Show the progress of content retrieval. @@NEW@@
- 3.3.8 Slow Multimedia: The user can slow the presentation rate
of recognized prerecorded audio and animation content, such that all of the following are true:@@4.4 in UAAG10@@
- if only an audio track is present, provide at least one setting between 75% and 80% of the
original speed.
- if a visual track is present, provide at
least one setting between 40% and 60% of the original speed.
- when audio and video tracks are synchronized: above 75% of the original speed, maintain synchronization; below 75% the user agent is not required to render the audio track.
- 3.3.9 Stop/Pause/Resume Multimedia: The user can stop, pause, and resume
rendered audio and animation content (including
video and animated images) that last three or more seconds at their default
playback rate.@@4.5 in UAAG10@@
- 3.3.10 Navigate Multimedia: The user can navigate efficiently
within rendered audio and animations (including video and animated
images) that last three or more seconds at their default playback
rate.@@4.5 in UAAG10@@
Level AA Success Criteria for Guideline 3.3
- (No level AA success criteria for Guideline 3.3)
Level AAA Success Criteria for Guideline 3.3
- (No level AAA success criteria for Guideline 3.3)
@@Tech=Provide the user with the ability to toggle whether the base user agent executes content that it is able to . - if cond. content exists reveal it (2.3)
@@Tech=Provide the user with the ability to toggle the loading of plugins that execute content the base browser is unable to execute - if cond. content exists reveal it (2.3)
Guideline 3.4 Provide access to relationship information [Techniques] @@NEW 10.1@@
Level A Success Criteria for Guideline 3.4
- 3.4.1 Relationships Available Programmatically: Make explicitly-defined relationships in the content (e.g., labeled_by, table_header_for, etc.) available programmatically. @@Expanded 10.1 in UAAG10@@
- 3.4.2 Access Relationships: The user can access information from explicitly-defined relationships in the content (e.g., what is form control's label?, what is label's form control?, what is cell's table header?, etc.). @@Expanded 10.1 in UAAG10@@
Level AA Success Criteria for Guideline 3.4
- 3.4.3 Location in Hierarchy: For content in a hierarchy (e.g., tree node, nested frame), the user can view the path of nodes leading from the root to the content.@@NEW@@
Level AAA Success Criteria for Guideline 3.4
- (No level AAA success criteria for Guideline 3.4)
Guideline 3.5 Repair missing content [Techniques]
Level A Success Criteria for Guideline 3.5
Level AA Success Criteria for Guideline 3.5
- (No level AA success criteria for Guideline 3.5)
Level AAA Success Criteria for Guideline 3.5
- 3.5.2 Repair Empty Alternatives: The user has the option of receiving generated repair text when the user agent recognizes that the author has provided empty alternative
content for an enabled element. @@2.8 in UAAG10@@
Guideline 3.6 Provide highlighting for selection, content
focus, enabled elements, visited links [Techniques]
Level A Success Criteria for Guideline 3.6
- 3.6.1 Highlighted items: The user has the option to highlight the following classes of information:
@@10.2 in UAAG10@@
- (a) selection,
- (b) content focus,
- (c) recognized enabled elements, and
- (d) recently visited links.@@Remove since so common?@@
- 3.6.2 Highlighting options: The highlighting options (with the same configurable range as the platform's conventional selection utilities) include at least:@@10.2 in UAAG10@@
- (a) foreground colors,
- (b) background colors, and
- (c) borders (with configurable color and width).
Level AA Success Criteria for Guideline 3.6
- (No level AA success criteria for Guideline 3.6)
Level AAA Success Criteria for Guideline 3.6
- (No level AAA success criteria for Guideline 3.6)
Guideline 3.7 Provide text configuration [Techniques] @@4.1, 4.2, 4.3 in UAAG10@@
Level A Success Criteria for Guideline 3.7
- 3.7.1 Configure Text: The user can globally set the following characteristics of visually rendered text content, overriding any specified by
the author or user agent defaults:
- (a) text scale (i.e., the general size of text) ,@@4.1 in UAAG10@@
- (b) font family, and @@4.2 in UAAG10@@
- (c) text color (i.e., foreground and background).@@4.3 in UAAG10@@
- 3.7.2 Preserve Distinctions: When rendered text is rescaled, distinctions in the size of rendered text are preserved (e.g., headers continue to be larger than body text).@@4.1 in UAAG10@@
- 3.7.3 Option Range: The range of options for each text characteristic includes at least:
- (a) the range offered by the conventional utility available in the operating environment, or
- (b) if no such utility is available, the range supported by the
conventional APIs of the
operating environment for drawing text.
Level AA Success Criteria for Guideline 3.7
- (No level AA success criteria for Guideline 3.7)
Level AAA Success Criteria for Guideline 3.7
- 3.7.4 Maintain contrast: The user has the option to constrain the configuration of the default text foreground color, background
color and highlighting colors, so that text contrast is maintained between them. @@NEW@@
Guideline 3.8 Provide volume configuration [Techniques]
Level A Success Criteria for Guideline 3.8
- 3.8.1 Global Volume: The user can globally set the
volume of all rendered audio tracks (including a "mute" setting) through available operating environment mechanisms. @@4.7 in UAAG10@@
- 3.8.2 Speech Volume: If speech and non-speech audio tracks can be recognized, then the user can set the volume of these two types of audio tracks independently. @@NEW 4.8@@
Level AA Success Criteria for Guideline 3.8
- (No level AA success criteria for Guideline 3.8)
Level AAA Success Criteria for Guideline 3.8
- (No level AAA success criteria for Guideline 3.8)
Guideline 3.9 Provide synthesized speech configuration [Techniques]
Level A Success Criteria for Guideline 3.9
- 3.9.1 Speech Characteristics: The user can set both of the following synthesized speech characteristics, overriding any values specified by
the author:
@@4.9,4.10 in UAAG10@@
- (a) speech rate and
- (b) speech volume (independently of other sources of
audio).
- 3.9.2 Option Range: The user can set all of the speech characteristics offered by the speech synthesizer, according to the full range of values available, overriding any values specified by
the author:
@@4.11 in UAAG10@@
Level AA Success Criteria for Guideline 3.9
- 3.9.3 Speech Characteristics: The user can set all of the following synthesized speech characteristics,
overriding any values specified by
the author:
@@4.12 in UAAG10@@
- (a) pitch ("pitch" refers to the average frequency of the speaking voice),
- (b) pitch range ("pitch range" specifies a variation in average frequency), and
- (c) speech stress.
("speech stress" refers to the height of "local peaks" in the intonation contour of the
voice).@@richness deleted since not in CSS3 http://www.w3.org/TR/2004/WD-css3-speech-20041216/@@
- 3.9.4 Speech Features: The following speech features are provided:
@@4.13 in UAAG10@@
- (a) user-defined extensions to the synthesized speech dictionary,
- (b) "spell-out", where text is spelled
one character at a time, or according to language-dependent pronunciation
rules,
- (c) at least two ways of speaking numerals: one
where numerals are spoken as individual digits, and one where full numbers are
spoken, and
- (d) at least two ways of speaking punctuation: one where punctuation is spoken literally, and one where punctuation is
rendered as natural pauses.
Level AAA Success Criteria for Guideline 3.9
- (No level AAA success criteria for Guideline 3.9)
Guideline 3.10 Provide style sheets
configuration
[Techniques]
Level A Success Criteria for Guideline 3.10
Level AA Success Criteria for Guideline 3.10
- (No level AA success criteria for Guideline 3.10)
Level AAA Success Criteria for Guideline 3.10
- (No level AAA success criteria for Guideline 3.10)
Guideline 3.11 Help user to use and orient within viewports [Techniques]
Level A Success Criteria for Guideline 3.11
- 3.11.1 Highlight Viewport: The viewport with the current focus is highlighted (including any frame that
takes current focus) using a highlight
mechanism that does not rely on rendered text foreground and background
colors alone (e.g., a thick outline).@@10.6 in UAAG10@@
- 3.11.2 Move Viewport to Selection: When a viewport's selection changes, the viewport moves as necessary to ensure that the new selection is at least
partially in the viewport.@@5.4 in UAAG10@@
- 3.11.3 Move Viewport to Focus: When a viewport's content focus changes, the viewport moves as necessary to ensure that the new content focus is at least
partially in the viewport.@@5.4 in UAAG10@@
- 3.11.4 Resizable: The user has the option to make graphical viewports resizable, within the limits of the display, overriding any values specified by
the author.@@NEW@@
- 3.11.5 Scrollbars: Graphical viewports include scrollbars if the rendered content (including after user preferences have been applied) extends beyond the viewport dimensions, overriding any values specified by
the author.@@NEW@@
- 3.11.6 Viewport History: If the user agent maintains a viewport history mechanism (e.g., via the "back button") that stores previous "viable" states (i.e., that have not been negated by the content, user agent settings or user agent extensions), it maintains
information about the point of regard and it restores the saved values when the user returns to a state in the history.@@9.4 in UAAG10@@
Level AA Success Criteria for Guideline 3.11
- 3.11.7 Open on Request: The user has the option of having "top-level" viewports (e.g., windows) only open
on explicit user request. In this mode, instead of opening a viewport automatically, alert the user and
allow the user to open it with an explicit request (e.g., by
confirming a prompt or following a link generated by the user agent).@@5.3 in UAAG10@@
- 3.11.8 Do Not Take Focus: When configured to allow "top-level" viewports to open without explicit user request, the user has the option that if a "top-level" viewport opens, neither
its content focus nor its user interface focus automatically becomes the current focus.@@5.1 in UAAG10@@
- 3.11.9 Stay on Top: The user has the option of having the viewport with the current focus remain "on top" of all
other viewports with which it overlaps.@@5.2 in UAAG10@@
- 3.11.10 Close Viewport: The user can close any "top-level" viewport.@@5.3 in UAAG10@@
- 3.11.11 Same UI: The user has the option of having all "top-level" viewports follow the same user interface configuration as the current or spawning viewport, including the same "chrome".@@NEW@@
Level AAA Success Criteria for Guideline 3.11
- 3.11.12 Indicate Viewport Position: Indicate the viewport's position relative to rendered content (e.g., the proportion along an audio or video timeline, the
proportion of a Web page before the current position ).@@10.7 in UAAG10@@
Guideline 3.12 Provide an effective focus mechanism [Techniques]
Level A Success Criteria for Guideline 3.12
- 3.12.1 Content Focus: At least one content focus is provided for each viewport (including frames), where enabled elements are part of the rendered
content. @@ 9.1 in UAAG10@@
- 3.12.2 Current Focus: The user can make the content focus of
each viewport the current focus. @@ 9.1 in UAAG10@@
- 3.12.3 User Interface Focus: A user interface
focus is provided. @@from 9.2 in UAAG10@@
- 3.12.4 Extensions Focusable: The user interface focus can navigate within extensions to the user interface "chrome". @@If it knows how to insert and render the extension in its chrome, then it should have good enough programmatic access and knowledge to properly give focus. - Tech XUL spec for FF@@
- 3.12.5 Hand-Off Focus: The user agent programmatically notifies any nested user agent(s) (e.g., plug-ins) when focus moves to them.@@NEW@@
- 3.12.6 Retrieve Focus: At any time, the user agent is able to retrieve focus from a nested viewport (including nested viewports that are user agents).@@NEW@@
- 3.12.7 Return Focus: Embedded user agents are responsible for notifying embedding user agent that focus should move back to it. @@Embedded user agents must write to AccessAPI and HTML DOM if applicable@@
- 3.12.8 Bi-Directional: The user can move the content focus forward or backward to any enabled element in the viewport.@@ 9.3, 9.7 in UAAG10@@
- 3.12.9 Sequential Navigation: If
the author has not specified a navigation order, the default is sequential
navigation, in document order.@@ 9.3 in UAAG10@@
- 3.12.10 Only on User Request: The user has the option of having the content focus of
a viewport only change on explicit user request.@@ 9.3 in UAAG10@@
- 3.12.11 On Focus: The user has the option of ensuring that moving the content focus to or from an enabled element does not cause the user agent to take any further action.@@9.5 in UAAG10@@
Level AA Success Criteria for Guideline 3.12
- (No level AAA success criteria for Guideline 3.12)
Level AAA Success Criteria for Guideline 3.12
- (No level AAA success criteria for Guideline 3.12)
Guideline 3.13 Provide alternative views [Techniques]
Level A Success Criteria for Guideline 3.13
Level AA Success Criteria for Guideline 3.13
- 3.13.2 Outline View: An "outline"
view of rendered content is provided,
composed of labels for important structural elements (e.g., heading text, table
titles, form titles, and other labels that are part of the content). Note: What constitutes a label is defined by each markup language specification.
For example, in HTML, a heading (
H1-H6) is a label
for the section that follows it, a CAPTION is a label for a table,
and the title attribute is a label for its element.@@10.4 in UAAG10@@
Level AAA Success Criteria for Guideline 3.13
- 3.13.3 Configure Set of Important Elements: The user has the option to configure the set of important
elements for the "outline" view, including by element type (e.g., headers). @@9.10 in UAAG10@@
Guideline 3.14 Provide link information [Techniques]
Level A Success Criteria for Guideline 3.14
- 3.14.1 Basic Link Information: The following
information is provided for each link:
@@10.5 in UAAG10@@
- (a) link element content,
- (b) link title,
- (c) technology type: of the linked Web resource,
- (d) internal/external: whether the link is internal to the resource (e.g., the link is to a target
in the same Web page),
- (e) new viewport: whether the author has specified that the resource will open in a new viewport.
Level AA Success Criteria for Guideline 3.14
- (No level AA success criteria for Guideline 3.14)
Level AAA Success Criteria for Guideline 3.14
- 3.14.2 Extended Link Information: The following
information is provided for each link:
@@10.5 in UAAG10@@
- (a) visited: whether the user has visited the the linked Web resource recently,
- (c) size: the size of the linked Web resource,
- (c) language: natural language of linked Web resource.
PRINCIPLE 4. Ensure that the user interface is operable
Guideline 4.1 Ensure full keyboard access [Techniques]
@@The UAWG is currently working to ensure that sufficient requirements are in place regarding how keyboard shortcuts are conveyed to the user (e.g. visual indicators, documentation, etc.). Input from area experts would be welcome.@@
@@The UAWG is also currently working to ensure that the requirements properly cover interaction with video and dynamic Web content. Input from area experts would be welcome.@@
Level A Success Criteria for Guideline 4.1
- 4.1.1 Keyboard: The user can, through keyboard input alone, navigate to and operate all of the functions included in the user interface (e.g., navigating and selecting content within views, operating the user interface "chrome", installing
and configuring the user agent, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. freeform drawing). This applies to at least one mechanism per "browsing outcome"@@DEFINE@@, allowing
non-keyboard accessible mechanisms to remain available (e.g.,
providing resizing with mouse-"handles" and with keystrokes).@@1.1 in UAAG10@@[ATAG 2.0]
- 4.1.2 Precedence of Keystroke Processing: The precedence of keystroke processing between the user agent interface, user agent extensions, content keystroke operations administered by the user agent (e.g., access keys), and executable content (e.g., key press events in scripts, etc.) is documented.@@NEW@@
- 4.1.3 No Keyboard Trap: If focus can be moved to a component with the keyboard, then at least one of the following is true:
@@WCAG2 concept@@
- (a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
- (b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the user is advised of the method.
- 4.1.4 Separate Activation: The user has the option to have selection separate from activation
(e.g., navigating through the items in a dropdown menu without
activating any of the items).@@9.5 in UAAG10@@[ATAG 2.0]
- 4.1.5 Available Keystrokes: The user can always determine available binding information in a centralized fashion (e.g., a list of bindings) or a distributed fashion (e.g., by keyboard shortcuts listed in user interface menus) for the following:
@@11.1,11.2 in UAAG10@@
- (a) user interface "chrome" and extensions (including any user re-mappings), and
- (b) content keybindings that the user agent can recognize.
- 4.1.6 Standard Text Area Conventions: Views that render text support the standard text area conventions for
the platform including, but not necessarily limited to:
character keys, backspace/delete, insert, "arrow" key
navigation (e.g., "caret" browsing), page up/page down, navigate to start/end, navigate
by paragraph, shift-to-select mechanism, etc. @@7.1 in UAAG10@@ [ATAG 2.0]
- 4.1.7 "Chrome" Navigation: The user can use the keyboard to traverse all of the controls forwards and backwards, including controls in floating toolbars, panels, user agent extensions @@DEFINE@@, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab").[ATAG 2.0]
Level AA Success Criteria for Guideline 4.1
- 4.1.8 Accelerator Keys: If any of the following functionalities are implemented by the
user agent, the user has the option to enable
key-plus-modifier-key (or single-key) access to them:@@11.5 in UAAG10@@ [ATAG 2.0]
- (a) move content focus to the next/previous enabled element in document order,
- (b) activate the link designated by the content focus,
- (c) open search function, search again
- (d) increase/decrease the scale of rendered text,
- (e) increase/decrease global volume,
- (f) stop/pause/resume and navigate efficiently audio and animations, including video and animated images,
- (g) next/previous history state (i.e., forward/back),
- (h) enter a URI for a new resource,
- (i) add a URI to favorites (i.e., bookmarked resources),
- (j) view favorites,
- (k) reload a resource,
- (l) interrupt a request to load or reload a resource,
- (m) for graphical viewports@@DEFINE?@@: navigate forward and backward through rendered content by approximately the height of the viewport, and
- (n) for user agents @@Line based user agents? DEFINE@@ that render content in lines of (at least) text: move the point of regard to the next and previous line.
- 4.1.9 Precedence of Keystroke Processing: Keystrokes are processed in the following order: user agent user interface, user agent extensions, content keystroke operations administered by the user agent (e.g., access keys), and executable content (e.g., key press events in scripts, etc.).@@NEW@@
- 4.1.10 User Override any Binding: The user can override any binding that is part of the user agent default input configuration except for conventional bindings for the operating environment (e.g., for access to help). The keyboard combinations offered for rebinding include single key and key plus modifier keys if these are available in the operating environment. @@11.3,11.4 in UAAG10@@
Level AAA Success Criteria for Guideline 4.1
- 4.1.11 Intergroup Navigation: If logical groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels) are present, the user can use the keyboard to navigate to a focusable control in the next and previous groups.[ATAG 2.0] @@NEW@@
- 4.1.12 Group Navigation: If logical groups of focusable controls are present, the user can use the keyboard to navigate to the first, last, next and previous focusable controls in the current group.[ATAG 2.0]@@NEW@@
Guideline 4.2 Provide access to event handlers [Techniques]
Level A Success Criteria for Guideline 4.2
- 4.2.1 All Available: The user can activate, through keyboard input alone, all
input device event handlers (including those for pointing devices, voice, etc.) that are
explicitly associated with the element designated by the content focus.@@1.2 in UAAG10@@
- 4.2.2 Show All: For the element with content focus, the list
of input device event types for which there are
event handlers explicitly associated
with the element are provided. @@9.6 in UAAG10@@
- 4.2.3 Activate All: The user can activate, as a group, all event
handlers of the same input device event type, for the same control. @@1.2 in UAAG10@@
Level AA Success Criteria for Guideline 4.2
- (No level AA success criteria for Guideline 4.2)
Level AAA Success Criteria for Guideline 4.2
- (No level AAA success criteria for Guideline 4.2)
Guideline 4.3 Allow time-independent interaction [Techniques]
Level A Success Criteria for Guideline 4.3
- 4.3.1 Timing Adjustable: Where time limits for user input are recognized and controllable by the user agent, an option is provided to extend the time limit.@@2.4 in UAAG10@@
Level AA Success Criteria for Guideline 4.3
- (No level AA success criteria for Guideline 4.3)
Level AAA Success Criteria for Guideline 4.3
- (No level AAA success criteria for Guideline 4.3)
Guideline 4.4 Help users avoid flashing that could cause seizures [Techniques]
Level A Success Criteria for Guideline 4.4
- 4.4.1 Below Threshold: The user interface "chrome" never violates the general flash or red flash thresholds. @@NEW@@
Level AA Success Criteria for Guideline 4.4
- (No level AA success criteria for Guideline 4.4)
Level AAA Success Criteria for Guideline 4.4
- 4.4.2 Three Flashes: No part of the user interface "chrome" ever flashes more than three times in any one second period. [WCAG 2.0] @@NEW@@
Guideline 4.5 Store preference settings [Techniques]
Level A Success Criteria for Guideline 3.6
- 4.5.1 Save Settings: User agent preference settings are stored between sessions. @@NEW@@
Level AA Success Criteria for Guideline 3.6
- 4.5.2 User Profiles: The user can save and retrieve multiple sets of user agent preference settings. @@11.6 in UAAG10@@
Level AAA Success Criteria for Guideline 3.6
- 4.5.3 Portable Profiles: Sets of preferences are stored as separate files (allowing them to be transmitted electronically). @@NEW@@
- 4.5.4 Preferences Wizard: A "wizard" helps the user to configure (at least) the accessibility-related user agent preferences. @@NEW@@
Guideline 4.6 Provide text search [Techniques]
Level A Success Criteria for Guideline 4.6
- (No level A success criteria for Guideline 4.6)
Level AA Success Criteria for Guideline 4.6
- 4.6.1 Search Rendered: The user can perform a search within rendered (e.g., not hidden with a style) content for text and text alternatives for a sequence
of characters from the document character set.@@9.8 in UAAG10@@
- 4.6.2 Bi-Directional: The user has the option of searching forward or backward (in document order) from any selected
or focused location in content.@@NEW@@
- 4.6.3 Match Found: When there is a match, both of the following are true:
- (a) move: the viewport moves so that the matched text content is at least partially
within it, and@@9.8 in UAAG10@@
- (b) search again: the user can search for the next instance of the text from the
location of the match.@@9.8 in UAAG10@@
- 4.6.4 No Match: The user is alerted when there is no match or after the last match in content (i.e.,
prior to starting the search over from the beginning of content).@@9.8 in UAAG10@@
- 4.6.5 Case Insensitive: There is a case-insensitive search option.@@9.8 in UAAG10@@
Level AAA Success Criteria for Guideline 4.6
- (No level AAA success criteria for Guideline 4.6)
Guideline 4.7 Provide structured navigation [Techniques]
Level A Success Criteria for Guideline 4.7
Level AA Success Criteria for Guideline 4.7
- (No level AA success criteria for Guideline 4.7)
Level AAA Success Criteria for Guideline 4.7
- 4.7.2 Configure Set of Important Elements: The user has the option to configure the set of important
elements for structured navigation, including by element type (e.g., headers). @@9.10 in UAAG10@@
Note: For example, allow the user to navigate only
paragraphs, or only headings and paragraphs, or to suppress and restore
navigation bars, or to navigate within and among tables and table cells
Guideline 4.8 Provide tool bar configuration [Techniques]
Level A Success Criteria for Guideline 4.8
- (No level A success criteria for Guideline 4.8)
Level AA Success Criteria for Guideline 4.8
- (No level AA success criteria for Guideline 4.8)
Level AAA Success Criteria for Guideline 4.8
Principle 5: Ensure that user interface is understandable
Guideline 5.1 Help users avoid unnecessary messages [Techniques]
Level A Success Criteria for Guideline 5.1
- (No level A success criteria for Guideline 5.1)
Level AA Success Criteria for Guideline 5.1
- 5.1.1 Option to Ignore: The user has the option to turn off rendering of non-essential or low priority text messages, based on priority properties defined by the author (e.g., ignoring messages marked "polite" using ARIA ). @@NEW@@
Level AAA Success Criteria for Guideline 5.1
- (No level AAA success criteria for Guideline 5.1)
Guideline 5.2 Help users avoid and correct mistakes [Techniques]
Level A Success Criteria for Guideline 5.2
- (No level A success criteria for Guideline 5.2)
Level AA Success Criteria for Guideline 5.2
- 5.2.1 Form Submission: The user has the option to confirm (or cancel) any
form submission made while content focus is not on the submitting control (e.g., forms that submit when Enter is pressed). @@5.5 in UAAG10@@
Level AAA Success Criteria for Guideline 5.2
- (No level AAA success criteria for Guideline 5.2)
Guideline 5.3 Document the user agent user interface
including all accessibility features [Techniques]
Level A Success Criteria for Guideline 5.3
- 5.3.1 Accessible Format: At least one
version of the documentation is either:
@@12.1 in UAAG10@@
- (a) "A" accessible: Web content and conforms to WCAG 2.0 Level "A" (although it is not necessary
for the documentation to be delivered on-line), or,
- (b) accessible platform format: not Web content and conforms to a published accessibility
benchmark that is identified in the conformance
claim (e.g.,
when platform-specific documentation systems are used).
- 5.3.2 Document Accessibility Features: All user agent
features that benefit accessibility @@DEFINE - as specified in the conformance claim@@ are documented.@@12.2 in UAAG10@@
Level AA Success Criteria for Guideline 5.3
- 5.3.3 Changes Between Versions: Changes to features that benefit
accessibility since the
previous version of the user agent are documented. @@12.4 in UAAG10@@
- 5.3.4 Centralized View: There is a centralized view of all
features of the user agent that benefit accessibility, in a dedicated section
of the documentation.@@12.5 in UAAG10@@
Level AAA Success Criteria for Guideline 5.3
- 5.3.5 Context Sensitive Help: There is context-sensitive help on all user agent features that benefit accessibility.@@NEW@@
Conformance
@@Ed. This section is still under development@@
This glossary is normative.
- activate
- In the context of rendered content this means to execute or carry out one or more behaviors associated with an
enabled element.
In the context of the user interface "chrome", this means to execute or carry out one or more behaviors associated with a component of the
user agent user interface.
The effect of activation depends on the type of the
user interface control.
For instance, when a link is activated, the user agent generally retrieves the linked
Web resource.
When a form element is activated, it may change state (e.g., check boxes) or may take user input (e.g., a text entry field).
- alert
- To make the user aware
of some event, without requiring acknowledgement. For example, the user agent
may alert the user that new content is available on the server by displaying a
text message in the user agent's status bar.
- alternative content
- Content that should be made available to the user only under certain conditions (e.g., based on user preferences or operating environment limitations). Some examples include:
- The
alt attribute of the IMG element in HTML 4 [HTML4].
OBJECT elements in HTML 4 [HTML4].- The
switch element and test attributes in SMIL 1.0 [SMIL].
- The
NOSCRIPT and NOFRAMES elements in HTML 4 [HTML4].
Note: Specifications vary in how completely they define how and w