Explanations for the Accessibility Checklist 2.0

Explanation of the success criteria and technical examples for the Accessibility Checklist 2.0 of the "Web Content Accessibility Guidelines (WCAG 2.0)"

 

 

        Content

1.          Principle: Perceivable................................................................................................................................. 3

1.1.       Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, Braille, speech, symbols or simpler language.................................................................... 3

1.2.       Time-based Media: Provide alternatives for time-based media............................................................... 4

1.3.       Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure...................................................................................................................................................... 7

1.4.       Distinguishable: Make it easier for users to see and hear content including separating foreground from background................................................................................................................................................................... 13

2.          Principle: Operable................................................................................................................................... 19

2.1.       Keyboard Accessible: Make all functionality available from a keyboard................................................. 19

2.2.       Enough Time: Provide users enough time to read and use content........................................................ 20

2.3.       Seizures: Do not design content in a way that is known to cause seizures............................................ 22

2.4.       Navigable: Provide ways to help users navigate, find content, and determine where they are............ 23

3.          Understandable........................................................................................................................................ 29

3.1.       Readable: Make text content readable and understandable................................................................... 29

3.2.       Predictable: Make Web pages appear and operate in predictable ways................................................ 32

3.3.       Input Assistance: Help users avoid and correct mistakes........................................................................ 34

4.          Robust....................................................................................................................................................... 38

4.1.       Compatible: Maximize compatibility with current and future user agents, including assistive technologies................................................................................................................................................................... 38

 

 

Reference:                             http://www.access-for-all.ch/checklist

                                                  http://www.ch.ch/accessibility

Version:                                   2.10                                                      

 


I.        Reference: The Web Content Accessibility Guidelines (WCAG 2.0)

The explanations for Checklist 2.0 are based on the internationally recognized "Web Content Accessibility Guidelines (WCAG 2.0)" Original: http://www.w3.org/TR/WCAG20/

Validity

This document contains the original texts of the official translation of the WCAG 2.0 documents, "Principles", "Guidelines" and "Success criteria". For each success criterion, a simplified, in-house text is presented – "Understanding" and "Example". This text can be used for websites with the current, most widely used design technologies, and it assists with effective use of the guidelines.

This document is not a replacement for the guidelines of the "Web Accessibility Initiative" (WAI).  In case of doubt, the original WAI text always applies.

WCAG 2.0 Conformance Requirements

To achieve conformance with one of the levels — A (lowest), AA (recommended) or AAA (highest) — the entire website must meet all the success criteria of the relevant level(s) or provide an alternative version with level conformance.

Conformance Requirements: http://www.w3.org/TR/WCAG20/#conformance-reqs

Technical terms in the glossary

Important framework texts from the guidelines are not listed in this document for lack of space. Many terms are explained in the glossary, which is distributed with this document.

Glossary for the Accessibility Checklist 2: http://www.access-for-all.ch/checklist

WAI glossary: http://www.w3.org/TR/WCAG20/#glossary

Application

The Accessibility Checklist 2.0 can be used to assess the accessibility of web content. The structure of the original WCAG 2.0 guidelines has been maintained, and the original texts have been cited verbatim to guarantee the greatest possible consistency.

Some requirements are divided into several success criteria (SC). This makes it possible for several aspects to be examined in detail. Cross-references are indicated with a parenthetical comment, e.g., (see also SC 1.2.1).

Tools for testing are also specified for each success criterion; further solutions are documented under “Meeting the requirement”.

Further information is in the appendix to this document.

Information and user interface components must be presentable to users in ways they can perceive.

1.1.        Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, Braille, speech, symbols or simpler language.

1.1.1.          Non-text-Content (Level A)

Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

1.       Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)

2.       Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)

3.       Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.

4.       Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.

5.       CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

6.       Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Understanding:

In order for information graphics to be considered accessible for blind and visually impaired users (and search engines), they must be described with a meaningful alternative text.

If the graphic is a photo or a symbol (e.g., print, PDF icons), the content displayed must be described analogously in the text.

In the case of complex information graphics, such as diagrams or organizational charts, the description in the alternative text is often not sufficient. An additional description should be included, either directly in the neighboring text or using the longdesc attribute.

Code example:

<p><img src=“theimage.gif“ alt=“The organizational chart of administrative. Explanation in long description.“ longdesc=“organizational chart-administrative.html“ /></p>

 

<p><img src=“theimage.gif“ alt=“The organizational chart of administrative. Explanation in the following paragraph“ /></p>

Example CAPTCHA:

 

Figure 1: Two examples of accessible CAPTCHAS. On the left the security word can also be played as an audio file, on the right a simple calculation has to be carried out.

WCAG 2.0, 1.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-text-equiv-all

Tools for testing:                      Web developer toolbar or AIS toolbar, source text analysis

1.2.        Time-based Media: Provide alternatives for time-based media.

1.2.1.          Audio-only and Video-only (Prerecorded) (Level A)

For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such:

-       Prerecorded Audio-only: An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.

-       Prerecorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.

Understanding:

For the content of prerecorded audio-only and prerecorded video-only media to be considered accessible for blind and deaf people, an alternative must be made available.

Example:

The visual content of a video is described in an audio file made available as a podcast. Conversely, the contents of a podcast are described visually with cartoons. This fulfils the “two senses principle”.

Media alternative: A text transcription (text version) of the spoken words with notes on visible or audible content that is contextually relevant is made available as a linked document (RTF or HTML format).

WCAG 2.0, 1.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-av-only-alt

Tools for testing:                      Visual inspection


1.2.2.          Captions (Prerecorded) (Level A)

Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Understanding:

Captions are provided to make the content of spoken language in videos accessible for deaf people.

WCAG 2.0, 1.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captions

Tools for testing:                      Visual inspection

1.2.3.          Audio Description or Media Alternative (Prerecorded) (Level A)

An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

Understanding:

For the content of prerecorded media, e.g., an audio podcast or a video with sound, to be considered accessible for blind and deaf people, an alternative format must be available. Visible or audible non-verbal content should also be described if it is contextually relevant.

Example:

An “audio description” link beneath each video provides access to an audio file that consists of the original sound and additional spoken notes that describe the visible content. Media alternative: A text transcription (text version) of the spoken words with descriptions of the contextually relevant visible or audible content is made available as a linked document (RTF or HTML format).

WCAG 2.0, 1.2.3, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc

