W3C logoWeb Accessibility Initiative (WAI) logo

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

Questions and Answers about Baseline and WCAG 2.0

Page Contents

Background

The World Wide Web has evolved considerably since the release of the 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 be a document that would 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. As new technologies come out it is not necessarily a valid assumption that user agents including assistive technologies will be able to support them all on the day they are announced. Some mechanism defining the technologies that can be assumed to be enabled and working in user agents (including AT) is needed. The group, however, found that choosing any set of technologies and defining it in WCAG (overtly or through the definition of the success criteria) would quickly date the new guidelines, as the previous (WCAG 1.0) guidelines 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 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".

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.

What is a baseline?

A "baseline" (as used in WCAG 2.0) is the set of such 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 conforms to WCAG 2.0 assuming that user agents support only of the technologies in the baseline (and have them enabled).

The Baseline may be set by the author or another individual, or organization or a governmental body. 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. When baselines are set by someone else, authors may actually rely on only some of the technologies in the baseline (a subset of them).

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 many have browsers that support them while others may not.

Examples of Baselines (and what they mean) include

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

A claim using this baseline means that, if the user agent supports these technologies, the content satisfies all success criteria for the conformance level claimed by the author.

This baseline allows any content that can be created in 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 may rely upon these technologies, and may 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 Transitional, 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. SC 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 delivery unit contains instructions before the control that describe the behavior. If JavaScript were listed in the baseline, the script techniques listed as “sufficient” in Understanding WCAG 2.0 could 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 SC 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.

JavaScript is not listed in Sample Baseline 1, however, so using this script technique would not be sufficient for the Baseline in example1. 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 save to assume that people’s user agents (including assistive technologies) will all support JavaScript, it would be appropriate to use Example 2 Baseline.    If people’s user agents (and AT) cannot be counted on to support JavaScript, then the Example 1 Baseline would be the only appropriate one to specify.

Example 3 Baseline: HTML 4.01 Transitional, CSS, GIF, JPEG, MOV, AVI class=GramE>, MP3, RM, RT

Sample Baseline 1 does not include multimedia technologies such as audio and video. What happens if the Web unit includes multimedia?

Since audio and video formats are not listed in Example Baseline 1, these technologies may be used, but not relied upon style='mso-bidi-font-style:italic'> (for Sample Baseline 1 content) because it cannot be assumed that users have accessible media players. If a Web page does use multimedia, an alternative version of the content that relies only upon technologies in the baseline must be available from the same page as the multimedia—even if captions and audio descriptions are available for the multimedia. The alternate version must provide all of the same information and functionality as the multimedia, and it must be updated whenever the multimedia content is updated (as required by SC 4.2.1).

However – with Sample Baseline 2 the author could rely on the multimedia access features.    So a movie with captions and audio descriptions would be sufficient for level 1 conformance.    It would not be necessary to provide all the information in another accessible format.

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 all stakeholders who are creating 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?

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 sample baselines discussed above are just that: samples. 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 users whose agents can support the stated baseline technologies for that content.

If developers choose a baseline that is too high, that includes too many technologies that are not supported by user agents in use by people with disabilities, then those sites or that content may not be accessible to those people. It is up to developers to use baselines that are reasonable and appropriate to the times and the technical levels of user agents of people with disabilities.

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 (e.g. public information vs. internal content) or environments (Worldwide Web vs. Intranet).

What is available to help developers choose a baseline?

There is an informative document called “How to Meet SC x.x.x” for each success criterion. This "How to Meet" document 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. The “How to Meet” document also shows who benefits from the success criterion, and lists examples and related resources for further information for that WCAG 2.0 success criterion. In addition, the individual technique documents have a section titled “User Agent and Assistive Technology Support Notes” where appropriate 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 the "How to meet..." documents describe 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 where appropriate.

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.

Most major non-W3C technology providers are in the process of developing accessibility techniques that will help users of their technologies meet the WCAG guidelines. 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 Baseline?

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

The technological environment of today 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 proposed 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 Baseline 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 1, 2 or 3).
  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 URI's 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" includes markup languages, style sheet languages, scripting/programming languages, image formats, and multimedia formats.
    • "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 even if that technology is 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, 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. class=GramE> class=grame>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/Baseline#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, class=spelle>png. class=GramE> class=grame>" 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 the WCAG 2.0 except for a section where people post information and class=GramE>files. We cannot always be sure they will post conforming content. What do we do?"

Answer

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

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 any portions of a site and/or can claim all but certain sections of the site.

"Horizontal scoping" (scoping out a particular technology within Web units) is not allowed. A company could not say something like "our content conforms to the WCAG 2.0 at level 1 except all the navigation menus are not compliant," 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 content (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 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 AT combination).

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

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 (Windows, Macintosh, Unix, Windows XP, Windows 2000, Windows ME, Windows 98, Windows 95). Sometimes service packs can make a difference. When dealing with the Internet, it is therefore important to think in terms of technologies and not browsers.

Below are some question 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. Is each candidate technology supported only by user agents that are very expensive so that the cost is likely to be prohibitive for the audience, making it 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