Since the release of the WCAG 1.0 in 1999, the World Wide Web has evolved considerably. The WCAG 1.0 was written assuming that Web users would primarily be using HTML. Today, the Web is used in hundreds 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 2.0 working group realized that it would have to find a different basis upon which to form the 2.0 guidelines. It would have to present Web accessibility as a set of principles that would work across all of todays 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 an accessible Web content yet allow for differences between technologies and cultures without introducing incompatible guidelines between countries.
To address these needs the working group has developed a set of guidelines (with success criteria) that are technology independent. This guideline document is accompanied by a second information document (called Understanding WCAG 2.0) that provides examples and lists of techniques that are sufficient to meet the guidelines. By using this two layered approach, it is possible to have stable criteria for accessibility with supporting technical documents that will be "evergreen" and updated as the technologies evolve.
A key element in this model is the ability to define the set of technologies that user agents can be assumed to support. The group however found that any set of technologies it chose would quickly date the guidelines as the last guidelines were. 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 out UAAG 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".
A “baseline” (as used in WCAG 2.0) is a set of technologies that a user agent (browser, media player, screen reader etc.) is assumed to support and have enabled. The Baseline may be set by the author or someone above them. When an author makes a WCAG 2.0 conformance claim, they must specify the Baseline that they are using to make that claim. The author is claiming that their content will meet WCAG 2.0 at the stated level of conformance if a user’s agent can support those (the baseline) technologies.
The author may actually rely on only some of the technologies in the baseline (a subset of them). When they make their claim they can therefore also say exactly what they are relying on for their claim. This is a more precise description of the part of the baseline that they are relying on and can be helpful to consumers whose user agent does not fully support the named baseline. (This additional "relies on" information would be optional in a conformance claim).
Developers may choose to use additional technologies that are not in the minimum set (the baseline) provided that the following are true:
If the user’s agent supports this technology, then the content meets WCAG 2.0 at the level the author claims.
This content might also use CSS2, Real Video, Real Audio, and MP3. However, even if the user’s agent does not support these, the content claimed would still meet WCAG 2.0 at the level claimed.
If the user’s agent supports these technologies, then the content meets WCAG 2.0 at the level the author claims.
This content might also use other technologies. However, even if the user’s agent does not support these, the content claimed would still meet WCAG 2.0 at the level claimed.
The Baseline #1-2006 might include for example HMTL 4.01, gif, jpg, avi, mov, and other a few other commonly supported technologies.
If the user’s user agent supports the technologies in that baseline, then the content meets WCAG 2.0 at the level the author claims.
The author may only use a subset of these technologies in the web pages they are claiming. They may therefore state that they are only relying on HTML 4.01 and gif. That would mean that their pages would conform to WCAG 2.0 at the claimed level if the users' user agents only supported these technologies. Note that the "relies on" technologies must always be a subset of the Baseline technologies.
This content might also use JavaScript 1.2, CSS2, PDF and Flash. However, even if the user’s agent does not support these, the content claimed would still meet WCAG 2.0 at the level claimed.
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 is not browser-specific nor user agent specific. It is a set of technologies. There is a subtle but important distinction. 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.
The baseline statement is a 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 needs to 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. As a part of a conformance claim one cannot exclude people with disabilities from the target audience.
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’s 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.
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.
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 chose 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.
There will be an "How to meet SC x.x.x" document for each success criteria. This "how to meet" document will include key terms, the intent, sufficient and optional techniques, common failures, who benefits, examples, and related resources for further information for that WCAG 2.0 success criterion. Within some of these docs (where appropriate) there will be example baselines for various circumstances. These can be used as templates that can be adapted to specific environments.
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.
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 criteria of the guidelines, the technique docs will provide detail on both sufficient and advisory techniques including examples, code, and test procedures where appropriate.
W3C is not in a position to create guidance documents for other companies' technologies. However W3C is working with them 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.
The User Agent Accessibility Guidelines (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:
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.
On 13 March 2005, www.johnpointer.com conforms to W3C's WCAG 2.0, Conformance Level 1.The baseline for this claim is XHTML 1.0. The specification that this content *relies upon* is: XHTML 1.0. The specifications that this content *uses* are: CSS2, Real Video, Real Audio, MP3, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.01 (Windows, Linux), IE 3.0 and 6.0 (Windows, Mac), Jaws 3.7 and Jaws 6.0 (windows), Safari 1.2 (Mac), Opera 7.5 (OSX).
On 1 August 2006, "S5: An Introduction" http://meyerweb.com/eric/tools/s5/s5-intro.html conforms to W3C's WCAG 2.0. Conformance Level 1. 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). The specifications that this content *uses* are: JavaScript 1.2, CSS2, png, and jpg.
On 1 July 2005, "Photo gallery application" http://foo.makeyourownslideshow.com conforms to W3C's WCAG 2.0, Conformance Level 1. The baseline is ISA-Baseline#2-2005 at http://ISA.gov/Baselines/BL2-2005. The specifications that this content *relies upon* are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpg. The specification that this content *uses* is: gif. The techniques profile that this content uses is, "HTML/ECMAScript for latest browsers."
We are planning to have our content conform to the 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?
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 delivery 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 delivery units and would not be a valid or acceptable WCAG 2.0 conformance claim. Any Web content (delivery unit or set of delivery units) that is part of a conformance claim must meet all of the Success Criterion for the level that it claims.
(Note that in example 4 the author is not specifying the user agent; the company had specified the user agent in advance. The author just has knowledge that only that agent is used so the author has very good knowledge of the technologies the user agent supports. Care must be taken here however since that agent would have to be cross disability accessible or else the author's assumptions may be bad because users with disabilities may have to use other user agents to access the content.)
Developers may use technologies that are not in the specified baseline provided that the both of the following are true:
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.
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).
NOTE: Care must be taken when making assumptions about which assistive technologies will be used in a company.
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, Mac, Unix? Windows XP, Windows 2000, Windows ME, Win98, Win 95). 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.
Some question to consider
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.
Note: Some examples of entities that may set baselines that an author may have to follow include the author, a company, a customer and government entities.
Note: This term was taken verbatim from Glossary of Terms for Device Independence.