Quick Table of Contents

Conformance

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.

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

Technology assumptions and the "baseline"

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.

Choosing baseline technologies

In choosing Web technologies (HTML, scripting, etc.) that will be used when building content, authors 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. Authors must ensure that all information and functionality of the Web content conforms to WCAG 2.0 assuming that user agents support all of the technologies in the baseline and that they are enabled. 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 technologies turned off. Both conditions are necessary since some users many have browsers that support them while others may not.

Who sets baselines?

Baselines may be set by many different entities including (but not limited to) authors, organizations, 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 (for example, state, country, etc.). Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time.

Some examples of scenarios leading to different 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 authors 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 Web sites 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: Baselines are not specified in terms of specific user agents, but in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies).

Use of technologies outside of the baseline

Authors may use technologies that are not in the specified baseline provided that the authors do not rely exclusively on those technologies for conveying any information or functionality. Also, the presence of the other technologies must not block the ability of the users to access the content via the technologies in the baseline. Specifically, the following must be true:

  1. All content and functionality are available using only the technologies in the specified baseline.

  2. The non-baseline technologies do not interfere with (break or block access to) the content

    1. when used with user agents that only support the baseline technologies

    2. when used with user agents that support both the baseline and the additional technologies.

Additional (non-normative) information on baselines can be found at About Baselines for WCAG 2.0.

Conformance levels and the baseline

  1. 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 specified baseline.

  2. 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 specified baseline.

  3. WCAG 2.0 conformance at level Triple-A (AAA) means that all Level 1, Level 2 and at least half (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 specified baseline.

If a success criterion relates to a feature, component or type of content 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

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

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/2006/REC-WCAG20-YYYYMMDD/

    Note: The correct date will replace "YYYYMMDD" when WCAG 2.0 is published as a W3C Recommendation.

  4. The conformance level satisfied: (Level A, AA or AAA)

  5. The baseline used to make the conformance claim. (The baseline technologies can be listed in the conformance claim, or, if the baseline is published elsewhere, the conformance claim can cite the baseline and provide a URI pointing to it.)

  6. Scope of the claim (a URI, list of URI's, or a set of URIs defined by a regular expression)

Optional components of a conformance claim:

  1. A list of additional success criteria that have been met beyond a standard claim

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

    • o All of the technologies that are 'relied upon' must be in the baseline.

  3. 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.

  4. A list of user agents that the content has been tested on. This should include assistive technologies.

  5. 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.

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 HTML 4.01. 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.

Conformance notes

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

Aggregated content

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. Authored units are defined as "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.

Scoping of conformance claims

Conformance claims can be limited, or "scoped," to apply to only some parts of a Web site. 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 cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria.

While scoping can include and exclude parts of a site, processes (such as shopping) and authored units must be considered 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 claim can be made at that level for any Web unit in that 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.php). 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 1: Linking to non-conforming content is not prohibited. Linking to non-conformant content is allowed, except when one of the following is true:

  • the content is rendered together with the Web page (or other Web unit), or

  • the content is itself a Web unit within the set of URIs to which the conformance claim applies, or

  • the content is a Web unit that is part of a process for which a claim is made.

Note 2: In any of these cases, the content would 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 and meet some conformance level of WCAG 2.0. WCAG 2.0 does not require that full Web sites conform, although that is certainly desirable.

Content that conforms to WCAG 1.0

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 Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0 .

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 Level AA. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0 Level AA."

How to refer to WCAG 2.0 from other documents

Information references

When referencing WCAG 2.0 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/)

When referring to WCAG 2.0 from another standard with a "should" statement

When referencing WCAG 2.0 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 referring to WCAG 2.0 from another standard with a "shall" statement

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:

  1. 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.

  2. 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 success criteria in Level 2 and Level 3]" be met.

  3. If Double-A conformance to WCAG 2.0 is specified, then all Level 1 and all Level 2 success criteria must be met.

  4. If Triple-A conformance to WCAG 2.0 is specified, then all Level 1, and all Level 2 success criteria as well as at least 50% of the Level 3 success criteria that apply to the content types used must be met.

Examples

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 and 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 for entire sites.

Example of use of a WCAG reference in a "shall" statement.

All Web content on publicly available Web sites 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/)

Referring to content from WCAG support documents

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. References to techniques in support documents should be cited separately.

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.