Last edited: February 22, 2007

***DRAFT***
UAAG Requirements Documents
***DRAFT***

Introduction

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:

  1. Organization of the document:
    1. Ensure that the conformance requirements are clear and design deliverables with ease of use in mind.
    2. Combine similar checkpoints to reduce redundancy.
    3. More clearly identify who benefits from accessible user agents.
    4. 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.
      1. Perceivable: able to be noticed by a user through one or more renderings provided by the base user agent, its extensions, or assistive technologies
      2. 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
      3. 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
      4. 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)
    5. Address author responsibilities when creating content content vs. UA functionality (repair and control functions)
    6. Address the balance between customizations complexity and streamlining (profiles)
  2. Clarify conformance details:
    1. 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.
    2. Be clear about which features/functions that can be passed off to AT and/or extensions
    3. Ensure requirements are relevant on all platforms (techniques may be different)
  3. Relevance to evolving state of Web technologies:
    1. 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).
      1. W3C technologies include HTML/XHTML, XFORMS, CSS, XSL, XSLT, MathML, SMIL, SVG, and others.
      2. Non-W3C technologies include Flash, PDF, Shockwave, Java applets, video formats (QuickTime, REAL, Windows Media, etc) and others.
      3. 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.
      4. 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.
      5. 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.
    2. 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.
    3. 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.).
    4. Ensure privacy of user settings is addressed.
    5. Consider adding search of conditional content.

Whys and whats

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