W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

[OUTDATED DOCUMENT] About Baselines and WCAG 2.0

NOTE: This document is outdated. WCAG 2.0 Working Drafts no longer use the concept of "Baseline". Please see the Conformance sections of WCAG 2.0 and Understanding WCAG 2.0 for updated information.

Background

The World Wide Web has evolved considerably since the release of the Web Content Accessibility Guidelines (WCAG) 1.0 in 1999. The WCAG 1.0 was written assuming that Web users would primarily be using HTML. Today, the Web is used in hundreds of ways that were not possible in 1999. Many new Web technologies are emerging and existing technologies are becoming more comprehensive as the Web community finds new and original ways to disseminate information and interact with it. Also, due to language, economic differences, and other factors, technologies that are common in one part of the world may not be present, or may not be as up to date, in others

Given these realities, the WCAG working group realized that it would have to find a different basis upon which to form version 2.0 of the guidelines. It would have to present Web accessibility as a set of principles that would work across all of today's technologies and that would be robust enough to withstand dramatic shifts and changes in technology. The WCAG 2.0 would have to apply to a wide range of W3C and non-W3C technologies. It would need to give policy makers and managers guidance about what outcomes are necessary when striving to create accessible Web content, yet allow for differences between technologies and cultures without introducing guidelines that are incompatible between countries.

To address these needs, the working group has developed a set of guidelines and success criteria that are technology independent. These are presented in the document, Web Content Accessibility Guidelines 2.0. This guideline document is accompanied by an informative document called Understanding WCAG 2.0 that provides examples and lists of techniques that are sufficient to meet the success criteria in WCAG 2.0. This two-layered approach makes it possible to have stable criteria for accessibility with supporting technical documents that can be updated as the technologies evolve and new ways of satisfying the success criteria are developed.

A key element in this model is the ability to define the set of technologies that user agents can be assumed to support. It is not valid to assume that user agents, including assistive technologies, will support all new technologies on the day they are announced. Some mechanism defining the technologies that can be assumed to be enabled and working in user agents (including assistive technologies) is needed. The group, however, found that choosing any set of technologies and defining it in WCAG 2.0 (overtly or through the definition of the success criteria) would quickly date the new guidelines, as the WCAG 1.0 had become dated. It would limit the ability of Web content that is accessible in the future, using future technologies, to claim conformance using those new technologies.

After trying to solve the problem several times in this manner (including trying to use the User Agent Accessibility Guidelines (UAAG) 1.0 to define the set of technologies; see below), the working group determined that the only way to solve the problem was to introduce a new concept: "baseline".

What is a baseline?

A "baseline", as used in WCAG 2.0, is the set of technologies that an author assumes are supported and turned on in accessible user agents. Authors must ensure that all information and functionality of the Web content conform to WCAG 2.0 even when a user agent supports and uses only the technologies in the baseline.

A baseline may be set by a government body, client, organization, author, or combination of these. When authors make WCAG 2.0 conformance claims, they must specify the baseline that they are using to make that claim. In making their claim they are then claiming that the content will meet WCAG 2.0 at the stated level of conformance if a user agent can support the technologies listed in the baseline. Authors may actually rely on only some of the technologies in a baseline (a subset).

Non-baseline technologies can also be used, but all information and functionality of the Web content must conform both with all non-baseline technologies turned on and with the non-baseline technologies turned off. Both conditions are necessary since some users may have browsers that support them while others may not.

Examples of baselines (and what they mean)

Example 1 Baseline: HTML 4.01 Transitional, .GIF, and .JPEG

Conformance using this baseline means that all content meets WCAG 2.0 (at the level claimed by the author) for all user agents that support these technologies.

