This section is normative.
Conformance means that Web content satisfies the success criteria defined in this document. This section outlines the conformance scheme used throughout this document.
The success criteria for each guideline are organized into three (3) levels.
Level 1 success criteria:
Achieve a minimum level of accessibility through markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies.
Can reasonably be applied to all Web resources.
Level 2 success criteria:
Achieve an enhanced level of accessibility through one or both of the following:
markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies
the design of the content and presentation
Can reasonably be applied to all Web resources.
Level 3 success criteria:
Achieve additional accessibility enhancements for people with disabilities.
Are not applicable to all Web resources.
Note: Guidelines do not necessarily contain success criteria at every level. Some have success criteria at only one level.
This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people.
The WCAG Working Group also believes that all WCAG 2.0 success criteria are testable. Some can be tested by computer programs while others must be tested by qualified human testers. When multiple people who understand WCAG 2.0 test the same content using the same success criteria, the same results should be obtained with high inter-rater reliability.
Note: For each success criterion, there is a list of techniques deemed by the working group to be sufficient to meet the requirement. For each technique, there is a test to determine whether the technique has been successfully implemented. If the test(s) for a "sufficient" technique or combination of techniques is passed, then the working group would consider that success criterion met. However, passing all tests for all techniques is not necessary. Nor is it necessary to meet a success criterion using one of the sufficient techniques. There may be other techniques which are not documented by the working group that would also meet the success criterion.
WCAG 2.0 defines accessibility guidelines (goals) and success criteria (testable criteria for conformance at different levels of accessibility). The guidelines and success criteria are described in a technology-independent way in order to allow conformance using any Web technology that supports accessibility. WCAG 2.0, therefore, does not require or prohibit the use of any specific technology. It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as the technologies are supported by accessible user agents including assistive technologies.
WCAG 2.0 uses the term user agent to mean: Any software that retrieves and renders Web content for users. This may include Web browsers, media players, plug-ins, and other programs - including assistive technologies - that help in retrieving and rendering Web content. It is important to note that assistive technologies are included in this definition. Assistive technologies include screen readers, screen magnifiers, on-screen and alternative keyboards, single switches, voice recognition and a wide variety of input and output devices that meet the needs of people with disabilities.
In choosing Web technologies (HTML, scripting, etc.) that will be used when building content, developers need to know what technologies they can assume will be supported by, and active in, the user agents (including assistive technologies) that people with disabilities will be using. If authors rely on technologies that are not supported, then their content may not be accessible.
The set of such technologies that an author assumes are supported and turned on in accessible user agents is called a baseline. Developers must ensure that all information and functionality of the Web content conforms to WCAG 2.0 assuming:
that user agents support all the technologies in the baseline, but no other technologies and
that those technologies that are listed in the baseline are all enabled
Note: See also Use of technologies outside of the baseline .
Baselines may be set by authors, companies, customers and governmental bodies.
WCAG 2.0 does not specify any particular baseline. There are several reasons for this. First, what is appropriate in a baseline may differ for different environments. For example, in the case of content that will be viewed only by employees of a particular company, it may be possible to assume that user agents support more advanced technologies if the company provides the necessary user agents (including assistive technology) to all employees. For public Websites, however, a more conservative level of technology may be all that can be reasonably assumed. Baselines may also vary by jurisdiction. Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time.
Some examples of baselines
Example 1: A government site that provides information to the public A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release. The government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies.
Example 2: A particular government provides high level accessible user agents to all citizens who need them A government provides all citizens with user agents that support newer technologies. The government is thus able to specify a baseline that includes these newer technologies for all of its Websites for its citizens since the government can assume its citizens' user agents can handle the technologies.
Example 3: A private intranet An organization (public or private) provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only by the user agent that the organization provides for its employees. Because the company controls the user agents that will view its internal content, the author has a very accurate knowledge of the technologies that those user agents (including assistive technologies) support.
Note: In the examples above, the baseline is 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).
Developers may also use technologies that are not in the specified baseline provided that the following are true:
All content and functionality are available using only the technologies in the specified baseline.
The non-baseline technologies do not interfere with (break or block access to) the content
when used with user agents that only support the baseline technologies
when used with user agents that support both the baseline and the additional technologies.
Additional (informative) information on baselines can be found at Questions and Answers about Baseline and WCAG 2.0.
WCAG 2.0 conformance at level A means that all Level 1 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.
WCAG 2.0 conformance at level Double-A (AA) means that all Level 1 and all Level 2 success criteria in the guidelines are met assuming user agent support for only the technologies in the chosen baseline.
WCAG 2.0 conformance at level Triple-A (AAA) means that all Level 1, Level 2 and 50% of the Level 3 success criteria that apply to the content types used are met assuming user agent support for only the technologies in the chosen baseline.
If a success criterion relates to a technology that is not used in the content (for example, there is no multimedia on the site), then that success criterion is met automatically.
Conformance claims apply to Web units, and sets of Web units. (Web units often take the form of a traditional Web page but can also take the form of a fully interactive and immersive environment.)
Conformance claims are not required. However, if you make a conformance claim then conformance claim must include the following assertions:
The date of the claim
The guidelines title/version: "Web Content Accessibility Guidelines 2.0"
The URI of the guidelines: http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/
The conformance level satisfied: (Level A, AA or AAA)
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.)
Scope of the claim (a URI, list of URI's or a regular expression defining a set of URIs)
A list of additional success criteria that have been met beyond a standard claim
A list of the specific technologies "relied upon" to create the content for which the claim is being made. (This 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 technologies.
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.
A list of user agents that the content has been tested on. This should include assistive technologies.
Information about audience assumptions or target audience. This could include language, geographic information, or other pertinent information about the intended audience. The target audience information CANNOT specify anything related to disability or to physical, sensory or cognitive requirements.
Example 1: On 13 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: XHTML 1.0. 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.01 (Windows, Linux), IE 3.0 and 6.0 (Windows, Mac), Jaws 3.7 and Jaws 6.0 (Windows), Safari 1.2 (Mac), and Opera 7.5 (OSX).
Example 2: On 1 August 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.6, 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 1 July 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, jpg, gif. " The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.
A Web Unit conforms to WCAG 2.0 at a given conformance level only if all content provided by that Web unit (including any secondary resources that are rendered as part of the Web unit) conforms at that level.
Note: If multiple representations can be retrieved from a URI through content negotiation, then the conformance claim would be for the Web unit that is returned when no negotiation is conducted (unless the server returns an error for that condition, in which case one of the negotiated forms must comply) (Refer to success criterion 4.2.1 .)
Sometimes, a Web unit is assembled ("aggregated") from multiple sources that each may or may not have their own level of conformance. They may in fact not even be Web units of any kind - and thus would not, and sometimes could not, conform to all of the success criteria by themselves. These sources are called authored units ("some set of material created as a single entity by an author"). The conformance level for a Web unit that contains authored units is equal to the lowest conformance level claimed for the Web Unit content and any of the authored units it contains - including any claims pertaining to aggregated authored units. If individual authored units do not carry a conformance claim, then the claim must be based on the Web Unit with the authored units in place.
Conformance claims can be limited, or "scoped," to pertain to only some parts of a Web site. All conformance claims, however, must be directed to a URI or a range of URIs. Scoping to exclude a particular type of content (for example, images or scripts) from a site is not allowed since it would allow exclusion of individual success criteria. Scoping by URI to exclude sections of a site is allowed so that authors can make claims for just some parts of a site. Example 3 above is a scoped conformance claim.
Editorial Note: Refer to Scoping clarifications for proposed additions to this section (proposal pasted below).
[BEGIN PROPOSED]
Scoping can include and exclude parts of a site. But if any Web unit that is part of an authored unit or part of a process or does not meet WCAG 2.0 at some conformance level then no Web unit that is part of the authored unit or part of the process can claim conformance at that level.
Example 1: An online store has a series of pages that are used to select and purchase products. All pages in the sequence must conform in order to claim conformance for any page that is part of the sequence.
Example 2: A site has a collection of videos for which it was not required to and did not want to claim accessibility. The site can locate the videos in one location (e.g. example.com/movies) and then write a conformance claim for the site or section of the site that excludes that location. As long as the pages on the site only linked to the videos (and did not embed them in a Web page or other web unit) the conformance claim would be valid. Linking to inaccessible content does not make a page inaccessible. Only if that content is rendered together with the web page (or other web unit) or if the content is itself a Web unit within the set of URIs to which the conformance claim applies (or if the Web unit is part of a process for which a claim is made) would it have to meet the guidelines in order for the claim to be valid.
This scoping provision does not preclude an organization, customer, or government from requiring that all parts of a site be accessible or meet some standard including WCAG. WCAG does not require that full websites conform, although that is certainly seen as desirable. A conformance claim only requires conformance for Web Units that are in the URI set described in the claim.
[END PROPOSED]
This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999.
The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft.
Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0."
When being referenced in an informational fashion, the following format can be used.
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/, Latest version at http://www.w3.org/TR/WCAG20/)
If WCAG 2.0 is being referred to from within a should statement in a standard (or advisory statement in a regulation), then the full WCAG 2.0 should be referenced. This would mean that all three levels of WCAG 2.0 should be considered but that none are required. The format for referencing WCAG 2.0 from a should statement therefore is:
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)
When citing WCAG 2.0 as part of a requirement (e.g., a shall statement in a standard or regulation), the reference must include the specific parts of WCAG 2.0 that are intended to be required . When referencing WCAG 2.0 in this manner, the following rules apply;
Conformance at any level of WCAG 2.0 requires that all of the Level 1 success criteria be met. References to WCAG 2.0 can not be for any subset of Level 1.
Beyond Level 1, a "shall" reference may include any subset of provisions in Levels 2 and 3. That is, it is possible to require "all of Level 1 and [some specific list of SC success criteria in Level 2 and Level 3]" be met.
If Double-A conformance to WCAG 2.0 is specified, then all Level 1 and all Level 2 success criteria must be met.
If Triple-A conformance to WCAG 2.0 is specified, then all Level 1, all Level 2 and one half of the Level 3 items must be met.
To cite only the Level 1 success criteria (Single-A conformance).
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)
To cite the Levels 1& 2 success criteria (Double-A conformance).
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 & Level 2 success criteria. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)
To cite Level 1 success criteria and selected success criteria from Level 2 and Level 3 :
Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria plus Success Criteria 1.x.x, 2.y.y, … 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)
Note: It is not recommended that Triple-A conformance ever be required site wide.
Example of use of a WCAG reference in a "SHALL" statement.
All Web content on publicly available websites shall conform to Web Content Accessibility Guidelines 2.0, W3C World Wide Web Consortium Recommendation XX Month Year, Level 1 success criteria plus Success Criteria 1.3.3, 1.3.4, 1.4.1, 2.4.2-6, 3.1.6 (http://www.w3.org/TR/200X/REC-WCAG20-YYYYMMDD/)
Techniques, which are listed in Understanding WCAG 2.0 and described in other supporting documents, are not part of the normative WCAG 2.0 Recommendation and should not be cited using the citation for the WCAG 2.0 Recommendation itself. If reference is to be made to techniques in support documents, they should be cited separately as techniques listed in Understanding WCAG 2.0 or as individual technique documents.
Techniques can be cited based on the individual Technique document or on the master WCAG 2.0 Techniques document. For example, the technique “Using alt attributes on img elements” could be cited as
"Using alt attributes on img elements”, W3C World Wide Web Consortium Note. (URL: http://www.w3.org/TR/NOTE-WCAG20-TECHS/UsingAltOnImg.html/)
or
W3C World Wide Web Consortium (200x): WCAG2.0 HTML Techniques (URL: http://www.w3.org/TR/NOTE-WCAG20-TECHS/HTMLTechs.html)
Note: Techniques are not designed to be referenced as "required" from any standard or regulation.