Last edited: February 2, 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).

We will not be backward compatible with UAAG 1.0.

The primary goal of UAAG 2.0 is the same as 1.0: to lower barriers to accessibility of user agents. Additional goals discussed in this document are:

1. Ensure that requirements may be applied across and interoperable with technologies - scripting languages, CSS (generated content, style/presentation information-chrome and content), W3 specification, operating systems, platforms (mobile, etc.), APIs, accessibilty architectures
   1. interoperabilty between APIs (platform, accessbility, etc.), negotiating keyboard input/control conflicts (all of GL 6)
   2. ?how should inprocess javascript etc. be provided user preferences (platform specific information (high contrast mode) and UA preferences) [perhaps AT settings],?
   3. use the same requirements on all platforms (techniques may be different)
   4. resolve settings/preferences negotiations (platform, browser, javascript, and author created preferences - accesskeys, ajax stuff)
2. shift focus back to base browser (make user agent base provide the accessibility model)(getting information out through the use of API)
   1. base browser is primary platform for testing
   2. core browser features for folks not using AT (especially keyboard access to tooltips, mouseovers, etc.)
   3. features/functions that can be passed off to AT and/or extensions
   4. broad support by browsers -
   5. Accessibilty model (make user agent base provide the accessibility model)
   6. programatic access to allow browser extensions
   7. UA should allow/enable the creation/customization of accessible extensions, then up to UA developer to do the enablement
   8. allow extensions to access the 'accessibility model' (DOM, accessibility API)
   9. promote use of engineered public complete accessibility API
      1. promote the implementation of platform accessibility API's by UA (extensions and embedded UA) for use by assistive technology.
      2. Implementation of appropriate DOM [HTML DOM incomplete because doesn't have accessible information for extensions to the browser (JS, flash, XUL?), CSS, scripting]
4. [use this a a model for the proposed outline of the new document - to help guide discussion] explain how to demonstrate (test and declare) compliance through an accessible view and controller using the appropriate UIs (browsers and extenstions, assistive technology, other UAs)
   explain compliance by stating what was added to base browser (extensions, AT, plug-in)
   1. customization requirements (slow multimedia)
      1. UI extensions that modify/manipulate the view. Grease monkey, transcoding on client level, (allow users to modify rendered content through scripting)
   2. modularization
      1. speech output (AT, phone)
      2. keyboard selection/navigation (11.2, 11.3)
      3. speech input
      4. compound documents
   3. core (handling of input devices)
   4. (also, content customization - settings to expose alt, title, abbreviation expansion, event handler, how much information will the UA tell me about each element - 'verbosity level' etc.)
   5. chrome and UI customization (include UI extensions) - accessible(!) and interoperable(?)
5. update UAAG to reflect the emerging internet technologies {this is more about Techniques - keyboard, customization, programatic access)
   1. W3 technologies
      1. web 2.0
      2. web applications (scripting, css, html)
      3. svg
      4. mathml
6. Ensure privacy of user settings.

1. Ensure that the conformance requirements are clear
2. Design deliverables with ease of use in mind
3. Clearly identify who benefits from accessible user agents
4. restructure to more closely align with ATAG and WCAG
   1. simplify but combining similar checkpoints, reducing redundancy
   2. balance roles Author content and UA functionality (repair and control functions)
5. better address accessibilty of compound documents (with embedded user agents)
   1. flash/mediaplayer/pdf (other things the UA doesn't know about-out process) (non-W3 technologies)
   2. svg
   3. mathml
6. create separate section of UAAG that deal with configuration to resolve settings/preference negotiations (platform, browser, javascript, and author created preferences - accesskeys, ajax stuff)

promote use of engineered public complete accessibility API

promote the implementatiion of platform accessibility API's by UA (extensions and embedded UA) for use by assistive technology.

Implementation of appropriate DOM [HTML DOM incomplete because doesn't do extensions, CSS, scripting]

?? for in-process components [[want active-x and other objects to implement accessibility APIs (msaa)]]

out of process bucket - animations, things in objects, javascript out of process

implementation detail - search of conditional content.

balance between customizations complexity and streamlining (profiles)

what about skins and accessibilty.

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 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.