This baseline includes HTML 4.01, in addition to .GIF and .JPEG images, the most widely used image formats today. This extremely limited baseline might be appropriate for content aimed at a very broad audience when there is little or no specific knowledge about what user agents are available to that audience. Authors using this baseline would rely on just these 3 technologies to conform. They would use the HTML 4.01 techniques described as “sufficient” in Understanding WCAG 2.0. (Authors may further enhance the user experience by also using additional HTML techniques listed as “advisory” (optional) in Understanding WCAG 2.0.)

Example 2 Baseline: HTML 4.01, CSS, GIF, JPEG, and JavaScript.

Consider the scenario of a Web site that provides a list of “quick links” for navigating to frequently accessed sections of the site. Success Criterion 3.2.2 requires that changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order) unless the Web unit contains instructions before the control that describe the behavior. Since JavaScript is listed in the baseline, the script techniques listed as “sufficient” in Understanding WCAG 2.0 can be relied upon to produce conforming content, and it would not be necessary to provide alternatives that work when JavaScript is disabled. In the case of Success Criterion 3.2.2, this would mean that the script technique “Hiding and showing content based upon a select element change” together with the general technique “Providing a submit button to initiate a change of context” would be sufficient.

Example 3 Baseline: HTML 4.01, CSS, GIF, JPEG, MOV, AVI, MP3, RM, RT

In this example, multimedia technologies are included in the baseline. A movie with captions and audio descriptions would therefore be sufficient for level 1 conformance. It would not be necessary to provide all the information in another accessible format, as would be true for Web units claiming conformance under the baselines in example 1 and Example 2 above.

Notes on the above examples

Javascript

In Example 2, we find Javascript in the baseline. Therefore, the Javascript technique mentioned would satisfy the Success Criterion. JavaScript is not listed in Example Baseline 1, however, so using this same script technique would not be sufficient for the Baseline in Example 1. Instead, the HTML technique “Providing submit buttons in HTML” together with the general technique “Providing a submit button to initiate a change of context” would be sufficient. JavaScript might still be used within the Web unit for other purposes, but accessible alternatives that do not rely on JavaScript would be required.

Here we can see how the baseline concept works. In environments where it is safe to assume that people’s user agents (including assistive technologies) will all support JavaScript, it would be appropriate to use Example 2 Baseline (and use JavaScript). If people’s user agents (including assistive technologies) cannot be counted on to support JavaScript, then the Example 1 Baseline would be the only appropriate one to specify (where JavaScript could be used but not relied on). Thus JavaScript could be used but all of the information and functionality would need to be accessible with JavaScript turned off or disabled).

Multimedia

Example Baseline 1 and Example Baseline 2 do not include multimedia technologies such as audio and video. Can the Web unit include multimedia? Yes. But since audio and video formats are not in these example baselines, these technologies can not be relied upon as the only way to provide information and functionality. If a Web page does use multimedia (under Example Baseline 1 or 2) an alternative version of the content would be required made all the information and functionality available using ONLY the technologies in the baseline. The alternate version must also be updated whenever the multimedia content is updated. This alternate version might, for example, be a text screenplay of the multimedia (that exactly matches the multimedia).

Baseline specifications are not browser specifications

The baseline is not the same as statements such as "this Web content works best using IE 6.0". This would be an invalid baseline statement. The baseline cannot be browser or user agent specific. It is a set of technologies. There is a subtle but important distinction. The types of technology to be listed in the baseline include but are not limited to:

These are classes of technology used to create content or make it available to users via the user agent. A baseline, then, is a list of specific technologies that belong to the classes above.

One reason it is important to be technology-specific rather than user agent specific is that restricting users to specific user agents may pose insurmountable accessibility problems for some people. It would be almost impossible to know all of these problems in advance unless perhaps the content was to be used in a closed environment.

Baselines are not about audience abilities

The baseline statement is also not a statement about what physical, sensory or cognitive abilities are required to use content. It is a technology-specific statement about what technologies a user agent must support for the content to be accessible at the claimed level.

One assumption that must be made by anyone who creates Web content is that the target audience will include people with disabilities. People with disabilities are to be considered an integral part of all demographics. One cannot exclude people with disabilities from the target audience.

