Image with the acronyms of the accessibility standards: W3C, WAI, WCAG
Index

W3C

The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web. Founded in 1994 and currently led by Tim Berners-Lee, the consortium is made up of member organizations that maintain full-time staff working together in the development of standards for the World Wide Web. As of 21 October 2019, W3C had 443 members. W3C also engages in education and outreach, develops software and serves as an open forum for discussion about the Web.

Specification maturation

Sometimes, when a specification becomes too large, it is split into independent modules that can mature at their own pace. Subsequent editions of a module or specification are known as levels and are denoted by the first integer in the title (e.g. CSS3 = Level 3). Subsequent revisions on each level are denoted by an integer following a decimal point (for example, CSS2.1 = Revision 1).

The W3C standard formation process is defined within the W3C process document, outlining four maturity levels through which each new standard or recommendation must progress.

Working draft (WD)

After enough content has been gathered from 'editor drafts' and discussion, it may be published as a working draft (WD) for review by the community. A WD document is the first form of a standard that is publicly available. Commentary by virtually anyone is accepted, though no promises are made with regard to action on any particular element commented upon.

At this stage, the standard document may have significant differences from its final form.

Candidate recommendation (CR)

A candidate recommendation is a version of a standard that is more mature than the WD. At this point, the group responsible for the standard is satisfied that the standard meets its goal. The purpose of the CR is to elicit aid from the development community as to how implementable the standard is.

The standard document may change further, but at this point, significant features are mostly decided.

Proposed recommendation (PR)

A proposed recommendation is the version of a standard that has passed the prior two levels. The users of the standard provide input. At this stage, the document is submitted to the W3C Advisory Council for final approval

While this step is important, it rarely causes any significant changes to a standard as it passes to the next phase.

W3C recommendation (REC)

The most mature stage of development. At this point, the standard has undergone extensive review and testing, under both theoretical and practical conditions. The standard is now endorsed by the W3C, indicating its readiness for deployment to the public, and encouraging more widespread support among implementors and authors.

Recommendations can sometimes be implemented incorrectly, partially, or not at all, but many standards define two or more levels of conformance that developers must follow if they wish to label their product as W3C-compliant.

Later revisions

A recommendation may be updated or extended by separately-published, non-technical errata or editor drafts until sufficient substantial edits accumulate for producing a new edition or level of the recommendation. Additionally, the W3C publishes various kinds of informative notes which are to be used as references.

Certification

Unlike the ISOC and other international standards bodies, the W3C does not have a certification program. The W3C has decided, for now, that it is not suitable to start such a program, owing to the risk of creating more drawbacks for the community than benefits.

Membership

The Consortium is governed by its membership. The list of members is available to the public. Members include businesses, non-profit organizations, universities, governmental entities, and individuals.

Membership requirements are transparent except for one requirement: An application for membership must be reviewed and approved by the W3C, which has no final guideline about the process or standards by which membership might be finally approved or denied.

Criticism

In 2012 and 2013, the W3C started considering adding DRM-specific Encrypted Media Extensions (EME) to HTML5, which was criticised as being against the openness, interoperability, and vendor neutrality that distinguished websites built using only W3C standards from those requiring proprietary plug-ins like Flash. On September 18, 2017, the W3C published the EME specification as a recommendation, leading to the Electronic Frontier Foundation's resignation from W3C. As feared by the opponents of EME, as of 2020, none of the widely-used Content Decryption Modules used with EME is available for licensing without a per-browser licensing fee.


WAI

The Wide Web Consortium (W3C)'s Web Accessibility Initiative (WAI) is an effort to improve the accessibility of the World Wide Web (WWW or Web) for people with disabilities. People with disabilities may encounter difficulties when using computers generally, but also on the Web. Since people with disabilities often require non-standard devices and browsers, making websites more accessible also benefits a wide range of user agents and devices, including mobile devices, which have limited resources.

The W3C launched the Web Accessibility Initiative in 1997 with endorsement by The White House and W3C members. It has several working groups and interest groups that work on guidelines, technical reports, educational materials and other documents that relate to the several different components of web accessibility. These components include web content, web browsers and media players, authoring tools, and evaluation tools.

Organization

WAI develops guidelines and other technical reports through the same process as other parts of the W3C. Like other W3C initiatives, the WAI consists of several working groups and Special interest groups, each with its own focus. Only working groups can produce technical reports that become W3C recommendations. A working group can sometimes delegate specific work to a task force, which then presents its results back to the working group for approval.

Authoring Tool Accessibility Guidelines Working Group (AUWG)

The Authoring Tool Accessibility Guidelines Working Group develops guidelines, techniques and supporting resources for tools that create web content, ranging from desktop HTML editors to content management systems. The accessibility requirements apply to two types of things: the user interface on the one hand, and the content produced by the tool on the other.

