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 of conformance.
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 for users. Thus Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The 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 Working Group also believes that all success criteria are testable. Some can be tested by computer programs while others must be done 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.
Note: For each success criteria there are techniques listed that are sufficient to meet them. Each technique has a test to determine whether it 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 they relied on technologies that were 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 conform to WCAG 2.0 assuming:
WCAG 2.0 does not specify any particular baseline. This is done for several reasons. First, what is appropriate in a baseline may differ for different environments. For example, for content that will be viewed only by company employees, a company may be able to assume a higher level of user agent technology if they provide that technology to all their 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. And the level of technology that can be assumed to be supported by accessile 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 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 in the user agent which the organization provides for its employees. Because the company controls the user agents that will view its internal content - the author has very accurate knowledge of the technologies that those user agents (including assistive technologies) support.
(Note that in example 3, the author is not specifying the baseline in terms of a user agent but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies)
Baselines may be set by authors, companies, customers and governmental bodies.
Developers may also use technologies that are not in the specified baseline provided that the following are true:
All content and functionality is available using only the technologies in the specified baseline.
The non-baseline technologies must 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 information on baselines can be found at Questions and Answers about Baseline and WCAG 2.0.
Three levels of conformance can be claimed in 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 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 means that all Level 1, all 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 you are not using (e.g. you don't have any multimedia on your site) then you automatically meet that success criterion since you don't have any multimedia on your site that does not meet the success criterion.
Conformance claims apply to Web-Pages* and sets of Web-Pages. (Web-Pages* often take the form of a traditional Web page but can also take the form of a fully interactive and emmersive environment.)
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/2005/REC-WCAG20-YYYYMMDD/
The conformance level satisfied: (Level A, Double-A or Triple A)
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)
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. The target audience information CANNOT specify anything related to disability or to physical, sensory or cognitive requirements.
Example 1: On 13 March 2005, 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), Opera 7.5 (OSX).
Example 2: On 1 August 2006, "G7: An Introduction" http://Telcor.example.com/nav/G7/into.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), png, jpg, and Real Video. The specifications that this content *uses but does not rely on* are: JavaScript 1.2, CSS2.
Example 3: On 1 July 2005, 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-2005 at http://ISA.example.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 but does not rely on* is: gif. The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html
A Web-Page* conforms to WCAG 2.0 at a given conformance level only if all content provided by that Web-Page (including any secondary resources that are rendered as part of the Web-page) 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-Page 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) (see Success Criterion 4.2.1.
Sometimes a Web-Page* 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-Pages* or primary resources of any kind - and thus would not, and sometime 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-Page that contains authored units is equal to the lowest conformance level claimed for the Web-Page content and any of the authored units it contains - including any claims of aggregated authored units. If authored units do not have an accessibility claim then the claim must be based on the Web-Page 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.
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 created or modified before 31 December 2005 conform to WCAG 1.0. Materials created or modified on or after 31 December 2005 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 non 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;
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& 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.