Go to previous article
Go to next article
Return to 2003 Table of Contents
Jon Gunderson, Ph.D.
Chair, W3C User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Students
University of Illinois at Urbana/Champaign
1207 S.Oak Street, Champaign, IL 61820
Jim Allan, M.S.
Member, W3C User Agent Working Group
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, TX 78756
The User Agent Accessibility Guidelines working group has developed an implementation report and a set of test suites to help consumers and developers to understand the accessibility features of browsers and multi-media players required by people with disabilities for access to web resources. Test suites can be used by people with disabilities to provide specific feedback to developers on accessibility features that need to be improved in browsers and multimedia players. The test suites allow people to easily tell developers where accessibility problems exist in their product by providing a common point of reference to discuss the issue.
The W3C User Agent Accessibility Guidelines (UAAG)  define the accessibility requirements for browsers and multi-media players to meet the needs of people with disabilities to access web content. UAAG is part of a set of accessibility guidelines developed by the W3C Web Accessibility Initiative to help authors and web technology developers understand how to make the web accessible to people with disabilities. The other two major guidelines are the Web Content Accessibility Guidelines (WCAG)  and the Authoring Tool Accessibility Guidelines (ATAG) . The guidelines work together to insure authors that create accessible content with WCAG can be accessed through web rendering technologies that conform to the UAAG requirements.
UAAG was developed in the consensus-based process  of the W3C and included participation of people with disabilities, developers, researchers and service providers. The working group was open to the public for participation and periodically called for public reviews by the general public and developers who were not a part of the working group. Comments and proposals from members of the working group and the public were added to the UAAG issues list . As the group resolved issues the person making the comment was notified and were given the opportunity to respond to the working groups resolution. In this way the document has been developed over the past five years. In the process of preparing the document for to be a Recommendation of the W3C the working group must also document implementation experience. This paper is primarily about the current state of implementation of the User Agent Guidelines based upon the information gathered by the working group.
UAAG has document the current implementation of UAAG requirements for browser and multi-media players . Table 1 shows a summary of the current implementation report as of September 2002. The implementation report is based on full or partial reviews of the following user agents:
Note: Percentages are for a given priority
The implementation report is used to show that the requirements of the UAAG document are technically achievable to developers and not designed to show whether a particular user agent meets all or some of the UAAG requirements. UAAG has a conformance section that defines how a user agent or combination of technologies can state that the requirements of UAAG  have been satisfied. The W3C process ideally wants two independent implementations of each requirement. The current implementation report (September 2002) shows that 92% of the UAAG requirements have at least two implementations and 99% have at least one implementation. This shows developers that the majority of requirements of UAAG are achievable since almost each requirement has been implemented in at least one user agent and the vast majority on more than one implementation. Currently the only requirement with partial implementation is the requirement to confirm form submission. In this case the browser can be configure to prompt for insecure form submissions, but not for secure submissions. It would seem to be an easy extension to allow for all form submissions to include prompting. During the Candidate recommendation period a few other requirements were merged as notes into other requirements, since the group could not show any implementation experience.
Use of Test Suites
Test suites bring UAAG to life for both developers and consumers . The test suites take the requirements of a checkpoint and provide a concrete test for some or all the requirements for a particular technology. Currently most of the effort has focused on the development of test suites for HTML. The HTML test suite currently consists of over 120 tests for 33 of the 83 checkpoints in UAAG. Other test suites are under development for multimedia technologies like Real Player, Quicktime, Microsoft Media Player and HTML+Time in Internet Explorer. The test suites are organized by checkpoint and provide information on the requirement or requirements the test is associated with, the procedure for the test, the test and the source code for the test. The test suites provide a common point for developers and reviewers to reference specific features that a user agent fully supports, partially supports or does not implement. Reviewers can send to the developer the URL of the test and the observed results for the developer to verify and comment on the accessibility issue. Reviewers can include anyone and is a good way for people who want to improve the accessibility of a particular browser or multi-media player to provide concrete feedback to a developer, since the test can be referenced in the message. Reviewers also don't need to interpret the guidelines to a specific requirement to provide comments to developers and can learn the scope and purpose of a checkpoint by looking at the associated tests. It is important to provide comments to developers to help them understand the importance and public's interest in adding accessibility features to their technologies. The more comments they receive the more importance they will put to addressing accessibility features.
An example of a test for Checkpoint 1.1 Support the Keyboard . For HTML browsers this includes support for the ACCESSKEY attribute for links and form controls. Separate test pages have been created for testing whether ACCESSKEY is available for links and various form controls.
Status of UAAG
UAAG is in the final stages of the recommendation process. It is anticipated that UAAG will become a proposed recommendation in mid October of 2002 and proceed to recommendation by December of 2002. People interested in participating in the development of Test Suites or tracking the implementation of user agents should contact the authors.
I would like to acknowledge the work of Colin Koteles, Ian Jacobs and Matt May in the development of the test suites and implementation report. I would like to that the user agent working group for all the time and effort they have expended in the development of the User Agent Accessibility Guidelines and their contributions to the implementation report.
 User Agent Accessibility Guidelines 1.0 http://www.w3.org/TR/UAAG10
 Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10
 Authoring Tool Accessibility Guidelines 1.0 http://www.w3.org/TR/ATAG10
 World Wide Web Consortium Process Document http://www.w3.org/Consortium/Process-20010719/
 W3C User Agent Issues List http://www.w3.org/WAI/UA/issues/issues-linear-lc4.html
 User Agent Accessibility Guidelines Implementation Report for Proposed Recommendation http://www.w3.org/WAI/UA/impl-pr2/
 Conformance to the W3C User Agent Accessibility Guidelines
 User Agent Accessibility Guidelines Test Suites http://www.w3.org/WAI/UA/TS/
 W3C User Agent Test for ACCESSKEY
Go to previous article
Go to next article
Return to 2003 Table of Contents
Return to Table of Proceedings