Education and Outreach Working Group (EOWG)

The Education and Outreach Working Group develops materials for training and education on Web accessibility. This working group has produced documents on a wide range of subjects, including:

  • Accessibility Features of CSS.
  • Curriculum for Web Content Accessibility Guidelines 1.0.
  • Evaluating Web Sites for Accessibility, a suite of documents about subjects such as conformance evaluation, evaluation approaches for specific contexts, involving users in web accessibility evaluation, and selecting web accessibility evaluation tools.
  • Planning Web Accessibility Training.
  • Developing a Web Accessibility Business Case for Your Organization
  • How People with Disabilities Use the Web, a document that describes various fictitious characters with disabilities and how they use the Web in different scenarios.
  • Many introduction pages on the WAI website.

Currently, the working group has a task force to support the work done in the WAI-AGE project. This project published a document that reviews literature about the needs of older users and compares these needs with those of people with disabilities as already addressed in WAI guidelines.

Evaluation and Repair Tools Working Group (ERT WG)

The Evaluation and Repair Tools Working Group develops technical specifications that support the accessibility evaluation and repair of Web sites. It also maintains a database of tools for evaluating Web sites and for making them more accessible ("repair", "retrofitting"). The working group consists mainly of developers of such tools and researchers. Current work focuses on:

  • Evaluation and Report Language (EARL): a language for expressing evaluation reports in a machine-readable way.
  • HTTP Vocabulary in RDF, which specifies how HTTP requests and responses can be expressed in RDF.
  • Representing Content in RDF, which specifies how content (retrieved from the Web or a local storage device) can be represented in RDF.
  • Pointer Methods in RDF, early work on how locations in and parts of online documents can be expressed in RDF.

Protocols & Formats Working Group (PFWG)

The Protocols & Formats Working Group reviews all W3C technologies for accessibility before they are published as a recommendation. It has also published a note on accessibility issues of CAPTCHA, a paper on natural language usage for people with cognitive disabilities, and initial work on accessibility requirements for XML-based markup languages (XML Accessibility Guidelines).

In 2006, the working group started development of a set of document and specifications for accessible rich internet applications: WAI-ARIA.

User Agent Accessibility Guidelines Working Group (UAWG)

This group develops guidelines, techniques and other documents to promote the accessibility of user agents: browsers and plug-ins.

WAI Interest Group (WAI IG)

The WAI Interest Group is an open group with a mailing list to which anyone can subscribe. W3C staff post announcements of new WAI documents to this mailing list to invite reviews and comments. Members of the list also post announcements of relevant events and publications, and ask advice on issues related to web accessibility.

Web Content Accessibility Guidelines Working Group (WCAG WG)

The Web Content Accessibility Guidelines Working Group produces guidelines, techniques and other supporting documents relating to the accessibility of Web content. Web content refers to any information you may find on a Web site: text, images, forms, sound, video, etcetera, regardless whether these were produced on the server side or on the client side (with a client-side scripting language such as JavaScript). Thus, the guidelines also apply to rich internet applications.

The working group consists of representatives from industry, accessibility consultancies, universities, organizations that represent end users, and other accessibility experts.

The working group published the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) as W3C Recommendation in 1999, followed by techniques documents in 2000. In 2001, the working group started work on WCAG 2.0, which became a W3C Recommendation on 11 December 2008.

WAI Coordination Group

The WAI Coordination Group co-ordinates that activities of the WAI working groups (and interest groups). Its activities are not public.

Guidelines and technical reports

Web Content Accessibility Guidelines (WCAG)

See below.

Authoring Tool Accessibility Guidelines (ATAG)

Developed by the Authoring Tool Accessibility Guidelines Working Group, the ATAG 2.0 became a W3C Recommendation on 24 September 2015. ATAG is a set of guidelines for developers of any kind of authoring tool for Web content: simple HTML editors, tools that export content for use on the Web (for example, word processors that can save as HTML), tools that produce multimedia, content management systems, learning management systems, social media, etc.
The goal is for developers to create tools that accessible to authors regardless of disability, produce accessible content by default and support and encourage authors to create accessible content.

Implementing ATAG 2.0 is a companion document that provides guidance on understanding and implementing ATAG 2.0. It gives an explanation of the intent of each success criterion, examples of the success criterion, and additional resources. Implementing ATAG 2.0 recommendations can reduce the costs for accessibility because authors are given the tools they need to create accessible content.

Authoring Tool Accessibility Guidelines 1.0 was published in 2000 by the Authoring Tool Accessibility Guidelines Working Group.

User Agent Accessibility Guidelines (UAAG)