Tools for testing:                      Visual inspection

1.2.4.          Captions (Live) (Level AA)

Captions are provided for all live audio content in synchronized media.

Understanding:

To make the information in live audio content accessible for deaf people, captions must be available.

Example:

The live news is broadcast with additional live captions.

WCAG 2.0, 1.2.4, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-real-time-captions

Tools for testing:                      Visual inspection

1.2.5.          Audio Description (Prerecorded) (Level AA)

Audio description is provided for all prerecorded video content in synchronized media.

Understanding:

For the content from all recorded video content to be considered accessible for blind people, an audio description must be available. Visible non-verbal content that is contextually relevant should also be described.

Example:

An “audio description” link beneath each video provides access to an audio file that consists of the original sound and additional spoken notes that describe the visible content.

WCAG 2.0, 1.2.5, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc-only

Tools for testing:                      Visual inspection

1.2.6.          Sign Language (Prerecorded) (Level AAA)

Understanding:

For Internet sites aimed at the general public, sign language videos are recommended. Sign language videos should be offered as an alternative to website content or as a moderated summary.

Sign language is the native language of many deaf people, written language is their second language. Processing information in written language is therefore laborious for deaf people and highly limited for many. Only sign language can communicate the entire content to deaf people, and it is the only way to guarantee the same level of knowledge and information. For deaf people, unrestricted use of their first language, sign language, is an important contribution to equal access to information sources.

Example:

Example of sign language videos: www.access-for-all.ch

WCAG 2.0, 1.2.6, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-sign

Tools for testing:                      Visual inspection

1.2.7.          Extended Audio Description (Prerecorded) (Level AAA)

Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.

Understanding:

To make the content of prerecorded videos accessible for blind people, visible non-verbal content that is contextually relevant should also be described.

The A and AA criteria are thus expanded if, for example, the pauses between scenes are not long enough for the visible content to be described by the speaker.

Example:

An "expanded audio description" link beneath each video provides access to an audio file that interrupts the original soundtrack as necessary in order to describe the visible content.

WCAG 2.0, 1.2.5, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-extended-ad

Tools for testing:                      Visual inspection

1.2.8.          Media Alternative (Prerecorded) (Level AAA)

An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media

Understanding:

There is an alternative for all prerecorded video media. This can either be a transcription or a description of the content and spoken material and can be accessible by link.

In this way, the A and AA criteria are expanded and the previously formulated requirements are extended to all recorded videos, including those with content that is already present on the web page in another form.

Example:

A text transcription (text version) of the spoken words with notes on the visible content that is relevant to the meaning is provided as a linked document (RTF or HTML format).

WCAG 2.0, 1.2.8, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-text-doc

Tools for testing:                      Visual inspection

1.2.9.          Audio-only (Live) (Level AAA)

An alternative for time-based media that presents equivalent information for live audio-only content is provided

Understanding:

An alternative must be provided for all live audio media, so deaf people can also understand the content.

Example:

A live news broadcast is also transmitted as text.

WCAG 2.0, 1.2.9, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-live-audio-only

Tools for testing:                      Visual inspection

1.3.        Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.1.          Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Understand 1.3.1 A. Heading structure:

Headings (h1, h2, h3 etc.) must introduce each block of content and communicate the arrangement and meaning of the blocks of content on the website. A website does not have to begin with a heading 1 (h1). It is considered to be good style, particularly by blind users of screen readers, if headings are structured with a correct hierarchy (h1, followed by h2, h3 etc.) and no levels are skipped.

Example 1.3.1 A. Heading structure:

 

Figure 2: Schematic view with grey areas of blocks of information on a typical website (left). The underlying markup is shown in the right column. Blocks of information can be structured with preceding headings (h1, h2 ... h6) and lists (ul).

Invisible headings:

Headings can also be made invisible by displacing them from the view port using CSS. This class can generally be used as follows for invisible notes for screen reader users:

.hidden {

display: inline;

left: -1000px;

overflow: hidden;

width: 0px;

position: absolute;

top: -1000px;

height: 0px
}

Understanding 1.3.1 B. Lists:

Lists are important elements of semantic grouping and structuring. They help screen reader users in particular to detect when information is listed or which links belong together and where a new link grouping starts.

Unformatted lists are unclear for screen reader users, and their length cannot be anticipated. A formatted list, on the other hand, is announced by the screen reader as follows: "List with 12 entries ..."

-       Content such as product lists should not only be shown as a list, but also formatted as a list.

-       Navigational elements should always be formatted as a list – even horizontal navigation.

-       Group links into logical units. For example, several main category groups should each be in a list (ul or ol) and subcategories should be in a nested list.

-       For glossaries, link lists with comments and similar items, definition lists (dl) can be used, see code example.

-       Nest lists correctly, see code example.

Code example:

<ul id="menu"><!--mind the correct nesting -->

   <li><a href="#">Upper point 01</a>

        <ul class="submenu" id="active">

           <li><a href="#">Submenu 1.a</a></li>

           <li><a href="#">Submenu 1.b</a></li>

           <li><a href="#">Submenu 1.c</a></li>

        </ul>

   </li>         

<li> ... </li>

</ul>

 

<dl><!—Definition list -->

  <dt><a href="website.htm">Website</a></dt>

  <dd>Description or commentary of the DT element contained links</dd>

  <dd>Also possible with more definition data cells</dd>

</dl>

 

Understanding 1.3.1 C. Form relationships:

In order to link labels logically with form fields, the element label should be used. The fieldset element is suitable for creating sections in large forms and for grouping checkboxes and radio buttons.

Best practice for forms: http://www.usability.com.au/resources/wcag2/
Notes on forms:

In order to link labels logically with form fields, the label element should be used.

Code example:

<form action="form.html">

    <fieldset>

         <legend>

               personal information

         </legend>

         <label for="vn">

               first name:

         </label>

         <input type="text" id="vn" title="Enter first name" name="first name" value="">

         <br />

         <label for="nn">

               last name:

         </label>

         <input type="text" id="nn" title="Enter last name" name="last name" value="">

         <br />

         Please tick:

         <input type="checkbox" id="selection" name="agb" value="">

         <label for="selection">

               I have read the Terms and Conditions.</label>

         <br />

    </fieldset>

</form>

Comment:

The speech output reads out what has been defined in the label. The legend element is required to label the form sections (fieldset). Order sections logically and use short, clear labels.

