Skip to main content

World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI)

Overview

Web accessibility means that people who have disabilities and others can perceive, understand, navigate, interact with, and contribute to the Web. The W3C develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential.

In order for the Web to be accessible, it is essential that several different components of Web development and interaction work together. These components include:

  • Content - the information in a Web page or Web application, including:
    • Information such as text, images, multimedia and applications.
    • Code or markup that defines structure, presentation, etc.
  • Web browsers, media players, and other "user agents".
  • Assistive technology, in some cases - screen readers, alternative keyboards, switches, scanning software, etc.
  • Users' knowledge, experiences, and in some cases, adaptive strategies for using the Web.
  • Developers - designers, coders, authors, etc., including developers with disabilities and users who contribute content.
  • Authoring tools - software used to create Web content.
  • Evaluation tools - Web accessibility evaluation tools.

A subgroup of the W3C, the Web Accessibility Initiative (WAI) develops guidelines and techniques that describe accessibility solutions. These WAI guidelines are considered the international standard for Web accessibility and cover all aspects of the previously mentioned components. The IBM HA&AC and Emerging Internet Technology teams are key members of the following groups developing accessibility guidelines:

One of the WAI's roles is to develop guidelines and techniques that describe accessibility solutions. These WAI guidelines are considered the international standard for Web accessibility and cover all aspects of the previously-mentioned components. The IBM HA&AC and Emerging Internet Technology teams are key members of the following groups developing accessibility guidelines:

Web Content Working Group (WCAG WG)

The WCAG working group develops guidelines, techniques, and supporting resources for accessible Web content.

The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them may also help make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment).

WCAG 1.0 was completed in 1999. It contains 65 checkpoints that provide guidance on:

  • Non-text content
  • Use of color
  • Proper markup including tables, headings, and lists
  • Input device independence
  • Navigation
  • Use of simple language and foreign languages

WCAG 2.0 is currently in development and is expected to be approved in 2008. When WCAG 1.0 was approved, the Internet consisted largely of static HTML pages. This is no longer the case and so WCAG 1.0 has become somewhat outdated for companies like IBM that are now focused on emerging Internet technologies. WCAG 2.0 is principle based, rather than technology based and can be applied to any Web technology that supports accessibility. The requirements are worded as objectively testable success criteria grouped according to the following principles:

  • Information and functionality must be presentable to users in ways that they can perceive.
  • Interactive functionality must be available to users in ways that they can operate.
  • Information and functionality must be understandable.
  • Information and functionality must be able to be rendered reliably by a wide variety of user agents, including assistive technologies.

WCAG 2.0 is accompanied by technology-specific techniques which include testing procedures so that developers have specific guidance for current Web technologies.

Authoring Tools Working Group (AUWG)

The ATAG working group defines how authoring tools should help Web developers produce Web content that conforms to the Web Content Accessibility Guidelines. The ATAG documents also explain how to make authoring tools accessible so that people with disabilities can use the tools.

ATAG 1.0 contains 28 checkpoints that provide guidance on:

  • Producing accessible output that meets standards and guidelines.
  • Prompting the content author for accessibility-related information.
  • Providing ways of checking and correcting inaccessible content.
  • Integrating accessibility in the overall "look and feel," help, and documentation.
  • Making the authoring tool itself accessible to people with disabilities.

ATAG 2.0 is being developed to be compatible with WCAG 2.0, which is under development, and WCAG 1.0, which was completed in May 1999. IBM is an active participant of the ATAG working group and contributes to the development of ATAG 2.0.

Protocols and Formats Working Group (PFWG)

The PFWG is the architecture and technical strategy "unit" of the W3C WAI working groups. As part of this effort, they have ongoing responsibilities for reviewing W3C specifications for accessibility issues and for recommending enhancements. Most recently, the PFWG has developed a roadmap for making Rich Internet Applications accessible. When necessary, the PFWG produces technical specifications, like the W3C WAI Accessible Rich Internet Applications specifications to address broader accessibility issues such as, what is often called, the "JavaScript Accessibility Problem – in XHTML and HTML, most elements" have defined semantic meanings such as headers, lists, and table cells. Assistive technologies understand these elements and present them to users in an understandable way. But script technologies, such as JavaScript, create an accessibility problem by allowing markup language elements to be re-purposed to create interactive application widgets. When this happens, the markup no longer expresses the semantic information needed by assistive technologies.

