Last edited:
February 22, 2007
***DRAFT***
UAAG Requirements Documents
***DRAFT***
User Agent Accessibility Guidelines 1.0 (UAAG 1.0) provides guidelines for designing user agents 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
UA WG has received feedback about the usability, understandability, and applicability
of the suite of documents.[changes in the techniques used in web pages (extensive
scripting, changes in the use of technology used for the web, updates in
the functionality of assistive technology, changes in accessibility APIs,
changes in platforms (pervasive, mobile devices, etc.) These changes in addition
to information gathered from evaluating user agents using test suites to
develop implementation reports (link) and feedback 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 1.0: to lower barriers to accessibility
of user agents.
Potential Areas for Guideline Document Improvement
We intend to improve over UAAG 1.0 in the following areas:
- Organization of the document:
- Ensure that the conformance requirements are clear and design deliverables with ease of use in mind.
- Combine similar checkpoints to reduce redundancy.
- More clearly identify who benefits from accessible user agents.
- Align the structure of the document with the one used in ATAG 2.0 and
WCAG 2.0 by splitting requirements into the perceivable, operable,
understandable, and access system friendly categories.
- Perceivable: able to be noticed by a user through one or more
renderings
provided by the base user agent, its extensions, or
assistive technologies
- Operable: able to be manipulated by a user through one or
more input
devices recognized by the base user agent, its extensions,
or
assistive technologies
- Understandable: able to be comprehended
by a user through one or more
intelligible renderings provided by the base user agent, its
extensions, or assistive technologies
- Access system
friendly: able to be viewed and controlled programmatically
by extensions to the base user agent and
assistive technologies using standard APIs (e.g. DOM, MSAA,
AT-SPI, UA, UIA)
- Address author responsibilities when creating content content vs. UA functionality (repair and control functions)
- Address the balance between customizations complexity and streamlining (profiles)
- Clarify conformance details:
- 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 that can be passed off to AT
and/or extensions
- Ensure requirements are relevant on all platforms (techniques may be different)
- Relevance to evolving state of Web technologies:
- Take into account and include references to W3C, non-W3C, compound
documents, platforms, and emerging internet technologies. 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 may be:
- 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 and other UNIX variants such as Solaris,
MAC OS, and Java. Mobile platforms such as phones, 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, XUL, as
well as W3C markup languages and many others.
Programming interfaces include:
- Native operating system programming interfaces
for Windows, Linux, Java, MAC OS, 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, Accessibility Toolkit
(ATK) and Assistive Technology Service Provider Interface
(AT-SPI) for Linux, and Universal Access for MAC
OS.
- Emerging technologies include emerging W3C technologies such
as XHTML, XForms, and Web APIs, as well as Rich Internet Applications
(RIA) which include AJAX, mashups, wikis, widget toolkits like
Dojo, etc.
- Better 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.
- Ensure UAAG 2.0 addresses 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.).
- Ensure privacy of user settings is addressed.
- Consider adding search of conditional content.
Whys and whats
- encourage the adoption of aria techniques by user agents
- more clearly define user agents as browsers, but distinguish the testing of compliance to include extensions and assistive technology
Audience
must attract all browser developers to participate as well as accessibility
architects for api (msaa, atk, iaccessible2, uia) as well as consumers of
accessibility apis (plug in developers, AT developers) and end users because
all benefit