Using baselines in conformance claims

In claiming conformance to WCAG 2.0, developers are claiming that all information and functionality of the Web content conforms to WCAG 2.0 at a given level if the user agent supports the stated baseline technologies.

Over time, the baselines used by various organizations and governments may change to accommodate new technological advances. The intention of the WCAG 2.0 is that the principles and functional outcomes of the guidelines remain stable during technological change because they are both technology independent and baseline independent.

Who sets the baseline?

Baselines may be set by individual authors, organizations (including corporations, non-governmental or nonprofit organizations), or governmental bodies.

Although there was no mention of a baseline in the 1999 WCAG 1.0 Guidelines, there was an implicit baseline used for those guidelines. Simply put, the WCAG 1.0 assumed a baseline of HTML, and a few graphic and media technologies. In this respect, a baseline was assumed and was "hard wired" into the specifications. Since WCAG 1.0 was written with HTML in mind, a baseline was set by and included in the guidelines themselves. The constraints this presented were a key reason for the need for WCAG 2.0.

In the WCAG 2.0 Guidelines, no particular baseline is assumed. Instead the baseline is assumed to be set outside of the WCAG 2.0 document. The baseline may be set by any one of a number of sources.

The WAI may provide guidance in setting baselines, but is not setting "The Baseline" or "A Baseline" for WCAG 2.0. The example baselines discussed above are provided simply for the purpose of demonstrating and discussing how the baseline concept works. They do not represent baselines recommended by the WCAG Working Group, the WAI, or the W3C.

If the WCAG does not set the baseline, then how can we be sure that a site will be accessible?

No site or content is ever completely accessible.

Conformance to WCAG 2.0 at some level provides that level of accessibility for people whose user agents can support the stated baseline technologies for that content.

If developers do not use reasonable baselines, then it is up to companies, customers, or regulatory agencies to set baselines that are appropriate for the time and possibly for different types of content (for example public information available on the World Wide Web vs. content available only to internal users of an intranet within a specific organization).

What is available to help developers choose a baseline?

The informative document called “Understanding WCAG 2.0”“contains information about how to meet each success criterion. “Understanding WCAG 2.0” provides important information about the success criterion, including definitions of key terms (also available in the normative Glossary), an explanation of the intent of the success criterion, and a list of sufficient and optional techniques as well as common failures. “Understanding WCAG 2.0” also shows who benefits from the success criterion, and lists examples and related resources for further information for that success criterion. When appropriate, individual technique documents include a section titled “User Agent and Assistive Technology Support Notes” that provides information on the support for different techniques or technologies by assistive technologies

The W3C-WAI may also prepare "A Guide for Policy Makers" to help organizations choose a baseline that will ensure the maximum accessibility for their environments. There may also be resources that describe what user agent support is available in different languages and different geographies.

What other aids will be available for developers?

W3C technologies

The WCAG will provide technology-specific techniques documents for various W3C technologies. Where "Understanding WCAG 2.0 " lists sufficient ways to meet each success criterion of the guidelines, the technique documents will provide detail on both sufficient and advisory techniques, including examples, code, and test procedures.

Non-W3C technologies

W3C is not in a position to create guidance documents for technologies not developed by the W3C. However, W3C is working with vendors to develop similar materials.

Many major non-W3C technology providers are in the process of developing accessibility techniques that will help users of their technologies meet the WCAG 2.0 success criteria. Just as with W3C technologies, in order to claim conformance, any content using these technologies will have to meet all of the level 1 WCAG 2.0 success criteria.

For non-W3C technologies that do not have their own techniques documents, the functional outcomes described in the success criterion can be used to evaluate content for accessibility at the three WCAG 2.0 levels of conformance.

Why wasn't UAAG used as baselines?

