This First Public Working Draft outlines the requirements that the User Agent Accessibility
Guidelines Working Group (UAWG) has set for development of User Agent
Accessibility Guidelines 2.0 (UAAG 2.0). These requirements are based on feedback from
the use of UAAG 1.0 and will be used to determine if the UAWG has met
its goals as UAAG 2.0 advances through the W3C
Recommendation Track Process.
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/.
This is a First Public Working Draft of "User Agent Accessibility Guidelines 2.0 Requirements."
This document was developed by the User
Agent Accessibility
Guidelines Working Group (UAWG), part of
the W3C Web Accessibility Initiative (WAI).
The goals of the UAWG are discussed in the UAAG
Working Group charter. The UAWG is part of the WAI
Technical Activity.
This requirements document introduces planned new work on a second generation of guidelines for browser and media player accessibility.
Comments on our proposed direction are welcome at public-uaag2-comments@w3.org (Public Archive).
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.
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.
User Agent Accessibility Guidelines 1.0 (UAAG 1.0) provides guidelines for
designing user agents (browsers) that lower barriers to Web accessibility for people
with disabilities (visual, hearing, physical, cognitive, and neurological).
Since the release of UAAG 1.0 as a W3C Recommendation
in December 2002, the UAWG has received feedback about the usability, understandability,
and applicability of the suite of documents. Also, in the intervening years
there have been changes and improvements in
- technologies and techniques used in web content,
- functionality of assistive technology,
- accessibility application programming interfaces (APIs), and
- platforms used to receive content.
The feedback, changes, and information gathered from evaluating
user agents using test suites to develop implementation
reports is driving the development of
UAAG 2.0 and is captured as the Requirements for UAAG 2.0 (this document).
The primary goal of UAAG 2.0 is the same as it was for version 1.0. To lower barriers to accessibility
of user agents.
We intend to ensure that the revision is backwards and forward compatible.
We intend to attract the participation of developers of browsers, assistive technologies, plug-ins, extensions, accessibility
APIs (Microsoft Active Accessibility - MSAA, Gnome Accessibility Toolkit - ATK, iaccessible2, Microsoft UI Automation on Windows Vista - UIA, etc.) as well as consumers of
accessibility APIs (e.g., some assistive technology and plug-in developers) and end users.
Areas for Development in Version 2.0
Ensure that UAAG 2.0 is relevant to evolving Web technologies:
In developing UAAG 2.0, the UAWG will:
- Take into account advances in Web technologies since the release of UAAG 1.0. Specifically, the new version will add or improve references to W3C, non-W3C, compound documents, platforms, and emerging internet technologies. UAAG 2.0 will also promote the use of public engineered accessibility APIs and the implementation of Document Object Models (DOMs).
- W3C technologies include HTML/XHTML, XFORMS, CSS, XSL, XSLT, MathML,
SMIL, SVG, and others.
- Non-W3C technologies include Flash, PDF, Shockwave, Java applets,
video formats (QuickTime, REAL, Windows Media, etc.) and others.
- Compound document examples include:
- XHTML + SVG + MathML
- XHTML + SMIL
- XHTML + XForms
- XHTML + VoiceML
- Compound documents can also include integration
of non-W3C formats with W3C or other non-W3C formats.
- Platforms include both software and hardware frameworks, including
architecture, operating systems and desktops, languages (scripting,
programming, markup), and programming interfaces.
- Primary operating systems and desktops include Windows XP and
Vista, Linux (Gnome and KDE Desktops) and other UNIX variants such as Solaris,
MacOS, and Java. Mobile platforms such as phones, personal data assistants (PDAs), etc.
and their operating systems (PalmOS, Windows Mobile, Java ME,
etc.) will also be considered.
- Scripting, programming, markup languages, and development
environments include C/C++, Python, Java, JavaScript, XML User Interface Language (XUL), as
well as W3C markup languages and many others.
- Programming interfaces include:
- Native operating system programming interfaces
for Windows, Linux, Java, MacOS, etc
- DOM programming interfaces such as COM interfaces
for Windows Internet Explorer and ISimpleDOMNode
for Firefox
- Engineered accessibility APIs include Microsoft
Active Accessibility (MSAA) and IAccessible2 on Windows,
UI Automation on Windows Vista (UIA), Accessibility Toolkit
(ATK) and Assistive Technology Service Provider Interface
(AT-SPI) for Linux, and Universal Access for MacOS.
- Emerging technologies include W3C technologies such
as XHTML, XForms, and Web APIs, as well as Rich Internet Applications
(RIA) which include AJAX, mashups, wikis, widget toolkits like
the Dojo toolkit, etc.
- Address the interaction of preferences that are set by
various levels of technology (i.e., platform, browser, content) and
by
different actors (e.g., authors setting accesskeys and creating custom
controls, browser-users setting keyboard preferences). The group will
reference external preference negotiation protocols where they exist.
- Address the behavior of extensions and related technologies
that allow the user to modify the view through scripting and other
techniques such that these changes are made available to all appropriate
accessibility mechanisms (e.g., DOM, accessibility API, etc.).
- Address privacy of user settings.
- Consider adding search of conditional content.
- Address user agent repair functionality when content is non-conformant with
WCAG 2.0.
- Address the balance between customizations complexity and streamlining
(profiles).
Ensure that the conformance requirements are clear
In developing UAAG 2.0, the UAWG will:
- Consider modularizing the UAAG 2.0 document. One module would
address "core" browser capabilities (i.e., features for people
needing
some accessibility support, but who do not use assistive technologies).
Other modules might address voice browsers, speech input, etc. that,
while important, are not as relevant to "basic" browsers.
- Be clear about which features/functions can be passed off to assistive technologies
and/or extensions.
- Ensure requirements are relevant on all platforms (techniques may be different).
Identify clearly who benefits from accessible user agents.
In developing UAAG 2.0, the UAWG will:
- Attempt, through informative support documents, to more clearly
identify who will benefit from each requirement.
- Attempt to address, as completely as possible, the needs of:
- user agent developers
- user agent extension developers
- user agent plug-in developers
- assistive technology developers
- API accessibility architects
- end users with:
- blindness
- low vision
- color deficit or distortions
- deafness
- hearing loss
- cognitive limitations
- reading disabilities
- speech impairments
- paralysis, weakness, and other problems with movement
and coordination of limbs
- photosensitivity
- and combinations thereof.
Modify the design of deliverables
In developing UAAG 2.0, the UAWG will:
- Simplify the structure of the deliverables,
where possible, in order to promote ease of use. In designing the usability of
the deliverables, the UAWG will consult the results of the WAI Site
Redesign Task Force usability testing and discuss the design with representatives
of the WAI-EOWG.
- Make an effort to align the structure of the document, wherever appropriate, with the one used in ATAG 2.0 and
WCAG 2.0 by splitting requirements into the perceivable, operable,
understandable, and access system interoperable categories.
- Examine whether similar checkpoints can be combined to reduce redundancy.
Last edited:
October 25, 2007