This is how the screen reader reads the code example above:

„form

personal information: field first name,
personal information: field last name,
personal information: selection field I have read the Terms and Conditions
end form“

Checkboxes and radio buttons

So that blind users can process checkboxes and radio buttons correctly, these must be linked with a fieldset to the relevant label.

Code example:

<fieldset>

<legend>title</legend>

<div>

<input type="radio" name="title" id="title_woman" value="1" />

<label for="title_woman">woman</label>

</div>

<div>

<input type="radio" name="title" id="title_man" value="0" />

<label for="title_man">man</label>

</div>

</fieldset>

Comment:

An id attribute is always unique throughout the entire document, so it can only be used once. Thus, while the name attributes of the radio elements are the same, the id attributes are different.

Understanding 1.3.1 D. Data tables

For simple data tables with just one column heading, the first row can be used as a header, and th is used instead of tr. The scope attributes can be left out, see code example 1.

For two-dimensional data tables it is appropriate to use scope attributes, see code example 2. For multi-dimensional data tables, or summarized column headings, a correlation can be made using the id attribute, see method H43.

Tables require a heading, which can be a preceding heading (h2, ..., h6) or the caption element provided. The caption can also be hidden for visual users, see code example 1.

Complex tables also require a summary. As the screen reader always reads this summary, you should ensure that it is brief and meaningful. See code example 2.

Never use empty cells in tables to create spaces. If a cell is empty, it is best to use a symbol such as: - or 0 (zero).

Code example 1 for a simple data table with column headings comprised only of headers (th):

Three cities compared

Chur

Bern

Basel

1287

2355

2233

 

<table>

    <caption>Three cities compared</caption>

    <tr>

         <th>Chur</th>

         <th>Bern</th>

         <th>Basel</th>

    </tr>

    <tr>

         <td>1287</td>

         <td>2355</td>

         <td>2233</td>

    </tr>

</table>


Code example 2 of a data table with column and row headers with scope:

Post offices in Switzerland

post offices

2005

2006

2007

main branches

2389

2357

2312

branches

657

654

649

agencies

135

129

150

 

<table summary="The number of main branches, subsidiaries and agencies are compared in the years 2005, 2006 and 2007">

    <caption>post offices in Switzerland</caption>

    <tr>

                   <th scope="col">post offices</th>

                   <th scope="col">2005</th>

                   <th scope="col">2006</th>

                   <th scope="col">2007</th>

              </tr>

              <tr>

         <th scope="row">main branches</th>

         <td>2'389</td>

         <td>2'357</td>

         <td>2'312</td>

    </tr>

    <tr>

         <th scope="row">branches</th>

                   <td>657</td>

                   <td>654</td>

                   <td>649</td>

    </tr>

    <tr>

         <th scope="row">agencies</th>

         <td>135</td>

         <td>129</td>

         <td>150</td>

    </tr>
</table>

Understanding 1.3.1 E. Use of characters

Separation of structure (content and HTML) and style (CSS) must be guaranteed. Text is formatted with semantically correct markup, e.g., citations with cite and long quotations with blockquote; q, em and strong, sup, and sub may also be used.

If font variations have a meaning in regards to content, this must be clear to all users (e.g., italics cannot be detected by a screen reader).

Do not use spaces or pre for making layouts.

Elements such as the del element should be avoided, as screen readers cannot correctly evaluate them. Differences among versions (e.g., if several people have worked on one text) must therefore be made clear in the text.

WCAG 2.0, 1.3.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#content-structure-separation 

Tools for testing:                      Web developer toolbar, web accessibility toolbar, source code test, and visual inspection

1.3.2.          Meaningful Sequence (Level A)

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

Understanding:

All content is arranged in a meaningful order, so that the meaning is also clear if a screen reader interprets and re-presents the content without CSS and in linear order, for example.

Example 1.3.2 Order

Figure 3: The order of the content is not just visually meaningful (figure, left), but is also clear when CSS is turned off (figure, right).

WCAG 2.0, 1.2.8, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-sequence

Tools for testing:                      Visual inspection, turning off CSS,

1.3.3.          Sensory Characteristics (Level A)

Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

Note: For requirements related to color, refer to Guideline 1.4.

Understanding:

Information and instructions must be communicated in a way that can be understood regardless of sensory limitations.

Example:

Not:
"For further information see the box with a grey background at the top right."
but:
For further information see the box
"Use a meaningful heading".

WCAG 2.0, 1.3.3, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understanding 

Tools for testing:                      Visual inspection, Greasemonkey script

1.4.        Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

1.4.1.          Use of Color (Level A)

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

Understanding:

Information and instructions must be communicated in a way that can be understood regardless of ability to recognize colors.

Example:

Active menu items are not just highlighted by color, but are also bold, for example. Headings are not just color highlighted, but are also larger and bolder.

Figure 4: The figure on the left shows which courses still have space available. The information is communicated using only the colors green, red and yellow. A colorblind person or a blind person cannot perceive this information. Just one additional character (figure, right) is sufficient to communicate the distinction without using color.

WCAG 2.0, 1.4.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color 

Tools for testing:                      Visual inspection, turning off CSS, using user-defined color settings

1.4.2.          Audio Control (Level A)

If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Understand:

Automatically played audio interferes severely with screen readers, for example, and it must therefore be possible to stop it or turn the volume down.

Example:

Control buttons (play, stop etc.) must be available.

WCAG 2.0, 1.4.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audio 

Tools for testing:                      Visual inspection

1.4.3.          Contrast (Minimum) (Level AA)

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

-       Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3: 1;

-       Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

-       Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Understanding:

Sufficient color contrast is very important and makes text generally easier to read because it stands out from the background more. Many people are visually impaired and many use additional individual settings, e.g., color inversion. For these settings to have the desired effect, sufficient contrast is necessary. You should also observe links in their various states: “hover” (mouse over), “focus”, and “visited”.

Necessary minimum contrast:

Font: Contrast ratio of at least 4.5:1
Large font (at least 18 pt or at least 14 pt for bold text): Contrast ratio of at least 3:1
(also applies for text in information graphics, but not necessarily for logos and lettering)

Note on font size:

The WAI expresses font size in terms of points (pt). Points are a physical unit of measure and may be interpreted for the screen as follows: For a screen (resolution 1200 x 900 pixels) the font size 18 pt means a height of at least 5.3 mm for a capital W or 14 pt bold means a minimum height of 4 mm for a bold capital W.