Developed by the User Agent Accessibility Guidelines Working Group, the UAAG 1.0 became a W3C Recommendation on 17 December 2002. The UAAG is a set of guidelines for user agent developers (such as web browsers and media players) aimed at making the user agent accessible to users with disabilities.

The working group is currently working on a new version of the guidelines. The first public draft of User Agent Accessibility Guidelines 2.0 was published on 12 March 2008.

Accessible Rich Internet Applications (WAI-ARIA)

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification which became a W3C Recommended Web Standard on 20 March 2014. It allows web pages (or portions of pages) to declare themselves as applications rather than as static documents, by adding role, property, and state information to dynamic web applications. ARIA is intended for use by developers of web applications, web browsers, assistive technologies, and accessibility evaluation tools.

WCAG

The Web Content Accessibility Guidelines (WCAG) are part of a series of web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the Internet. They are a set of recommendations for making Web content more accessible, primarily for people with disabilities—but also for all user agents, including highly limited devices, such as mobile phones. WCAG 1.0 were published in May 1999 and WCAG 2.0, in December 2008, becoming an ISO standard. WCAG 2.1 became a W3C Recommendation in June 2018.

WCAG 1.0

The WCAG 1.0 were published and became a W3C recommendation on 5 May 1999. They have since been superseded by WCAG 2.0.

WCAG 1.0 consist of 14 guidelines—each of which describes a general principle of accessible design. Each guideline covers a basic theme of web accessibility and is associated with one or more checkpoints that describes how to apply that guideline to particular webpage features.

  • Guideline 1: Provide equivalent alternatives to auditory and visual co.ntent
  • Guideline 2: Don't rely on colour alone.
  • Guideline 3: Use markup and style sheets, and do so properly.
  • Guideline 4: Clarify natural language usage.
  • Guideline 5: Create tables that transform gracefully.
  • Guideline 6: Ensure that pages featuring new technologies transform gr.acefully
  • Guideline 7: Ensure user control of time sensitive content changes.
  • Guideline 8: Ensure direct accessibility of embedded user interfaces.
  • Guideline 9: Design for device independence.
  • Guideline 10: User interim solutions.
  • Guideline 11: Use W3C technologies and guidelines.
  • Guideline 12: Provide context and orientation information.
  • Guideline 13: Provide clear navigation mechanisms.
  • Guideline 14: Ensure that documents are clear and simple.

Each of the in total 65 WCAG 1.0 checkpoints has an assigned priority level based on the checkpoint's impact on accessibility:

  • Priority 1: Web developers must satisfy these requirements, otherwise it will be impossible for one or more groups to access the Web content. Conformance to this level is desibed as A.
  • Priority 2: Web developers should satisfy these requirements, otherwise some groups will find it difficult to access the Web content. Conformance to this level is descrid as AA or Double-A.
  • Priority 3: Web developers may satisfy these requirements to make it easier for some groups to access the Web content. Conformance to this level is described as AAA or Triple-A.

WCAG Samurai

In February 2008, The WCAG Samurai, a group of developers independent of the W3C, and led by Joe Clark, published corrections for, and extensions to, the WCAG 1.0.

WCAG 2.0

WCAG 2.0 were published as a W3C Recommendation on 11 December 2008. They consist of twelve untestable guidelines organized under four principles (websites must be perceivable, operable, understandable, and robust). Each guideline has testable success criteria (61 in all). The W3C's Techniques for WCAG 2.0 is a list of techniques that help authors meet the guidelines and success criteria. The techniques are periodically updated whereas the principles, guidelines and success criteria are stable and do not change.

Principles

  1. Perceivable

    Information and user interface components must be presentable to users in ways they can perceive.

    • Guideline 1.1: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
    • Guideline 1.2: Time-based media: Provide alternatives for time-based media.
    • Guideline 1.3: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
    • Guideline 1.4: Make it easier for users to see and hear content including separating foreground from background.
  2. Operable

    User interface components and navigation must be operable.

    • Guideline 2.1: Make all functionality available from a keyboard.
    • Guideline 2.2: Provide users enough time to read and use content.
    • Guideline 2.3: Do not design content in a way that is known to cause seizures.
    • Guideline 2.4: Provide ways to help users navigate, find content, and determine where they are.
  3. Understandable

    Information and the operation of user interface must be understandable.

    • Guideline 3.1: Make text content readable and understandable.
    • Guideline 3.2: Make web pages appear and operate in predictable ways.
    • Guideline 3.3: Help users avoid and correct mistakes.
  4. Robust

    Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

    • Guideline 4.1: Maximize compatibility with current and future user agents, including assistive technologies.

    WCAG 2.0 uses the same three levels of conformance (A, AA, AAA) as WCAG 1.0, but has redefined them. The WCAG working group maintains an extensive list of web accessibility techniques and common failure cases for WCAG 2.0.

Further information