WCAG 2.0 Double-A Conformance

Please note that this is only my personal interpretation of WCAG. Secondly, please note that this interpretation has been written specifically with HTML and XHTML in mind, and there are more to the checkpoints than this. Finally, be aware that this article is based on the working draft of 23rd November 2005. As further drafts and/or final recommendations are produced, this article may require amendment. Please check the latest version.

Article sections

1. Technology Baseline
2. Design Principles  
3. Success Criteria  
4. Conformance Claims  
5. Single-A Conformance Criteria  
6. Double-A Conformance Criteria
7. Triple-A Conformance Criteria  

Return to Contents

Level AA Conformance Criteria

To conform to WCAG 2.0 level AA accessibility you need to meet all of the Single-A Conformance Criteria, plus the following success criteria:

Success Criterion	Description
1.2.3	Provide captions for real-time multimedia.
1.3.3	Information conveyed by text presentation should be appropriately marked up (use "strong", "em", headings, quote and blockquote) rather than just changing the font presentation.
1.3.4	Information conveyed by colour is evident even when colour is not available (strengthening of 1.3.2).
1.4.1	Text or diagrams and their background must have a luminosity contrast of at least 5:1. You may wish to use the Juicy Studio Luminosity Contrast Analyser.
1.4.2	There must be a mechanism to switch off any background audio that plays automatically.
2.2.2	Content does not blink for more than 3 seconds or a mechanism is provided to stop blinking.
2.2.3	Content can be paused by the user unless timing or movement is part of an activity where timing or movement is essential (strengthening of 2.2.1)
2.3.2	Content does not violate the general flash threshold or the red flash threshold irrespective of the technology baseline (strengthening of 2.3.1).
2.4.2	There should be more than one way to locate information in a site (e.g. site map, table of contents, navigation bars, links within the text) — except for pages which are part of multi-stage tasks — e.g. page 3 of an online application is reasonably only accessible after submitting page 2.
2.4.3	Where blocks of content appear multiple times across different pages (navigation, header, lists of friends sites) they are able to be bypassed (e.g. by skip links — it is preferable that these are visible).
2.4.4	Web pages and frames should have appropriate titles, not just the filename.
2.4.5	Each reference to another document should describe the document with meaningful link text (e.g. use "terms and conditions" for the link rather than using the "click here" part of "for terms and conditions click here"). Title attributes should be used to provide additional information where appropriate.
2.5.2	If an input error is detected and suggestions for correction can be made without security implications or changing the purpose of the content (e.g. don't suggest someone's password; in a spelling game, don't suggest the correct spelling), then suggestions should be provided to the user.
2.5.3	For any financial or legal transaction, allow the user to confirm information before proceeding, allow the user to check details at every stage of the process, or allow the transaction to be reversible.
3.1.2	Changes in the language use of the content (e.g. any foreign passage or phrase) should be marked up with the appropriate language identifier.
3.2.2	Changing the setting of any input field does not cause the page to change or the information on the page to change (e.g. do not use dropdown menus that change the page automatically when a selection is chosen).
3.2.3	Blocks of content that are repeated across the site (e.g. header, navigation, contents block, footer) should always occur in the same relative order.
3.2.4	Repeated content that has the same function across the site is used consistently (e.g. do not call a search function "search" in one place and "find" in another, and do not make them work in different ways).