Example 1.4.3 Color contrast

Figure 5: Using the tool, "Color Contrast Analyser", the contrast of the colors used can be measured during the design process. The “luminosity” algorithm measures color contrast as required for WCAG 2.0 conformance.

WCAG 2.0, 1.4.3, AA               

“Meeting the requirement”:    http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrast

Tools for testing:                      Visual inspection, contrast measurement with Color Contrast Analyser (freeware Win, Mac):

                                                  http://www.visionaustralia.org.au/info.aspx?page=628

1.4.4.          Resize text (Level AA)

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Understanding:

Many visually impaired people depend on the enlargement functions of the browser. For them to be able to use this, it must be possible to adjust the layout and the font size.

Requirements:

These requirements are met when:

-       Text size (font size) is defined in the CSS in % or em.

-       No layout overlaps occur during enlargement. No text disappears, and it is readable at all times.

-       The zoom function (if present) enlarges the content of the entire window up to 200%

 Test steps:

o    Internet Explorer 7, 8 zoom function: 200%.

o    Firefox: Zoom function: 200%; press "ctrl" + "+" 6 times ( with “Zoom Text Only” switched off)

-       Text enlargement of up to 200% is possible (without breaking the layout)

 Test steps:

o    In Internet Explorer 7, 8: "Text size large"

o    In Firefox: Text enlargement: Press "ctrl" + "+" 2 times (with “Zoom Text Only” switched on)

Example:

Figure 6: The web page on the left is shown at original size and on the right with 200% text enlargement in Firefox. All text must still be readable.

WCAG 2.0, 1.4.4, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-scale 

Tools for testing:                      Internet Explorer, Firefox, and visual inspection

1.4.5.          Images of Text (Level AA)

If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

-       Customizable: The image of text can be visually customized to the user's requirements;

-       Essential: A particular presentation of text is essential to the information being conveyed.

Note: Logotypes (text that is part of a logo or brand name) are considered essential.

Understanding:

Text should be used instead of text graphics for content. Text display can be controlled with graphic CSS technologies.

WCAG 2.0, 1.4,5, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation 

Tools for testing:                      Internet Explorer, Firefox, setting of user-defined colors, visual inspection

1.4.6.          Contrast (Enhanced) (Level AAA)

The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:

-       Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;

-       Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

-       Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Understand:

Sufficient color contrast is very important and makes text generally easier to read, because it stands out from the background more. This success criterion expands on SC 1.4.3 with higher minimum values.

You should also observe links in their various states: “hover” (mouse over), “focus”, and “visited”. Necessary minimum contrast:

Font: Contrast ratio of at least 7:1
Large font (from 18 pt or 14 pt + bold): Contrast ratio of at least 4.5:1
(also applies for text in information graphics, but not necessarily for logos and logotypes)

Note on font size:

The WAI expresses font size in terms of points (pt). Points are a physical unit of measure and may be interpreted for the screen as follows: For a screen (resolution 1200 x 900 pixels) the font size 18 pt means a height of at least 5.3 mm for a capital W or 14 pt bold means a minimum height of 4 mm for a bold capital W.

WCAG 2.0, 1.4.6, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast7 

Tools for testing:                      Colour Contrast Analyser

1.4.7.          Low or No Background Audio (Level AAA)

For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true:

-       No Background: The audio does not contain background sounds.

-       Turn Off: The background sounds can be turned off.

-       20 dB: The background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sounds that last for only one or two seconds.

Note: Per the definition of «decibel», background sound that meets this requirement will be approximately four times quieter than the foreground speech content.

Understanding:

So that users who rely on speech can understand spoken content, it should have very little background noise or none at all.

WCAG 2.0, 1.4.6, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-noaudio 

Tools for testing:                      Visual inspection

1.4.8.          Visual Presentation (Level AAA)

For the visual presentation of blocks of text, a mechanism is available to achieve the following:

-      Foreground and background colors can be selected by the user.

-       Width is no more than 80 characters or glyphs (40 if CJK).

-       Text is not justified (aligned to both the left and the right margins).

-       Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

-       Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Understanding:

The readability of content can be improved enormously by observing the typographical criteria listed.

WCAG 2.0, 1.4.8, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-visual-presentation 

Tools for testing:                      Visual inspection

1.4.9.          Images of Text (No Exception) (Level AAA)

Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed.

Note: Logotypes (text that is part of a logo or brand name) are considered essential.

Understanding:

Text should be used instead of text graphics for relevant content.

WCAG 2.0, 1.4.9, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-images 

Tools for testing:                      Visual inspection

User interface components and navigation must be operable.

2.1.        Keyboard Accessible: Make all functionality available from a keyboard.

2.1.1.           Keyboard (Level A)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Understanding:

Many users use their PC with the keyboard and not the mouse. Special input devices also use the keyboard as an interface.

If the user is advised in advance in text form, keystrokes other than the conventional ones (tab, arrow keys) can be used to carry out a function.

WCAG 2.0, 2.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-keyboard-operable 

Tools for testing:                      Visual inspection

2.1.2.          No Keyboard Trap (Level A)

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Understanding:

Many users operate their PC using the keyboard. Elements such as videos or in-house programming can "capture" the keyboard focus, making further operation impossible – these cases must be avoided in all current browsers.

If the user is advised in advance in text form, keystrokes other than the conventional ones (tab, arrow keys) can be used to carry out a function.

Example:

Tip: "Close lightbox by pressing ESC".


 

WCAG 2.0, 2.1.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-trapping 

Tools for testing:                      Visual inspection

2.1.3.          Keyboard (No Exception) (Level AAA)

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

Understanding:

Many users operate their PC using the keyboard. It should always be possible to use the keyboard without exception.

WCAG 2.0, 2.1.3, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-keyboard-operation-all-funcs 

Tools for testing:                      Visual inspection

2.2.        Enough Time: Provide users enough time to read and use content.

2.2.1.          Timing Adjustable (Level A)

For each time limit that is set by the content, at least one of the following is true:

-       Turn off: The user is allowed to turn off the time limit before encountering it; or

-       Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

-       Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

-       Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

-       Essential Exception: The time limit is essential and extending it would invalidate the activity; or

-       20 Hour Exception: The time limit is longer than 20 hours.

Note: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

Understanding:

Many users operate their PC very slowly. If timing or a time limit is necessary, it must therefore be possible to adjust it.

