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.
Can reasonably be applied to all Web resources.
Level 2 success criteria:
Achieve an enhanced level of accessibility.
Can reasonably be applied to all Web resources.
Level 3 success criteria:
Achieve additional accessibility enhancements.
Can not neccessarily be applied to all Web resources.
Note 1: Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria.
Note 2: 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.
All WCAG 2.0 success criteria are testable. While some can be tested by computer programs, others must be tested by qualified human testers. Sometimes, a combination of computer programs and qualified human testers may be used. When 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 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/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, png. " 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.
Scoping can include and exclude parts of a site. However processes and authored units must be evaluated in their entirety. If part of a Web unit that is part of a process or task does not conform at some level, then no conformance (at that level) can be made for any web unit in the process. The same applies to authored units.
Example 1: An online store has a series of pages that are used to select and purchase products. All pages in the series 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 is not required to and does not want to claim accessibility. The videos are located in one location (e.g., example.com/movies). The conformance claim for the site or section of the site excludes the location that contains the videos. The conformance claim is valid as long as the Web units to which it applies only link to the videos instead of displaying them as part of the page (that is, as long as the videos are not treated as embedded content within a page for which conformance is being claimed).
Note: Linking to non-conforming content does not make a page inaccessible. Only if the inaccessible 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 the content 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.
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.