Last edited: February 8, 2007

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

Table of Contents

  1. Introduction
  2. Audience

 

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, udates in the functionality of assistive technology, changes in accessibilty 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.

We will not be fully backward compatible with UAAG 1.0.

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. Restructure to more closely align with ATAG 1.0 and WCAG 2.0 - may make use of "model/view/controller" metaphor .
    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. Investigate modularizing the document to focus on "base" browsers while also addressing voice browsers, speech input, etc. when this is relevant.
    2. Ensure "base" browsers include "core" browser features for people needing some accessibility support but who do not use AT (especially keyboard access to tooltips, mouseovers, etc.)
    3. Be clear about which features/functions that can be passed off to AT and/or extensions
    4. Ensure requirements are relevant on all platforms (techniques may be different)
  3. Relevance to evolving state of Web technologies:
    1. Take into account emerging internet technologies (including Web 2.0)
      1. W3C techologies (svg, mathml, etc.) and non-W3C technologies
      2. compound documents (especially when rendered by embedded user agents)
      3. various platforms
    2. Include references to emerging accessibility technologies and best practices (e.g ARIA)
    3. Promote use of public engineered accessibility APIs and implementation of appropriate DOM
    4. Address the need for extensions to be able access the 'accessibility model' (DOM, accessibility API)
    5. Improve statement of configuration requirements for resolving settings/preference negotiations (e.g. between platform, browser, javascript, and author created preferences - accesskeys, ajax stuff)
    6. Consider UI extensions that modify/manipulate the view (e.g. Grease monkey, allow users to modify rendered content through scripting)
    7. Ensure privacy of user settings is addressed.
    8. Address skins and accessibility.
    9. 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 consurmers of accessiblity apis (plug in developers, AT developers) and end users because all benefit

plug-in vs extension vs model

  1. flash/media-player/PDF - own ui, implements accessibilty api (part of infrastructure), provides content , both a model and the view, not part of the HTML DOM , embedded object (in HTML), may have own DOM/API, may expose public API so others can get at the information
  2. UIUC accessibility extension - extension to view (using api to get information), consumer of existing model, extents the browser ui to provide information to end user. using the DOM
  3. web application - own ui (provided by the author, not the model), repurposes functioning of standard controls and creates custom controls [author must use WEB-ARIA to be accessible], doesn't implement native/platform API.