Example:

The user can configure the session time within an ordering process.

WCAG 2.0, 2.2.1, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-required-behaviors 

Tools for testing:                      Visual inspection

2.2.2.          Pause, Stop, Hide: (Level A)

For moving, blinking, scrolling, or auto-updating information, all of the following are true:

-       Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and

-       Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Note 1: For requirements related to flickering or flashing content, refer to Guideline 2.3.

Note 2: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Note 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.

Note 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.

Understanding:

Users with special cognitive needs or users working with assistive devices such as screen readers might be prevented from using the page by animated or automatically updated content.

Example:

An automatic news ticker or a slide show has a stop button.

WCAG 2.0, 2.2.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause 

Tools for testing:                      Visual inspection

2.2.3.          No Timing (Level AAA)

Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events.

Understanding:

Many users operate their PC very slowly. Timing or time limits should therefore be avoided.

Example:

The session in an ordering process does not have a time limit.

WCAG 2.0, 2.2.3, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-no-exceptions

Tools for testing:                      Visual inspection

2.2.4.          Interruptions (Level AAA)

Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency.

Understanding:

Advertising or news advisories pose an obstacle for many users if they interrupt the flow of content. Warning messages in case of incorrect user input are a special case and are permitted.

Example:

Users are able to close pop-up windows that advertise a product before the relevant content is displayed.

WCAG 2.0, 2.2.4, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-postponed

Tools for testing:                      Visual inspection

2.2.5.          Re-authenticating (Level AAA)

When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating.

Understanding:

No explanation necessary.

WCAG 2.0, 2.2.5, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-server-timeout 

Tools for testing:                      Visual inspection

2.3.        Seizures: Do not design content in a way that is known to cause seizures.

2.3.1.          Three Flashes or Below Threshold (Level A)

Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Understanding:

Various types of flashing can lead to seizures in people who are prone to light induced seizures. The brightness of the display means this is particularly true for screen media.

WCAG 2.0, 2.3.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violate 

Tools for testing:                      Visual inspection

2.3.2.          Three Flashes (Level AAA)

Web pages do not contain anything that flashes more than three times in any one second period.

Understanding:

Various types flashing can lead to seizures in people who are prone to light induced seizures. The brightness of the display means this is particularly true for screen media.

WCAG 2.0, 2.3.2, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-three-times

Tools for testing:                      Visual inspection

2.4.        Navigable: Provide ways to help users navigate, find content, and determine where they are.

2.4.1.          Bypass Blocks (Level A)

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

Understanding:

Various user groups rely on cues to help navigate websites with large amounts of content. A blind person, for example, can use a "to the content" skip link to go directly to the text without having to listen to all the details about navigation again on every page.

Requirements:

-       At least 1 "directly to the content" skip link

-       Grouping repeated blocks of information or labeling these with headings

-       Access keys are optional

Recommendation:

The "Access for All" foundation recommends skip links and access keys be defined as follows:

0 "Homepage"

1 "Navigation" (skip link within web page)

2 "Content" (skip link within web page)

3 "Contact"

4 "Sitemap"

5 "Search" (skip link within web page)

6-9 optional (only if necessary and useful)

The skip link and access key labels should be short, e.g., "Content", "Search", etc. Because the screen reader announces: "Link content". This information should be unambiguous. Allocating the number keys ensures that there is no conflict with keyboard shortcuts used by operating systems and software.

Skip links and access keys should ideally be combined. In the example below, the skip links are listed right at the start of the page and displaced from the view port for sighted people using the CSS class "skiplinks".

Code example HTML:

<body>

<ul class="skiplinks">

 <li><a href="#mainmenu"  accesskey="1" title="[ALT + 1]">main navigation</a></li>

 <li><a href="#content" accesskey="2" title="[ALT + 2]">to content</a></li>

 <li><a href="#additional" accesskey="6" title="[ALT + 6]">additional information</a></li>

</ul>

Code example CSS:

.skiplinks {

display: inline;

left: -1000px;

overflow: hidden;

width: 0px;

position: absolute;

top: -1000px;

height: 0px
}

 

WCAG 2.0, 2.4.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip 

Tools for testing:                      Visual inspection

2.4.2.          Page Titled (Level A)

Web pages have titles that describe topic or purpose.

Understanding:

The page title is the most important feature for helping orient various users. For this reason the title should describe the topic of the current page.

Example:

News - Access for all - Accessible technology use

Code example HTML:

<head>

  <title>News – Access for all – Accessible technology use

  </title>

  <meta ...

</head>

 

WCAG 2.0, 2.4.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-title 

Tools for testing:                      Visual inspection

2.4.3.          Focus Order (Level A)

If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Understand:

Many users use the keyboard (tab key) for operation. They go through the website sequentially and they rely on the logical sequence of links.

Example:

The sequence of tabs must be logical, particularly for processing forms.

WCAG 2.0, 2.4.3, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-order

Tools for testing:                      Visual inspection

2.4.4.          Link Purpose (In Context) (Level A)

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

Understanding:

Many users rely on the link target being specified as clearly as possible: see the examples listed.

A new window opening is problematic (target="_blank"). It is no longer necessary to specify "New window" for screen readers, as current screen readers detect this and announce it. Sighted users are informed in the title attribute of the link tag (title="in new window").

Example:

A link in the text makes it clear which content is available at the link target.A page contains the sentence A lot of blood was spilt in the historical period of the Middle Ages. The point in the text, "historical period of the Middle Ages", is the link.

A text explanation precedes a link
A page contains the sentence,
Find out more about Ireland's Commission for E-Voting at Go Vote!”. The point in the text, Go Vote!, is the link.

An icon and text are integrated into the link
An icon with a voting button and the text,
Ireland's Commission for E-Voting are integrated into the same link. The alt text of the icon is empty (alt="") because the link target is already listed in the text next to the icon.

A list with book titles
A number of books are available in three formats: HTML, PDF and mp3 (audio book). To avoid the title being repeated three times (once for each format), the title of each book is cited for the first link (HTML), the second link is
PDF and the third link is mp3.

News article overview
A website contains a number of news articles. The homepage lists the first few sentences of each article followed by a
continue reading link. As the links are integrated in the same paragraphs, screen readers can find the context using a function and interpret the link target. See code example 1.

Code example 1:

<p><img src="teas003.jpg" alt="View of the festival, Lake Zurich in the background"> This year’s Spring Festival was very well attended. <span class"wt03"><a href="123.html">Read more . . .</a></span></p>

More examples:

-       Summary (PDF, 34 KB)

-       Order form (in a new window)

Important note:

Clear link descriptions that are unambiguous on their own are very useful for many users. Success criterion 2.4.9, link target (pure link) (Level AAA) is therefore recommended.

WCAG 2.0, 2.4.4, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs

Tools for testing:                      Web accessibility toolbar

2.4.5.          Multiple Ways (Level AA)

More than one way is available to locate a Web page within a set of Web pages except where the Web page is the result of, or a step in, a process.

Understanding:

There is at least one method in addition to navigation within the website for accessing content.

Example:

A search function or a sitemap (contents) or both.

WCAG 2.0, 2.4.3, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-loc

Tools for testing:                      Visual inspection

2.4.6.          Headings and Labels (Level AA)

Headings and labels describe topic or purpose.

Understanding:

Headings are important for the readability of content and should be used before sections of longer text and to label different zones of a website. Headings help users to distinguish among and navigate to different zones. Active zones in image maps and links that trigger programmed functions must also be labeled.

Example:

The labels are short and meaningful.

WCAG 2.0, 2.4.6, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive 

Tools for testing:                      Visual inspection