The User Agent Accessibility Guidelines 1.0 (UAAG) will provide helpful direction to stakeholders who are choosing a baseline. It was a serious consideration of the working group to use the UAAG as the WCAG 2.0 baseline. In fact, the working group tried to do that at one point. However, after careful consideration and much effort and research, it was determined that the UAAG would not be a workable baseline for the WCAG for many reasons including the following:

Note: Although UAAG 1.0 does not provide the baseline for WCAG 2.0 for the reasons discussed above, UAAG is useful in assessing the accessibility of user agents when trying to decide if a technology being considered for inclusion in a baseline is supported by accessible user agents. User agents that conform to UAAG 1.0 will also provide better support for Web content that conforms to WCAG 2.0.

In Closing

Today’s technological environment is vastly different from that of 1999, when the WCAG 1.0 was released. We need to respond to these new realities in a way that will empower people with disabilities in this new environment while facilitating effective technological innovation, communication, and commerce on the Web. The baseline concept is a response to these challenges. It also reflects our experience of watching the implementation of the WCAG 1.0 over the past number of years. We seek comments and suggestions and welcome your input.

Additional Information Related to Baselines and Conformance

Use of baselines within a conformance statement

A conformance claim includes the following assertions:

Required components of a conformance Claim

Conformance claims are not required. However, if you make a conformance claim, then the conformance claim must include the following assertions:

  1. The date of the claim
  2. The guidelines title/version: "Web Content Accessibility Guidelines 2.0"
  3. The URI of the guidelines: http://www.w3.org/TR/2005/REC-WCAG20-YYYYMMDD/.
  4. The conformance level satisfied: (Level A, AA or AAA)
  5. The baseline used to make the conformance claim. (If baseline is a published baseline, it can be named along with a URI that points to it. The baseline technologies can also be spelled out individually in the conformance claim. )
  6. Scope of the claim (a URI, list of URIs, or a regular expression)

Optional components of a conformance Claim

  1. A list of the specific technologies "relied upon" to create the content for which the claim is being made
    • Technologies include markup languages, programming languages, style sheets, data formats, and APIs.
    • "Relied upon" means that the content would not meet WCAG 2.0 at the claimed level if that technology is turned off or not supported.
    • The set of "Relied Upon" technologies must be a proper subset of the baseline.
  2. A list of the specific technologies that are "used" but not "relied upon"
    • If a technology is "used" but not "relied upon" the content would still meet WCAG 2.0 at the stated conformance level both when those technologies are enabled and when they are turned off or not supported.
  3. A list of user agents that the content has been tested on. This should include assistive technologies.
  4. Information about audience assumptions or target audience. This could include language or geographic information. It CANNOT specify physical, sensory, or cognitive requirements.

Examples of conformance claims

Example 1

On 23 March 2005, http://www.wondercall.example.com conforms to W3C's WCAG 2.0, Conformance Level A The baseline for this claim is XHTML 1.0. The specification that this content "relies upon" is: HTML 4.01. The specifications that this content "uses but does not rely on" are: CSS2, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4

Example 2

On 5 May 2006, "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to W3C's WCAG 2.0. Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/baselines#1-2006.html. The specification that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video. The specifications that this content "uses but does not rely on" are: JavaScript 1.2, CSS2.

Example 3

On 21 June 2007, http://example.com/nav and http://example.com/docs conform to W3C's WCAG 2.0, Conformance Triple-A. The baseline is ISA-Baseline#2-2007 at http://ISA.example.gov/baselines/BL2-2007. The specifications that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpeg, png." The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.

Vertical and Horizontal Scoping in Conformance Statements

Question

"Can content conform to WCAG 2.0 except for a section where people post information and files. We cannot always be sure they will post conforming content. What do we do?"

Answer

Conformance cannot be claimed for any section of web content that cannot be guaranteed to conform to the guidelines. One common situation where this might occur is public forums where organizations may not have complete control over what is posted to their sites.