IBM initiated and chairs the PFWG WAI-ARIA subcommittee and is a contributing author to all WAI-ARIA related specifications:

  • WAI-ARIA Roadmap: this roadmap, to be published as a W3C Working Group Note, outlines the plan to make rich Internet applications accessible, the steps that have been taken, the remaining steps to be completed, and an estimated timeline.
  • WAI-ARIA technical specification: this specification, to be published as a W3C Recommendation Web standard, describes the WAI-ARIA roles, states, and properties to be utilized by developers of Web browsers, assistive technologies, and other user agents; developers of Web technologies (technical specifications); and developers of accessibility evaluation tools.
  • WAI-ARIA Best Practices: this specification, to be published as a W3C Working Group Note, provides guidance on creating accessible rich Internet applications using the WAI-ARIA technical specification. It is intended primarily for Web content developers.
  • WAI–ARIA Primer: this document, to be published as a W3C Working Group Note, provides an introduction to WAI-ARIA describing the problems, the fundamental concepts, and the WAI-ARIA approach.

The PFWG plans to produce a user agent implementation guide for WAI-ARIA to provide user agent developers with guidelines on how to implement WAI-ARIA.

Evaluation and Repair Tools Working Group (ERT WG)

This W3C WAI member group develops specifications and technical notes about the evaluation and repair of Web content with respect to accessibility. While specifications such as the Web Content Accessibility Guidelines (WCAG) or the Authoring Tools Accessibility Guidelines (ATAG) specify how to measure the degree to which Web content or authoring tools, respectively, are accessible, the ERT WG produces specifications for reporting on conformance or nonconformance to such guidelines.

The primary deliverables of the ERT WG include:

  1. Evaluation and Repair Language (EARL) 1.0 Schema – The EARL 1.0 Schema specifies a standardized vocabulary for expressing test results. These results can then be shared among different evaluation, reporting, comparison or analysis tools, or can be re-used for general quality assurance or regression testing. A document that uses the EARL schema is a report consisting of a collection of assertions. The main components of an EARL Report are:
    • Who (or which tool) runs a test (this is known in the EARL terminology as the Assertor).
    • The resource tested or Test Subject (e.g., Web page).
    • The tested criterion(-a).
    • The result(s) of the test.

A companion document, Evaluation and Report Language (EARL) 1.0 Guide, is an introduction to the EARL 1.0 Schema. The EARL 1.0 Schema is the only rec-track document of the deliverables discussed here.

  1. HTTP Vocabulary in Resource Description Format (RDF) – Quality assurance testing, conformance claims, and reporting languages like the Evaluation and Report Language (EARL) need to be able to identify resources on the Web. A simple URL may not be enough to uniquely resolve a document, for example, dynamic Web content may not even have a referenceable URL. Other factors such as HTTP content negotiation might come into play. HTTP Vocabulary in RDF attempts to mitigate this issue by providing a vocabulary in which to express HTTP headers, requests, and responses exchanged between clients and servers.
  2. Representing Content in RDF – The ERT WG has created and is maintaining a vocabulary for expressing different types of document content (e.g., html, xml, multi–media, text) in RDF.
  3. Pointer Methods in RDF – The ERT WG has created and is maintaining a vocabulary for referencing parts of or elements within a document.

The ERT WG has also been charged with the WCAG 2.0 Test Samples Development Task Force (TSD TF), a task force that is to develop test samples for WCAG 2.0 that demonstrate correct and incorrect implementation of WCAG criteria. The current test suite is based almost entirely on tests from the BenToWeb project. Each test also includes metadata describing the criterion being tested and the expected results. This information is presented in accordance with the BenToWeb Test Case Description Language (TCDL).


Last updated, July 31, 2008

WCAG Resources