2.4.7.          Focus Visible (Level AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Understanding:

In case of operation using the keyboard, the tab key jumps from link to link. When the user jumps to a link, giving it the focus, this must be visible for keyboard users who are working visually. The focused link must be clearly visually distinct from the other links. Skip links must also become visible when they are in focus.

Example:

a:focus, a:hover, a:active {
text-decoration:underline;

}

Example 2.4.7 Focus visible

Figure 7: In case of operation using the keyboard (tabs with tab key), all links are clearly emphasized and the skip links also appear in the clearly visible area (top left).


 

WCAG 2.0, 2.4.6, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visible 

Tools for testing:                      Visual inspection, Firefox and Internet Explorer

2.4.8.          Location (Level AAA)

Information about the user's location within a set of Web pages is available.

Understanding:

The position of the user within a number of web pages is indicated.

Example:

The current position is indicated in the navigation
or
The current position is indicated in the Breadcrumb
or
There is a textual indicator:
"You are on step 3 of 5".

WCAG 2.0, 2.4.8, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-location 

Tools for testing:                      Visual inspection

2.4.9.          Link Purpose (Link Only) (Level AAA)

A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

Understanding:

If links are understandable on their own, this helps a lot of people. For example, blind users of screen readers like to use the "Display link list" function. This displays all the links on a particular page, which can then be selected.

Example:

News article overview
A web page contains a number of news articles. The homepage lists the first few sentences of each article followed by a link,
"Continue reading". So that the links are also clear on their own, the title of the news message is added to the "Continue reading" link. The link now reads, “Continue reading Title XY”. 

Code example 1:

<p><img src="teas003.jpg" alt="View of the festival, Lake Zurich in the background"> This year’s Spring Festival was well attended. <span class"wt03"><a href="123.html">Read more . . .</a></span></p>

WCAG 2.0, 2.4.9, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-link 

Tools for testing:                      Web accessibility toolbar

2.4.10.      Section Headings (Level AAA)

Section headings are used to organize the content.

Note 1: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content.

Note 2: This success criterion covers sections within writing, not user interface components. User Interface components are covered under Success Criterion 4.1.2.

Understanding:

Section headings are important for the readability of longer text.

WCAG 2.0, 2.4.10, AAA           

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-headings

Tools for testing:                      Visual inspection

Information and the operation of user interface must be understandable.

3.1.        Readable: Make text content readable and understandable.

3.1.1.          Language of Page (Level A)

Understanding:

Indicating the correct main language of a particular page is very important. If, for example, German is not indicated for a German-language website, the screen reader will read the website in English.

Code example:

Accessible HTML documents can be supplied as HTML 4.01 with the content declaration text/html, to which the language attribute is added:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html lang=“de“>

or as an XHTML 1.0 document with the content declaration xml and text/html. Both content declarations require a language attribute:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de-ch" lang="de-ch">

<head>

or as an XHTML 1.1 document with the content declaration, application/xhtml+xml:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"     "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>

  <title>document écrit en français</title>

  <meta http-equiv="content-type" content="application/xhtml+xml;

  charset=utf-8" /> </head>

  <body>       ...document écrit en français...  </body>

</html>

or as HTML 5:

<!DOCTYPE html>

<html lang="en">

<head>

<title>Swapping Songs</title>

</head>

<body>

<h1>Swapping Songs</h1>

<p>Tonight I swapped some of the songs I wrote with some friends, who

gave me some of the songs they wrote. I love sharing my music.</p>

</body>

</html>

WCAG 2.0, 3.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-doc-lang-id

Tools for testing:                      Web accessibility toolbar

3.1.2.          Language of Parts (Level AA)

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

Understanding:

To facilitate correct pronunciation, sections of text in a language other than the default language should be marked up using the lang attribute.

Code example:

<h1>Swapping Songs</h1>

<p>Tonight I swapped some of the songs I wrote with some friends, who

gave me some of the songs they wrote. I love sharing my music.</p>

 

<blockquote lang="de">

<p>Da dachte der Herr daran, ihn aus dem Futter zu schaffen, aber der Esel merkte, dass kein guter Wind wehte, lief fort und machte sich auf den Weg nach Bremen: dort, meinte er, könnte er ja Stadtmusikant werden. Er kaufte sich beim bekannten Geigenbauer <span lang="fr">Henry Lagrumière</span> eine Violine.</p>

</blockquote>   

 

WCAG 2.0, 3.1.2, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-other-lang-id

Tools for testing:                      Web accessibility toolbar

3.1.3.          Unusual Words (Level AAA)

A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.

Understanding:

-       Special words, such as technical terms are explained in the running text or

-       They have a mechanism, e.g., a link to a glossary, where the term is explained.

WCAG 2.0, 3.1.3, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-idioms

Tools for testing:                      Visual inspection

3.1.4.          Abbreviations (Level AAA)

A mechanism for identifying the expanded form or meaning of abbreviations is available.

Understanding:

Abbreviations are either always explained in the running text or they have a link to a glossary.

The first time an abbreviation is used, it can be written out, and when the same abbreviation is used again with the same meaning, abbr or acronym and the title attribute can be used.

Abbreviations should be marked up using the abbr or acronym and the title attribute. The title attribute must be used in a way that supports accessibility. This technical support means that screen readers can also read the title attribute.

Common and widely known abbreviations, such as PDF, do not have to be explained.

Example:

<p>Today the United Nations Organization (UNO) elected the new secretary.</p>

<p>As the <abbr title="United Nations Organization" lang="en">UNO</abbr> was occupied for a long time ...</p>

 

WCAG 2.0, 3.1.4, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-located 

Tools for testing:                      Visual inspection

3.1.5.          Reading Level (Level AAA)

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

Understanding:

When communicating important instructions or essential information, summaries should be provided in simple language to aid those who may have difficulty understanding written language.

Example:

Medical information for the general public
A research group publishes its new findings on a web page. Every item it contributes is introduced with a summary containing all the important information in simple language.

An e-learning application
An online course in Spanish cultural history contains texts suitable for different reading levels. Summaries use simple language, photos and info graphics to illustrate and reduce the complexity of the material, making it easy for non-native students, for example, to complete the course in their first semester.

WCAG 2.0, 3.1.5, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-supplements 

Tools for testing:                      Visual inspection

3.1.6.          Pronunciation (Level AAA)

A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation.

Understanding:

Information on pronunciation can be provided in the text directly after the word, with a link to a glossary with pronunciation information or with the ruby element.

Example:

<p>When we talk about these guidelines, we often just call them
 <ruby>
   <rb>WCAG</rb>
    <rp>(</rp>
     <rt>Wuh-KAG</rt>
    <rp>)</rp>
 </ruby>.
</p>

WCAG 2.0, 3.1.6, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-pronunciation 

Tools for testing:                      Visual inspection, Internet Explorer, Firefox with "XHTML Ruby" add-on

3.2.        Predictable: Make Web pages appear and operate in predictable ways.

3.2.1.          On Focus (Level A)

When any component receives focus, it does not initiate a change of context.

Understanding:

So that websites work predictably for all users, no windows should be opened, no forms should be sent and no functions should be activated simply because an element receives focus.

WCAG 2.0, 3.2.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-receive-focus 

Tools for testing:                      Visual inspection

3.2.2.          On Input (Level A)

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Understanding:

So that websites work predictably for all users, no windows should be opened, no forms should be sent and no functions should be activated simply because the user activates an input. An exception can be made if the user is informed of the automatic behavior at the correct time, i.e., directly before using the component.

Example:

A selection from a drop-down menu does not automatically activate a link — the selection must be confirmed by the user (e.g., "Select" button).

When the user clicks on a checkbox, content-dependent selection options appear, though only after the user has pressed a button to confirm the checkbox selection.

Example 3.2.2 Automatic input functions

Figure 8: If drop-down menus for quick access are programmed with JavaScript to activate a link automatically after selection, users are misled and irritated. It is always better for links to be activated when the user intentionally presses a button, e.g., "Confirm".

WCAG 2.0, 3.2.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-unpredictable-change

Tools for testing:                      Visual inspection

3.2.3.          Consistent Navigation (Level AA)

Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.

Understanding:

So that websites work predictably for all users, the navigational elements on all pages must be arranged and structured consistently.

Example:

The search function is always in the same place

Categories in the navigation are consistent, unless the user activates expansion of subcategories, e.g., by activating a link.

WCAG 2.0, 3.2.3, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-consistent-locations 

Tools for testing:                      Visual inspection

3.2.4.          Consistent Identification (Level AA)

Components that have the same functionality within a set of Web pages are identified consistently.

Understanding:

So that websites work predictably for all users, elements that appear on several pages should be structured consistently.

Example:

The search function must always be structured and labeled identically on all pages.

WCAG 2.0, 3.2.4, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-consistent-functionality

Tools for testing:                      Visual inspection

3.2.5.          Change on Request (Level AAA)

Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

Understanding:

Some users do not understand changes that happen automatically. So that websites work predictably for all users, content should only change when the user has expressly requested it.

Example:

An "update" button
Instead of automatic updates, an
"Update now" button is provided.

A redirect
Sometimes a redirect from an old website to a new one is carried out in such a way that the user does not notice that there has been a redirect.

Clicking on a link is an example of a user-activated request.


 

WCAG 2.0, 3.2.5, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-no-extreme-changes-context 

Tools for testing:                      Visual inspection

3.3.        Input Assistance: Help users avoid and correct mistakes.

3.3.1.          Error Identification (Level A)

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Understanding:

If input errors are detected automatically, for example, when filling out a contact form, notifications should appear in readable text form, either as an error message ("system alert") or in the visible area where the content begins. The notification comes before the form and the incorrect field is identified in text form; however, it can also be identified visually. It is best to show the error messages as links, so it is possible to jump directly to the incorrect input field.

Example 3.3.1 Error detection

Figure 9: This error message is located where the content begins and names the incorrect input fields. It uses a link to direct the user to the first error. The notifications are in text form and use the color red as a visual cue.

WCAG 2.0, 3.3.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-identified

Tools for testing:                      Visual inspection

3.3.2.          Labels or Instructions (Level A)

Labels or instructions are provided when content requires user input.

Understanding:

If inputs are absolutely necessary or they are requested in a particular format, the instructions should be clear and readable for all users.

Example of mandatory fields:

When specifying a "required input field" you should bear in mind that an asterisk (*), like all punctuation, is not seen by users of screen readers. So that blind people know which fields require an input, the following text should appear in the label element (see code examples). Alternatively, graphics can be used with an asterisk when they include the alt text "required field". Another option for identifying mandatory fields is the WAI-ARIA script with "aria-required="true".

To avoid redundancy, only one of the recommended measures should be used.

Example 3.3.2 Required input field Code example 1:

<form action="post">
<p><label for=" firstName "><span class="hidden">Erforderlich </span>Vorname:*</label>
<input id="firstName" type="text" /></p>

The example shows how, in addition to using an asterisk, the status, "required", can be communicated to screen readers using the CSS class, "hidden", (description see code example in SC 1.3.1. A).

Example 3.3.2 Required input field Code example 2:

<form action="post">
<p><label for="firstName">Vorname:*</label>
<input id="firstName" type="text" aria-required="true" /></p>

 </form>

The example shows how simply the aria attribute, "aria required", can be used. However, it works only with newer browsers and screen readers. For compatibility with older environments, see technology aria4.

WCAG 2.0, 3.3.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-cues

Tools for testing:                      Visual inspection

3.3.3.          Error Suggestion (Level AA)

If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

Understanding:

If inputs are necessary or they are requested in a particular format, the instructions should be clear and readable for all users. For complicated formats an example should be given or error correction should help with input.

Example:

Input of date format (dd/mm/yyyy).

WCAG 2.0, 3.3.3, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-suggestions

Tools for testing:                      Visual inspection

3.3.4.          Error Prevention (Legal, Financial, Data) (Level AA)

For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

Reversible: Submissions are reversible.

Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Understanding:

For all inputs where errors could have severe consequences, it is important that all users be able to check, confirm and change or delete the data before transfer.

Example:

Before an order in an online shop is sent, a confirmation page is presented with the entire order and the customer data. The order is only carried out after confirmation on this page.

Example 3.3.4 Error prevention

Figure 10: Confirmation pages help a great deal with error prevention. The summary allows the user to review the order; using the "Edit" button it is possible to go back in the order process and make a revision; using the "Send order" button the order process is carried out with all its consequences.

WCAG 2.0, 3.3.4, AA               

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-reversible

Tools for testing:                      Visual inspection

Non-evaluated AAA criteria:

3.3.5.          Help (Level AAA)

Context-sensitive help is available.

Understanding:

Context-sensitive help only needs to be offered if the text in the label is not sufficient to describe the entire functionality. All users should be able to detect and use the help.

Example:

Online job application
Some questions on the application form are hard to understand. A help link next to each question leads to instructions and explanations for each question.

WCAG 2.0, 3.3.5, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-context-help

Tools for testing:                      Visual inspection

3.3.6.          Error Prevention (All) (Level AAA)

For Web pages that require the user to submit information, at least one of the following is true: (Level AAA)

Reversible: Submissions are reversible.

Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Understanding:

This success criterion is based on SC 3.3.4 Error prevention, and it is effective for all user inputs.

Example:

In a contact form, all the inputs are presented to the user again before they are sent. It is possible to confirm or correct them.

WCAG 2.0, 3.3.6, AAA             

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-reversible-all 

Tools for testing:                      Visual inspection

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

4.1.        Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1.          Parsing (Level A)

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.

Understanding:

The page code is checked (validated) and corrected.

Elements that are implemented with markup language have complete start and end tags, they are nested correctly according to specifications, they have no duplicate attributes and every ID is unique, except where the specifications allow otherwise.

Note:

Browsers and other user agents, such as screen readers, parse documents according to the specified doctype using the doctype definition (DTD). The doctype must be written in a way that is valid and correct.

List of the recommended doctypes: http://www.w3.org/QA/2002/04/valid-dtd-list.html

The code must be well-formed and valid so that web content can be qualitatively navigated and reviewed. XHTML documents require code that is well-formed and syntactically correct – screen readers and screen magnifiers rely on this more than visual browsers and cannot tolerate many errors.

WCAG 2.0, 4.1.1, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-ensure-compat-parses

Tools for testing:                      W3C validator

4.1.2.          Name, Role, Value (Level A)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Understanding:

In-house programming can be optimized for keyboard operation using "Accessibility for Rich Internet Applications" (WAI-ARIA).

Web designers who program their own components should observe the specifications of the web standards for the components produced. Various technologies have proprietary accessibility APIs, e.g., Java, Flash, Mozilla DHTML, which should also be observed.

It should be possible to use websites and produce UI components with all current user agents, with browsers as well as screen readers and screen magnifiers, etc.

Example:

Introduction to WAI-ARIA
Author: Gez Lemon, 01.08.2008.
http://dev.opera.com/articles/view/introduction-to-wai-aria/

WCAG 2.0, 4.1.2, A                  

Meeting the requirement:       http://www.w3.org/WAI/WCAG20/quickref/#qr-ensure-compat-rsv 

Tools for testing:                      Visual inspection



II.        Appendix

Important terms in WCAG 2

The WCAG 2 contains important terms that are described in the glossary. The glossary is distributed together with this document.
Glossary for Accessibility Checklist 2: http://www.access-for-all.ch/checklist
WAI Glossary: http://www.w3.org/TR/WCAG20/#glossary

WCAG 2 conformance requirements

To achieve conformance with one of the levels — A (lowest), AA (recommended) or AAA (highest) — the entire website must meet all the success criteria of the relevant level(s) or provide an alternative version with level conformance. The conformance logo must be accompanied on the website by a short explanation of the required components of a conformance claim: http://www.w3.org/TR/WCAG20/#conformance-reqs

Partial conformance as per WCAG 2

If a website meets all criteria and unchecked content is not accessible (e.g., the integrated share indices from an external supplier), this can be noted with a "declaration of partial conformance". The requirements for this are:

a.        The content in question is not under the control of the author.

b.       All parts (pages and areas) are understandably identified and explained.

Conformance requirements in Swiss Legislation

Consideration of the WCAG 2 criteria for conformance levels A and AA are required, see Federal Directive P028: http://www.isb.admin.ch/themen/standards/alle/03237/

Background to the checklist

The compilation of this checklist was made possible by the Federal Office of Communication OFCOM, the Federal Chancellery FC, the Swiss Post and Swisscom. A working group, a member from each of these organizations headed by the "Access for All" foundation created the checklist. A group of experts took part in the review of the checklists on a voluntary basis.

The authors

First name

Surname

Company

Isabelle

Haas

Post

Beatrice

Stampbach

Swisscom

Markus

Riesch

Access for All

Sven

Jenzer

Access for All

The Expert review group

First name

Surname

Company

Alain

Vérgeres

Swisscom

Oliver

Füri

Post

Julia

Dressler

Unic

Christian

Hahnloser

Unic

Kerstin

Probiesch

Independent accessibility expert

Tina

Kohler

BIT

Copyright

Circulation and further use of this checklist with explanations and glossary is expressly permitted, provided the name, "AG Accessibility Checklist 2" is used, the reference address (URL) is specified, and circulation under similar conditions is stipulated. In case of revision, an example copy is requested. Mail to: checklist@access-for-all.ch

Updates

You can always find the most up-to-date version at: http://www.access-for-all.ch/checklist
If you have suggestions or you have found an error, please inform the authors.
Mail to: checklist@access-for-all.ch