To handle this and similar situations, WCAG 2.0 includes the concept of scoping. A conformance claim may scope out" specific sections of a site. This is "vertical scoping" (scoping out a portion of a site by URI or URI range) and is allowed. WCAG 2.0 conformance can be claimed for specific portions of a site and/or for an entire site except for specific portions of the site.

"Horizontal scoping" (scoping out a particular technology within Web units) is not allowed. An organization could not say something like "our content conforms to WCAG 2.0 at level A, except for all the navigation menus," or "our content conforms except for all the multimedia and animations." This would be scoping out parts of various Web units and would not be a valid or acceptable WCAG 2.0 conformance claim. Any Web unit or set of Web units that is part of a conformance claim at Level A or Level AA must meet all of the Success criteria for the level or levels that it claims. Any Web content for which Level AAA conformance is claimed must meet all Level 1 and Level 2 success criteria plus at least 50% of applicable Level 3 success criteria

Examples of People and Places Setting Baselines

Note that baselines are not specified in terms of specific user agents but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies)

Some initial guidance in choosing a baseline

Choosing baseline technologies is a decision based on what technologies you can assume are supported by the user agents of your audience at the time the baseline is defined. When making the baseline decision, consider the following factors.

INTRANET

If you are in a closed environment (Intranet) where the user agents used are controlled and the Assistive Technology needed to make that user agent accessible are known, then you can set a baseline that is tuned to the capabilities of that user agent. Some questions to ask about that user agent (and combination of the user agent and assistive technology) are:

  1. How well does the user agent satisfy the requirements of UAAG for each technology being considered? A source of this information will be the UAAG conformance statement for the user agent. The UAAG working group also lists draft information about some user agents on the UAAG Working Group Web site.
  2. What technologies does the user agent support? For example, what version of HTML, XHTML, CSS, PDF, Flash etc.? (This information should be available from the user agent vendor.)
  3. Which versions of assistive technology products work with the user agent? And which technologies are supported by the assistive technology, e.g., does it support JavaScript? (This information should be available from the assistive technology vendor. See also the User agent and assistive technology support sections of the techniques for the technologies that are being considered for the baseline.)

NOTE: Care must be taken when making assumptions about which assistive technologies will be used in a company.

INTERNET

Most Web content is designed to be posted on the World Wide Web. For this content it is not possible to know what platform or user agent people will be using. It may be any one of many user agents running on any one of a number of operating systems. Sometimes service packs can make a difference. When dealing with the Internet, therefore, it is important to think in terms of technologies and not browsers.

Below are some questions to consider.

  1. For which platforms and operating systems is a user agent available for each technology being considered? Windows, Mac, Unix? Windows XP, Windows 2000, Windows ME, Windows 98, Windows 95, etc. Do operating system Service Packs affect the accessibility of the user agent?
  2. Is each candidate technology supported by a user agent (if one exists) in all the languages used by the audience? Is it available in the language of the content?
  3. Is each candidate technology supported by recent versions of a user agent your audience is using? Users do not always upgrade to newer versions of user agents, or may not do so immediately.
  4. 4. Is each candidate technology supported only by user agents that are very expensive? If that the cost is likely to be prohibitive for the audience, the content will be effectively unavailable.
  5. If support for a technology by a user agent depends upon optional software such as a plug-in, how difficult is it for users to obtain the plug in? Will they be prompted to install the software automatically if they try to use it? Is the accessible version of the plug-in different from the one that is usually downloaded or pointed to? Do you need to provide a link to the accessible version of the plug-in as part of the content?
  6. Does the technology have an open standard or a public specification?

An appropriate baseline for accessible Web content will make a conservative choice to ensure that users will have accessible user agents for rendering the Web content. However, this does not prohibit the use of other technologies, as long as they are used in such a way that user agents that support only the technologies in the baseline can still render the content accessibly.

Glossary

See Glossary in WCAG 2.0 at http://www.w3.org/TR/WCAG20