Techniques for WCAG 2.0

Skip to Content (Press Enter)

Failures for WCAG 2.0

This Web page lists Failures from Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0. Technology-specific techniques do not replace the general techniques: content developers should consider both general techniques and technology-specific techniques as they work toward conformance.

Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0 success criteria and conformance requirements. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.

For information about the techniques, see Introduction to Techniques for WCAG 2.0. For a list of techniques for other technologies, see the Table of Contents.

Table of Contents



F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS

Applicability

All technologies that support CSS.

This failure relates to:

Description

This describes the failure condition that results when CSS, rather than structural markup, is used to modify the visual layout of the content, and the modified layout changes the meaning of the content. Using the positioning properties of CSS2, content may be displayed at any position on the user's viewport. The order in which items appear on a screen may be different than the order they are found in the source document. Assistive technologies rely on the source code or other programmatically determined order to render the content in the correct sequence. Thus, it is important not to rely on CSS to visually position content in a specific sequence if this sequence results in a meaning that is different from the programmatically determined reading order.

Examples

Failure Example 1

The following example demonstrates how CSS has been improperly used to create a set of columns. In addition, the text appears visually in the browser in a different order than in the markup.

In this example a class is defined for each object that is being positioned. When style sheets are applied, the text appears in two columns. Elements of class "menu1" (Products) and "menu2" (Locations) appear as column headings. "Telephones, Computers, and Portable MP3 Players" are listed under Products and "Idaho" and "Wisconsin" are listed under Locations (note the different order for Idaho and Wisconsin in the source code order).

Since appropriate structural elements have not been used, when style sheets are not applied, all of the text appears in one line in the source order, "Products Locations Telephones Computers Portable MP3 Players Wisconsin Idaho."

Here is the HTML content:

Example Code:


<div class="box">      
     <span class="menu1">Products</span>       
     <span class="menu2">Locations</span>       
     <span class="item1">Telephones</span>       
     <span class="item2">Computers</span>       
     <span class="item3">Portable MP3 Players</span>       
     <span class="item5">Wisconsin</span>       
     <span class="item4">Idaho</span>
</div>

Here are the styles for the above content:

Example Code:


.menu1 { 
     position: absolute; 
     top: 3em; 
     left: 0em;     
     margin: 0px; 
     font-family: sans-serif;     
     font-size: 120%; 
     color: red; 
     background-color: white 
}        
.menu2 { 
     position: absolute; 
     top: 3em; 
     left: 10em;     
     margin: 0px; 
     font-family: sans-serif;     
     font-size: 120%; 
     color: red; 
     background-color: white 
}      
.item1 { 
     position: absolute; 
     top: 7em; 
     left: 0em; 
     margin: 0px 
}      
.item2 { 
     position: absolute; 
     top: 8em; 
     left: 0em; 
     margin: 0px 
}      
.item3 { 
     position: absolute; 
     top: 9em; 
     left: 0em; 
     margin: 0px 
}      
.item4 { 
     position: absolute; 
     top: 7em; 
     left: 14em; 
     margin: 0px 
}      
.item5 { 
     position: absolute; 
     top: 8em; left: 14em; 
     margin: 0px 
}      
#box { 
     position: absolute; 
     top: 5em; 
     left: 5em 
} 

A better solution for this content would be to use more meaningful elements, such as a table or a definition list.

Resources

No resources available for this technique.

Tests

Procedure

For content which uses CSS for positioning:

  1. Remove the style information from the document or turn off use of style sheets in the user agent.

  2. Check that the reading order of the content is correct and the meaning of the content is preserved.

Expected Results

  • If step #2 is false, then this failure condition applies and the content fails this Success Criterion.


F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text

Applicability

All technologies that support images or presentation markup.

This failure relates to:

Description

This document describes a failure that occurs when a change in the appearance of text conveys meaning without using appropriate semantic markup. This failure also applies to images of text that are not enclosed in the appropriate semantic markup.

Examples

Failure Example 1: Using CSS to style the p element to look like a heading

The author intended to make a heading but didn't want the look of the default HTML heading. So they used CSS to style the P element to look like a heading and they called it a heading. But they failed to use the proper HTML heading element. Therefore, the Assisitive Technology could not distinguish it as a heading.

Example Code:


 <style type="text/css">
 .heading1{
        font-family: Times, serif;
        font-size:200%;
        font-weight:bold;
 }
 </style>

 <p class="heading1">Introduction</p>
 <p>This introduction provides detailed information about how to use this 
 ........
 </p>

Note: In this case, the proper approach would be to use CSS to style the H1 element in HTML.

Failure Example 2: Images of text used as headings where the images are not marked up with heading tags

Chapter1.gif is an image of the words, "Chapter One" in a Garamond font sized at 20 pixels. This is a failure because at a minimum the img element should be enclosed within a header element. A better solution would be to eliminate the image and to enclose the text within a header element which has been styled using CSS.

Example Code:


<img src="Chapter1.gif" alt="Chapter One">
 
<p>Once upon a time in the land of the Web.....
</p>

Failure Example 3: Using CSS to visually emphasize a phrase or word without conveying that emphasis semantically

The following example fails because the information conveyed by using the CSS font-weight property to change to a bold font is not conveyed through semantic markup or stated explicitly in the text.

Here is a CSS class to specify bold:


.yell {
  font-weight:bold;
  text-transform: uppercase;
}

And here is the corresponding HTML:


<p>
 "I said, <span class="yell">no</span>, not before dinner!", 
 was the exasperated response when Timmy asked his mother for the 
 fourth time for an ice cream cone. 
 </p>

Resources

No resources available for this technique.

Tests

Procedure

  1. For images of text:

    1. Check if any images of text are used to convey structural information of the document.

    2. Check that the proper semantic structure (e.g., HTML headings) is used with the text to convey the information.

  2. For styled text that conveys information:

    1. Check if there is any styled text that conveys structural information.

    2. Check that in addition to styling, the proper semantic structure is used with the text to convey the information.

Expected Results

  • If check #1.1 is true, then #1.2 is true.

  • If check #2.1 is true, then #2.2 is true.


F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information

Applicability

All technologies that support CSS.

This failure relates to:

Description

The CSS background-image property provides a way to include images in the document with CSS without any reference in the HTML code. The CSS background-image property was designed for decorative purposes and it is not possible to associate text alternatives with images that are included via CSS. Text alternatives are necessary for people who cannot see images that convey important information. Therefore, it is a failure to use this property to add images to convey important information. This failure would apply equally in a case where the background image was declared in the HTML style attribute, as well as in a case where the background image declaration was created dynamically in a client script (see example 3 below).

Note: Embedding information into a background image can also cause problems for people who use alternate backgrounds in order to increase legibility and for users of high contrast mode in some operating systems. These users, would lose the information in the background image due to lack of any alternative text.

Examples

Failure Example 1:

In the following example, part of the content is contained in an image that is presented by CSS alone. In this example, the image TopRate.png is a 180 by 200 pixel image that contains the text, "19.3% APR Typical Variable."

Example Code:

 The CSS contains: 
p#bestinterest {
  padding-left: 200px;
  background: transparent url(/images/TopRate.png) no-repeat top left;
}

It is used in this excerpt:

Example Code:

 
<p id="bestinterest">
  Where else would you find a better interest rate?
</p>

Failure Example 2:

A book distributor uses background images to provide icons against a list of book titles to indicate whether they are new, limited, in-stock, or out of stock.

The CSS contains:

Example Code:


ul#booklist li {
  padding-left: 20px;
}

ul#booklist li.new {
  background: transparent url(new.png) no-repeat top left; 
}
                            
ul#booklist li.limited {
  background: transparent url(limited.png) no-repeat top left; 
}
                            
ul#booklist li.instock {
  background: transparent url(instock.png) no-repeat top left; 
}

ul#booklist li.outstock {
  background: transparent url(outstock.png) no-repeat top left; 
}

It is used in this excerpt:

Example Code:


<ul id="booklist">
  <li class="new">Some book</li>
  <li class="instock">Some other book</li>
  <li class="limited">A book we desperately want to get rid of</li>
  ...
  <li class="outstock">A book you actually want </li>
</ul>

Failure Example 3:

Using the code from example 1, the same background image is declared in the HTML style attribute:

<p id="bestinterest" style="background: transparent url(/images/TopRate.png) no-repeat top left;" >
Where else would you find a better interest rate?
<p>

In the following code, the background image declaration is created in a client script:

<script type="text/javascript">
var newP = document.createElement('p');
var newPText = document.createTextNode('Where else would you find a better interest rate?');
newP.appendChild(newPText);
newP.style.background = 'transparent url(/images/TopRate.png) no-repeat top left';
document.body.appendChild(newP);
</script> 

Resources

No resources available for this technique.

Tests

Procedure

  1. Examine all images added to the content via CSS, HTML style attributes, or dynamically in script as background images.

  2. Check that the images do not convey important information.

  3. If an image does convey important information, the information is provided to assistive technologies and is also available when the CSS image is not displayed.

Expected Results

  • If step #2 and step #3 are both false, then this failure condition applies and the content fails this Success Criterion.


F4: Failure of Success Criterion 2.2.2 due to using text-decoration:blink without a mechanism to stop it in less than five seconds

Applicability

Cascading Style Sheets.

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F4.

Description

CSS defines the blink value for the text-decoration property. When used, it causes any text in elements with this property to blink at a predetermined rate. This cannot be interrupted by the user, nor can it be disabled as a user agent preference. The blinking continues as long as the page is displayed. Therefore, content that uses text-decoration:blink fails the Success Criterion because blinking can continue for more than three seconds.

Examples

Failure Example 1

A product list page uses the text-decoration:blink style on an element to draw attention to sale prices. This fails the Success Criterion because users cannot control the blink.

Example Code:


<p>My Great Product <span style="text-decoration:blink">Sale! $44,995!</span></p>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Examine inline styles, internal stylesheets, and external stylesheets for the text-decoration property with a value of "blink".

  2. If the property is used, determine if the ID, class, or element identified by selectors on which this property is defined are used in the document.

Expected Results

  • If step #1 and step #2 are true, the content fails the success criterion.


F7: Failure of Success Criterion 2.2.2 due to an object or applet, such as Java or Flash, that has blinking content without a mechanism to pause the content that blinks for more than five seconds

Applicability

Technologies that support blinking content within an object, applet, or a plug-in.

This failure relates to:

Description

When content that is rendered by a plug-in or contained in an applet blinks, there may be no way for the user agent to pause the blinking. If neither the plug-in, applet, nor the content itself provides a mechanism to pause the content, the user may not have sufficient time to read the content between blinks or it may be so distracting that the user will not be able to read other content on the page.

Examples

  • An applet displays an advertisement on a news site. The applet blinks key words in the advertisement in order to call the user's attention to it. The blinking cannot be paused through any user agent settings and the applet does not provide a mechanism to stop it.

Tests

Procedure

For each page that has blinking content in a plugin or applet:

  1. Determine if the content continues to blink for longer than 5 seconds.

  2. Determine if there is a means to pause the blinking content.

Expected Results

  • If step #1 is true and step #2 is false, the content fails the success criterion.


F8: Failure of Success Criterion 1.2.2 due to captions omitting some dialogue or important sound effects

Applicability

Applies to all technologies.

This failure relates to:

Description

This describes a failure condition for all techniques involving captions. If the "caption" does not include all of the dialogue (either verbatim or in essence) as well as all important sounds then the 'Captions' are not real captions.

NOTE: Captions sometimes simplify the spoken text both to make it easier to read and to avoid forcing the viewer to read at very high speed. This is standard procedure and does not invalidate a caption.

Examples

Failure Example 1

Examples of text streams that are not captions include:

  • text that contains the dialogue (possibly simplified dialogue) but that does not describe important sounds

  • text that omits dialogue during portions of the material

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. View the material with captioning turned on.

  2. Check that all dialogue is accompanied by a caption.

  3. Check that all important sounds are captioned.

Expected Results

  • If check #2 and check #3 are false, then this failure condition applies and the content fails the Success Criterion.


F9: Failure of Success Criterion 3.2.5 due to changing the context when the user removes focus from a form element

Applicability

General.

This failure relates to:

Description

This document describes a failure that occurs when removing focus from a form element, such as by moving to the next element, causes a change of context.

Examples

Failure Example 1:

The user is going through the form filling out the fields in order. When he moves from the third field to the forth, the form submits.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Find all form elements.

  2. Go through them in order.

  3. Check if the form submits when you move from one field to the next.

  4. Check if moving from one field to the next launches any new windows.

  5. Check if moving from one field to the next navigates to another screen.

Expected Results

  • If step #3, step #4, or step #5 is true, then this failure condition applies and the content fails the Success Criterion.


F10: Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining multiple content formats in a way that traps users inside one format type

Applicability

Applies when content creates a situation where the user can enter the content using the keyboard, but cannot exit the content using the keyboard.

This failure relates to:

Description

When content includes multiple formats, one or more user agents or plug-ins are often needed in order to successfully present the content to users. For example, a page that includes XHTML, SVG, SMIL and XForms may require a browser to load as many as three different plug-ins in order for a user to successfully interact with the content. Some plug-ins create a common situation in which the keyboard focus can become "stuck" in a plug-in, leaving a keyboard-only user with no way to return to the other content.

Examples

  • A plug-in traps the user A user tabs into a plug-in and is unable to return to content outside the plug-in content with the keyboard. The user has to restart their browser in order to regain control and navigate to a new page and is unable to access any content that appears beyond the plug-in content.

Resources

No resources available for this technique.

Tests

Procedure

  1. Using a keyboard, navigate through the content.

  2. Check to see that the keyboard focus is not "trapped" and it is possible to move keyboard focus out of the plug-in content without closing the user agent or restarting the system.

Expected Results

  • If the keyboard focus becomes "trapped," then this failure condition applies and content fails the Success Criterion and conformance requirement 5.


F12: Failure of Success Criterion 2.2.5 due to having a session time limit without a mechanism for saving user's input and re-establishing that information upon re-authentication

Applicability

Sites that require user login to submit input and that terminate the session after a some period of inactivity.

This failure relates to:

Description

Web servers that require user authentication usually have a session mechanism in which a session times out after a period of inactivity from the user. This is sometimes done for security reasons, to protect users who are assumed to have left their computer exposed in a state where someone could do something harmful to them such as transfer bank funds or make an unauthorized purchase. A user with a disability may actually still be working to complete the form as it may take him or her longer to complete the form than would normally be expected. Upon re-authentication, if the state of the user's session is not restored, including all data that had been previously entered into the form, he or she will have to start over. And for these users, it is likely that the session will time out again before they can complete the form. This sets up a situation where a user who needs more time to complete the form can never complete it.

Examples

  • A user submits a form on an authenticated site after their login has expired. On submitting the form, they are prompted to log in again, and then taken to a general welcome page. The data is not processed and they must try again.

  • A user submits a form on an authenticated site after their login has expired. On submitting the form, they are prompted to log in again, and then taken back to the page they were on just before the login, which in this case contains the form they attempted to submit. However, the form is not populated with the data they just entered, and they must re-enter it.

Tests

Procedure

On a site where authentication is required, user input is collected, and which ends the user's session after a known period of inactivity:

  1. Provide user input as required but allow the session to time out, then submit the form.

  2. When requested, re-authenticate with the server.

  3. Determine if the function is performed using the previously submitted data.

Expected Results

  • If step #3 is false, the site fails the Success Criterion.


F13: Failure of Success Criterion 1.1.1 and 1.4.1 due to having a text alternative that does not include information that is conveyed by color differences in the image

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to describe the failure that occurs when an image uses color differences to convey information, but the text alternative for the image does not convey that information. This can cause problems for people who are blind or colorblind because they will not be able to perceive the information conveyed by the color differences.

Examples

  • A bar chart of sales data is provided as an image. The chart includes yearly sales figures for four employees in the Sales Department. The text alternative for the image says, "The following bar chart displays the yearly sales figures for the Sales Department. Mary sold 3.1 Million; Fred, 2.6 Million; Bob, 2.2 Million; and Andrew, 3.4 Million. The red bars indicate sales that were below the yearly quota". This text alternative fails to provide the information which is conveyed by the color red in the image. The alternative should indicate which people did not meet the sales quota rather than relying on color.

Resources

No resources available for this technique.

Tests

Procedure

For all images in the content that convey information by way of color differences:

  1. Check that the information conveyed by color differences is not included in the text alternative for the image.

Expected Results

  • If step #1 is true, then this failure condition applies and content fails the Success Criterion.


F14: Failure of Success Criterion 1.3.3 due to identifying content only by its shape or location

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to show how identifying content only by its visual shape or location makes content difficult to understand and operate. When only visual identification or location is used, users with visual disabilities may find it difficult to locate content since they cannot see the screen or may perceive only a small portion of the screen at one time. Also, location of content can vary if page layout varies due to variations in font, window, or screen size.

Examples

  • The navigation instructions for a site state, "To go to next page, press the button to the right. To go back to previous page, press the button to the left."

  • A user is reading a news article in an on-line newspaper. The article contains an illustration and additional links for more information. Within the text of the article is a statement, "Please see sidebar to the left of the illustration for links to additional information." An assistive technology user would have difficulty finding the illustration and the sidebar. Some alternatives would be to include the list of links within the text; to provide an in-page link within the text which links to the sidebar; to provide a heading for the sidebar which can be used for navigation and refer to the heading in the instructions.

  • A user is completing an on-line survey. There are three buttons at the bottom of the survey form. The instructions state, "Press the square button to exit the survey without saving, Press the triangle button to save in-progress survey results. You may return later to complete the survey. Press the round button to submit the survey results." A screen reader user or a user unable to distinguish shapes cannot determine which button is square, triangular, or round. The buttons must have additional information to indicate their functions or their shapes.

Resources

No resources available for this technique.

Tests

Procedure

  1. Examine the Web page for textual references to content within the Web page.

  2. Check that the references do not rely on only the visual shape or location of the content.

Expected Results

  • If step #2 is false, then this failure condition applies and the content fails this Success Criterion.


F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely

Applicability

Applies to all technologies that support an accessibility API.

This failure relates to:

Description

When standard controls from accessible technologies are used, they usually are programmed in a way that uses and supports the accessibility API. If custom controls are created, however, then it is up to the programmer to be sure that the newly created control supports the accessibility API. If this is not done, then assistive technologies will not be able to understand what the control is or how to operate it or may not even know of its existence.

Note: For technologies that support it, WAI-ARIA can be used to expose a custom control's role, name, value, states, and properties via the accessibility API for the technology.

Examples

Failure Example 1

A music player is designed with custom controls that look like musical notes that are stretched for volume, tone etc. The programmer does not make the new control support the Accessibility API. As a result - the controls cannot be identified or controlled from AT.

Resources

(none currently listed)

Tests

Procedure

  1. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check the controls to see if they support the accessibility API.

Expected Results

  • If step #1 is false, then this failure condition applies and the content fails this Success Criterion


F16: Failure of Success Criterion 2.2.2 due to including scrolling content where movement is not essential to the activity without also including a mechanism to pause and restart the content

Applicability

All technologies that support visual movement or scrolling.

This failure relates to:

Description

In this failure technique, there is moving or scrolling content that cannot be paused and resumed by users. In this case, some users with low vision or cognitive disabilities will not be able to perceive the content.

Examples

  • A page has a scrolling news ticker without a mechanism to pause it. Some users are unable to read the scrolling content.

Tests

Procedure

On a page with moving or scrolling content,

  1. Check that a mechanism is provided in the Web page or user agent to pause moving or scrolling content.

  2. Use the pause mechanism to pause the moving or scrolling content.

  3. Check that the moving or scrolling has stopped and does not restart by itself.

  4. Check that a mechanism is provided in the Web page or user agent to restart the paused content.

  5. Use the restart mechanism provided to restart the moving content.

  6. Check that the movement or scrolling has resumed from the point where it was stopped.

Expected Results

  • If step #1, step #3, step #4, or step #6 are false, then the content fails the success criterion.


F19: Failure of Conformance Requirement 1 due to not providing a method for the user to find the alternative conforming version of a non-conforming Web page

Applicability

Sites that provide alternative, WCAG-conforming versions of nonconforming primary content.

This failure relates to:

Description

This failure technique describes the situation in which an alternate, conforming version of the content is provided, but there is no direct way for a user to tell that it is available or where to find it. Such content fails the Success Criterion because the user cannot find the conforming version.

Examples

  • A link or a search takes a user directly to one of the nonconforming pages in the Web site. There is neither an indication that an alternate page is available, nor a path to the alternate page from the nonconforming page.

  • Nonconforming pages on the Web site inform the user that a conforming version is available and provide a link to the home page. However, the user must search the site for the conforming version of the page, so the functionality does not meet the requirements of the Success Criterion.

  • A user is able to use the nonconforming Web site for most pages. But when the user is not able to access a particular page, there is no way to find the conforming version of the page.

Tests

Procedure

  1. Identify a nonconforming page that has an alternative conforming version.

  2. Determine if the nonconforming page provides a link to the conforming version.

Expected Results

  1. If step #2 is false, the content fails the Success Criterion.


F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur

Applicability

Applies to all technologies.

This failure relates to:

Description

The objective of this failure condition is to address situations where the non-text content is updated, but the text alternative is not updated at the same time. If the text in the text alternative cannot still be used in place of the non-text content without losing information or function, then it fails because it is no longer a text alternative for the non-text content.

Examples

  • Failure Example 1: A Sales chart is updated to October results, but the text alternative still describes September results.

  • Failure Example 2: Pictures on a home page change daily, but text alternatives are not updated at the same time.

  • Failure Example 3: The source attribute of images on a page is updated periodically using script, but the text alternatives are not updated at the same time.

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Check each text alternative to see if it is describing content other than the currently-displayed non-text content.

Expected Results

  • If step #1 is true then the text alternative is not up to date with current item, this failure condition applies, and content fails these Success Criteria.


F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by the user

Applicability

General

This failure relates to:

Description

Failure due to opening new windows when the user does not expect them. New windows take the focus away from what the user is reading or doing. This is fine when the user has interacted with a piece of User Interface and expects to get a new window, such as an options dialogue. The failure comes when pop-ups appear unexpectedly.

Examples

Failure Example 1:

When a user navigates to a page, a new window appears over the existing user agent window, and the focus is moved to the new window.

Failure Example 2:

A user clicks on a link, and a new window appears. The original link has no associated text saying that it will open a new window.

Failure Example 3:

A user clicks on the body of a page and a new window appears. No indication that the area that was clicked has functionality is present.

Failure Example 4:

A user clicks on undecorated text within the page and a new window appears. The page has no visible indication that the area is functional.

Resources

No resources available for this technique.

Tests

Procedure

  1. Load the Web page.

  2. Check if new (additional) windows open.

  3. Find every actionable element, such as links and buttons, in the Web page.

  4. Activate each element.

  5. Check if activating the element opens a new window.

  6. Check if elements that open new windows have associated text saying that will happen. The text can be displayed in the link, or available through a hidden association such as an HTML title attribute.

Expected Results

  • If step #2 is true, the failure condition applies and the content fails the Success Criterion

  • If step #5 is true and step #6 is false, the failure condition applies and the content fails the Success Criterion


F23: Failure of 1.4.2 due to playing a sound longer than 3 seconds where there is no mechanism to turn it off

Applicability

Applies to all technologies except those for voice interaction.

This failure relates to:

Description

This describes a failure condition for Success Criteria involving sound. If sound does not turn off automatically within 3 seconds and there is no way to turn the sound off then Success Criterion 1.4.2 would not be met. Sounds that play over 3 seconds when there is no mechanism to turn off the sound included in the content would fall within this failure condition.

Examples

Failure Example 1

  • A site that plays continuous background music

Failure Example 2

  • A site with a narrator that lasts more than 3 seconds before stopping, and there is no mechanism to stop it.

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Check that there is a way in a Web page to turn off any sound that plays automatically for more than three seconds.

Expected Results

  • If step #1 is not true then content fails Success Criterion 1.4.2


F24: Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colors without specifying background colors or vice versa

Applicability

All technologies that allow user agents to control foreground and background colors through personal stylesheets or other means.

This failure relates to:

Description

Users with vision loss or cognitive, language and learning challenges often prefer specific foreground and background color combinations. In some cases, individuals with low vision will find it much easier to see a Web page that has white text on a black background, and they may have set their user agent to present this contrast. Many user agents make it possible for users to choose a preference about the foreground or background colors they would like to see without overriding all author-specified styles. This makes it possible for users to view pages where colors have not been specified by the author in their preferred color combination.

Unless an author specifies both foreground and background colors, then they (the author) can no longer guarantee that the user will get a contrast that meets the contrast requirements. If, for example, the author specifies, that text should be grey, then it may override the settings of the user agent and render a page that has grey text (specified by the author) on a light grey background (that was set by the user in their user agent). This principle also works in reverse. If the author forces the background to be white, then the white background specified by the author could be similar in color to the text color preference expressed by the user in their user agent settings, thus rendering the page unusable to the user. Because an author can not predict how a user may have configured their preferences, if the author specifies a foreground text color then they should also specify a background color which has sufficient contrast with the foreground and vice versa.

It is not necessary that the foreground and background colors both be defined on the same CSS rule. Since CSS color properties inherit from ancestor elements, it is sufficient if both foreground and background colors are defined either directly or through inheritance by the time that color is applied to a given element.

Note: Best practice is to include all states of the text. For example, text, link text, visited link text, link text with hover and keyboard focus, etc.

Examples

Failure Example 1: Specifying only background color with CSS

In the example below the background color is defined on the CSS stylesheet, however the foreground color is not defined. Therefore, the example fails the Success Criterion.

Example Code:


  <!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">
<html>
<head>
 <title>Setting the canvas background</title>
    <style type="text/css">

       body {background-color:white}
    </style>
  </head>
  <body>
    <p>My background is white.</p>
  </body>
</html>

Failure Example 2: Specifying only foreground color with CSS

In the example below the foreground color is defined on the CSS stylesheet, however the background color is not defined. Therefore, the example fails the Success Criterion.

Example Code:


 <!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">
<html>
<head>
 <title>Setting the canvas background</title>
    <style type="text/css">
       body {color:white}
    </style>
  </head>

  <body>
    <p>My foreground is white.</p>
  </body>
</html>

Failure Example 3: Specifying foreground color of link text with CSS

In the example below the link text (foreground) color is defined on the body element. However, the background color is not defined. Therefore, the example fails the Success Criterion.

Example Code:


  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html>
<head>
 <title>A study of population dynamics</TITLE>
 <style type="text/css">
  a:link { color: red }
  a:visited { color: maroon }
  a:active { color: fuchsia }
 </style>

</head>
<body>
  <p>... document body... <a href="foo.htm">Foo</a></p>
</body>
</html>

Failure Example 4: Specifying only background color with bgcolor in HTML

In the example below the background color is defined on the body element, however the foreground color is not defined. Therefore, the example fails the Success Criterion.

Note that the use of the bgcolor attribute is deprecated as of HTML 4, but this failure example is included as this usage is still found on some web sites.

Example Code:

   
<!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">
      <html>
          <head>
              <title>A study of population dynamics</title>
          </head>
          <body bgcolor="white">
              <p> ... document body...</p>
          </body>
  </html>

Failure Example 5: Specifying only foreground color with the text attribute in HTML

In the example below the foreground color is defined on the body element, however the background color is not defined. Therefore, the example fails the Success Criterion.

Note that the use of the text attribute is deprecated as of HTML 4, but this failure example is included as this usage is still found on some web sites.

Example Code:


 <!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">
<html>
<head>
 <title>A study of population dynamics</title>

</head>
<body text="white">
  <p>... document body...</p>
</body>
</html>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Examine the code of the Web page.

  2. Check to see if an author-specified foreground color is present

  3. Check to see if an author-specified background color is present

Note 1: Color and background color may be specified at any level in the cascade of preceding selectors, by external stylesheets or through inheritance rules.

Note 2: Background color may also be specified using a background image with the CSS property 'background-image' or with the CSS property 'background' (with the URI of the image, e.g., 'background: url("images/bg.gif")'). With background images, it is still necessary to specify a background color, because users may have images turned off in their browser. But the background image and the background color need to be checked.

Expected Results

If step #2 is true but step #3 is false, OR if step #3 is true but step #2 is false then this failure condition applies and content fails these Success Criteria.


F25: Failure of Success Criterion 2.4.2 due to the title of a Web page not identifying the contents

Applicability

All technologies.

This failure relates to:

Description

This describes a failure condition when the Web page has a title, but the title does not identify the contents or purpose of the Web page.

Examples

Failure Example 1

Examples of text that are not titles include:

  • Authoring tool default titles, such as

    • "Enter the title of your HTML document here,"

    • "Untitled Document"

    • "No Title"

    • "Untitled Page"

    • "New Page 1"

  • Filenames that are not descriptive in their own right, such as "report.html" or "spk12.html"

  • Empty text

  • Filler or placeholder text

Failure Example 2

A site generated using templates includes the same title for each page on the site. So the title cannot be used to distinguish among the pages.

Resources

No resources available for this technique.

Tests

Procedure

  1. Check whether the title of each Web page identifies the contents or purpose of the Web page .

Expected Results

  • If step #1 is false, then this failure condition applies and the content fails this Success Criterion.


F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to show how using a graphical symbol to convey information can make content difficult to comprehend. A graphical symbol may be an image, an image of text or a pictorial or decorative character symbol (glyph) which imparts information nonverbally. Examples of graphical symbols include an image of a red circle with a line through it, a "smiley" face, or a glyph which represents a check mark, arrow, or other symbol but is not the character with that meaning. Assistive technology users may have difficulty determining the meaning of the graphical symbol. If a graphical symbol is used to convey information, provide an alternative using features of the technology or use a different mechanism that can be marked with an alternative to represent the graphical symbol. For example, an image with a text alternative can be used instead of the glyph.

Examples

Failure Example 1: Glyphs Used to Indicate Status

A shopping cart uses two simple glyphs to indicate whether an item is available for immediate shipment. A check mark indicates that the item is in stock and ready to ship. An "x" mark indicates that the item is currently on back order and not available for immediate shipment. An assistive technology user could not determine the status of the current item.

Resources

No resources available for this technique.

Tests

Procedure

  1. Examine the page for non-text marks that convey information.

  2. Check whether there are other means to determine the information conveyed by the non-text marks.

Expected Results

  • If step #2 is false, then this failure condition applies and the content fails this Success Criterion.


F30: Failure of Success Criterion 1.1.1 and 1.2.1 due to using text alternatives that are not alternatives (e.g., filenames or placeholder text)

Applicability

Applies to all technologies.

This failure relates to:

Description

This describes a failure condition for all techniques involving text alternatives. If the text in the "text alternative" cannot be used in place of the non-text content without losing information or function then it fails because it is not, in fact, an alternative to the non-text content.

Examples

Failure Example 1

Examples of text that are not text alternatives include:

  • placeholder text such as " " or "spacer" or "image" or "picture" etc that are put into the 'text alternative' location on images or pictures.

  • programming references that do not convey the information or function of the non-text content such as "picture 1", "picture 2" or "0001", "0002" or "Intro#1", "Intro#2".

  • filenames that are not valid text alternatives in their own right such as "Oct.jpg" or "Chart.jpg" or "sales\\oct\\top3.jpg"

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Check each text alternative to see if it is not actually a text alternative for the non-text content.

Expected Results

  • If step #1 is true then this failure condition applies and content fails the Success Criterion.


F31: Failure of Success Criterion 3.2.4 due to using two different labels for the same function on different Web pages within a set of Web pages

Applicability

Applies to all technologies.

This failure relates to:

Description

Components that have the same function in different Web pages are more easily recognized if they are labeled consistently. If the naming is not consistent, some users may get confused.

Note: Text alternatives that are "consistent" are not always "identical." For instance, you may have an graphical arrow at the bottom of a Web page that links to the next Web page. The text alternative may say "Go to page 4." Naturally, it would not be appropriate to repeat this exact text alternative on the next Web page. It would be more appropriate to say "Go to page 5". Although these text alternatives would not be identical, they would be consistent, and therefore would not be failures for this Success Criterion.

Examples

Failure Example 1:

One of the most common examples of using inconsistent labels for components with the same function is to use a button that says "search" in one page and to use a button that says "find" on another page when they both serve the identical function.

Failure Example 2:

An online authoring tool that uses a button with "Save page" on one page and "Save" on another page, in both cases for the same function.

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. In a set of Web pages, find components with the same function that are repeated in multiple Web pages.

  2. For each component with the same function found in step #1, check that the naming is consistent.

Expected Results

If step #2 is false then this failure condition applies and content fails the Success Criterion.


F32: Failure of Success Criterion 1.3.2 due to using white space characters to control spacing within a word

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to describe how using white space characters, such as space, tab, line break, or carriage return, to format individual words visually can be a failure to present meaningful sequences properly. When blank characters are inserted to control letter spacing within a word, they may change the interpretation of the word or cause it not to be programmatically recognized as a single word.

Inserting white space characters into an initialism is not an example of this failure, since the white space does not change the interpretation of the initialism and may make it easier to understand.

The use of white space between words for visual formatting is not a failure, since it does not change the interpretation of the words.

Examples

Failure Example 1: Failure due to adding white space in the middle of a word

This example has white spaces within a word to space out the letters in a heading. Screen readers may read each letter individually instead of the word "Welcome."

Example Code:


<h1>W e l c o m e</h1>

&nbsp; can also be used to add white space, producing similar failures:

Example Code:


<h1>H&nbsp;E&nbsp;L&nbsp;L&nbsp;O</h1>

Failure Example 2: White space in the middle of a word changing its meaning

In Japanese, Han characters (Kanji) may have multiple readings that mean very different things. In this example, the word is read incorrectly because screen readers may not recognize these characters as a word because of the white space between the characters. The characters mean "Tokyo," but screen readers say "Higashi Kyo".

Example Code:


<h1>東 京</h1>

Failure Example 3: Using line break characters to format vertical text

In the row header cell of a data table containing Japanese text, authors often create vertical text by using line break characters. However screen readers are not able to read the words in vertical text correctly because the line breaks occur within the word. In the following example, "東京都"(Tokyo-to) will be read "Higashi Kyo Miyako".

Example Code:


<table>
<caption>表1. 都道府県別一覧表</caption>
<tr>
<td></td>
<th scope="col">(見出しセル 1.)</th>
<th scope="col">(見出しセル 2.)</th>
</tr>
<tr>
<th scope="row">東<br />京<br />都</th>
<td>(データセル 1.)</td>
<td>(データセル 2.)</td>
</tr>
・・・・・・
</table>

Resources

No resources available for this technique.

Tests

Procedure

For each word that appears to have non-standard spacing between characters:

  1. Check whether any words in the text of the content contain white space characters .

Expected Results

  • If step #1 is true, then this failure condition applies and the content fails this Success Criterion.


F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain text content

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to describe how using white space characters, such as space, tab, line break, or carriage return, to format columns of data in text content is a failure to use structure properly. Assistive technologies will interpret content in the reading order of the current language. Using white space characters to create multiple columns does not provide the information in a natural reading order. Thus, the assistive technology user will not be presented with the information in an understandable manner.

Plain text is not suitable for displaying multiple columns of text. Modify the content to present the data in a different layout. Alternatively, use a technology that provides structural elements to represent columnar data.

Examples

Failure Example 1

The following example incorrectly uses white space characters to format a paragraph into a two column format.

Example Code:


Web Content Accessibility Guidelines      including blindness and low vision, 
2.0 (WCAG 2.0) covers a wide range of     deafness and hearing loss, learning 
issues and recommendations for making     difficulties, cognitive limitations, limited 
Web content more accessible. This         movement, speech difficulties, and 
document contains principles,             others. Following these guidelines will 
guidelines, Success Criteria, benefits,   also make your Web content more 
and examples that define and explain      accessible to the vast majority of users, 
the requirements for making Web-based     including older users. It will also enable
information and applications accessible.  people to access Web content using 
"Accessible" means usable to a wide       many different devices - including a 
range of people with disabilities,        wide variety of assistive technologies.

If this table was to be interpreted and spoken by a screen reader it would speak the following lines:

  • Web Content Accessibility Guidelines including blindness and low vision,

  • 2.0 (WCAG 2.0) covers a wide range of deafness and hearing loss, learning

  • issues and recommendations for making difficulties, cognitive limitations, limited

  • Web content more accessible. This movement, speech difficulties, and

  • (additional lines eliminated for brevity)

If the text were reflowed, or changed from a fixed to a variable font, or increased in size until lines no longer fit on the page, similar interpretation issues would arise in the visual presentation.

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Examine the document for data or information presented in columnar format.

  2. Check whether the columns are created using white space characters to lay out the information.

Expected Results

  • If step #2 is true, then this failure condition applies and the content fails these Success Criteria.


F34: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to format tables in plain text content

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to describe how using white space characters, such as space, tab, line break, or carriage return, to format tables in text content is a failure to use structure properly. When tables are created in this manner there is no way to indicate that a cell is intended to be a header cell, no way to associate the table header cells with the table data cells, or to navigate directly to a particular cell in a table.

In addition, assistive technologies will interpret content in the reading order of the current language. Using white space to organize data in a visual table does not provide the information in a natural reading order in the source of the document. Thus, the assistive technology user will not be presented with the information in a logical reading order.

Plain text is not suitable for displaying complex information like tables because the structure of the table cannot be perceived. Rather than using visual formatting to represent tabular relations, tabular information would need to be presented using a different technology or presented linearly. (See Presenting tabular information in plain text)

Examples

Failure Example 1

The following example incorrectly uses white space to format a Menu as a visual table.

Example Code:


Menu
         Breakfast        Lunch           Dinner

Monday   2 fried eggs    tomato soup     garden salad
         bacon           hamburger       Fried Chicken
         toast           onion rings     green beans
                         Oatmeal cookie  mashed potatoes

Tuesday   Pancakes       vegetable soup  Caesar salad
          sausage        hot dogs        Spaghetti with meatballs
          orange juice   potato salad    Italian bread
                         brownie         ice cream

If this table was to be interpreted and spoken by a screen reader it would speak the following lines:

  • Menu

  • Breakfast Lunch Dinner

  • Monday 2 fried eggs tomato soup garden salad

  • bacon hamburger Fried Chicken

  • toast onion rings green beans

  • Oatmeal cookie mashed potatoes

This reading order does not make sense since there is no structure in the table for the assistive technology to identify it as a table. If the text were reflowed, or changed from a fixed to a variable font, or increased in size until lines no longer fit on the page, similar issues would arise in the visual presentation.

Resources

No resources available for this technique.

Tests

Procedure

  1. Examine the document for visually formatted tables.

  2. Check whether the tables are created using white space characters to layout the tabular data.

Expected Results

  • If step #2 is true, then this failure condition applies and the content fails these Success Criteria.


F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value

Applicability

HTML and XHTML

This failure relates to:

Description

Forms are frequently designed so that they submit automatically when the user has filled in all the fields, or when focus leaves the last field. There are two problems with this approach. First is that a disabled user who needs more context may move focus away from the field to the directions on how to fill in the form, or to other text, accidentally submitting the form. The other is that, with some form elements, the value of the field changes as each item is navigated with the keyboard, again accidentally submitting the form. It is better to rely on the standard form behavior of the submit button and enter key.

Examples

Failure Example 1:

This failure example submits a form when the user leaves the last field of a three-field telephone number form. The form will submit if the user leaves the field after editing it, even navigating backwards in the tab order. Developers should not use this method to submit a form, and should instead use a submit button, or rely on the form's default behavior of submitting when the user hits enter in a text field.

Example Code:

 
<form method="get" id="form1">
  <input type="text" name="text1" size="3" maxlength="3"> - 
  <input type="text" name="text2" size="3" maxlength="3"> - 
  <input type="text" name="text3" size="4" maxlength="4" onchange="form1.submit();">
</form> 

Failure Example 2:

This is a example that submits a form when the user selects an option from the menu when there is no warning of this behavior in advance. The form will submit as soon as an item from the menu is selected. A user using a keyboard will not be able to navigate past the first item in the menu. Blind users and users with hand tremors can easily make a mistake on which item on the dropdown menu to choose and they are taken to the wrong destination before they can correct it.

Example Code:

 
<form method="get" id="form2">
 <input type="text" name="text1">
  <select name="select1" onchange="form2.submit();">
    <option>one</option>
    <option>two</option>
    <option>three</option>
    <option>four</option>
  </select>
</form>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Enter data in all fields on page starting at top.

  2. Enter data in last field and exit from it (tab out of it).

  3. Check whether leaving the last field causes change of context.

Expected Results

  • If step #3 is true, then this failure condition applies and content fails the Success Criterion.


F37: Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the selection of a radio button, check box or select list is changed

Applicability

HTML and XHTML

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F37.

Description

This document describes a failure that occurs when changing the selection of a radio button, a check box or an item in a select list causes a new window to open. It is possible to use scripting to create an input element that causes a change of context (submit the form, open a new page, a new window) when the element is selected. Developers can instead use a submit button (see G80: Providing a submit button to initiate a change of context) or clearly indicate the expected action.

Examples

Failure Example 1:

The example below fails the Success Criterion because it processes the form when a radio button is selected instead of using a submit button.

Example Code:

  
<script type="text/JavaScript"> 
  function goToMirror(theInput) {
   var mirrorSite = "http://download." + theInput.value + "/"; 
   window.open(mirrorSite); 
  }
</script>
  …
<form name="mirror_form" id="mirror_form" action="" method="get">
       <p>Please select a mirror download site:</p> 
       <p> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_belnet" value="belnet.be" /> 
       <label for="mirror_belnet">belnet (<abbr>BE</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_surfnet" value="surfnet.nl" /> 
       <label for="mirror_surfnet">surfnet (<abbr>NL</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_puzzle" value="puzzle.ch" /> 
       <label for="mirror_puzzle">puzzle (<abbr>CH</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_voxel" value="voxel.com" /> 
       <label for="mirror_voxel">voxel (<abbr>US</abbr>)</label><br /> 
       </p> 
</form>

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Find each form in a page.

  2. For each form control that is a radio button, check box or an item in a select list, check if changing the selection of the control launches a new window.

  3. For each new window resulting from step 2, check if the user is warned in advance.

Expected Results

If step #3 is false, then this failure condition applies and content fails the Success Criterion.


F38: Failure of Success Criterion 1.1.1 due to not marking up decorative images in HTML in a way that allows assistive technology to ignore them

Applicability

HTML and XHTML

This failure relates to:

Description

This describes a failure condition for text alternatives for images that should be ignored by AT. If there is no alt attribute at all assistive technologies are not able to ignore the non-text content. The alt attribute must be provided and have a null value (i.e., alt="" ) to avoid a failure of this Success Criterion.

This describes a failure condition for text alternatives for images that should be ignored by assistive technology (AT). If an image has the attribute role="presentation", it will be ignored by AT. However, if it does not have role="presentation", and if there is no alt attribute at all assistive technologies are not able to ignore the image. For decorative images which need to be ignored by AT, either role="presentation" must be used or the alt attribute must be provided and have a null value (i.e., alt="") to avoid a failure of this Success Criterion.

Examples

  • Decorative images that have no alt attribute and no role attribute

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

For any img element that is used for purely decorative content:

  1. Check whether the element has no role attribute or has a role attribute value that is not "presentation".

  2. Check whether the element has no alt attribute or has an alt attribute with a value that is not null.

Expected Results

  • If step #1 is true and if step #2 is true, this failure condition applies and content fails the Success Criterion.


F39: Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive technology

Applicability

Applies to HTML and XHTML.

This failure relates to:

Description

This technique describes a failure condition for images that should be ignored by assistive technologies. A text alternative for an image should convey the meaning of the image. When an image is used for decoration, spacing or other purpose that is not part of the meaningful content in the page then the image has no meaning and should be ignored by assistive technologies.

Providing a null text alternative (i.e., alt="" ) will allow assistive technology to ignore the image and avoid a failure of this Success Criterion.

Examples

Failure Example 1: Decorative images that have no alt attribute

An image is used to create a blank space between content, where the spacing itself is not meaningful to the content. The image has an alt text value of "spacer". This image fails the Success Criterion because the text alternative does not serve an equivalent purpose. The image is meant to be ignored but its alternative text "spacer" is announced by screen readers and displayed in some alternate color schemes.

<div>Tree type: <img src="spacer.gif" width="100" height="1" alt="spacer"/>Cedrus deodara</div>

Resources

No resources available for this technique.

Tests

Procedure

  1. Identify any img elements that are used for decoration, spacing or other purpose that is not part of the meaningful content in the page

  2. Check that the alt attribute for these elements is null.

Expected Results

  • If step #2 is false, this failure condition applies and the content fails the Success Criterion.


F40: Failure of Success Criterion 2.2.1 and 2.2.4 due to using meta redirect with a time limit

Applicability

All pages

This failure relates to:

Description

meta http-equiv of {time-out}; url=... is often used to automatically redirect users. When this occurs after a time delay, it is an unexpected change of context that may interrupt the user.

It is acceptable to use the meta element to create a redirect when the time-out is set to zero, since the redirect is instant and will not be perceived as a change of context. However, it is preferable to use server-side methods to accomplish this. See SVR1: Implementing automatic redirects on the server side instead of on the client side (SERVER) .

Examples

Failure Example 1

The page below is a failure because it will redirect to the URI http://www.example.com/newpage after a time limit of 5 seconds.

Example Code:


<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
   <head>     
      <title>Do not use this!</title>     
      <meta http-equiv="refresh"
      content="5; url=http://www.example.com/newpage" />   
   </head>   
   <body>     
      <p>       
         If your browser supports Refresh, you'll be       
         transported to our        
         <a href="http://www.example.com/newpage">new site</a>        
         in 5 seconds, otherwise, select the link manually.     
      </p>   
   </body> 
</html>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. View a page.

  2. Check that the page does not redirect after a time-out.

Expected Results

  1. If check #2 is false, this failure condition applies and content fails the Success Criterion.


F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using meta refresh to reload the page

Applicability

HTML and XHTML

This failure relates to:

Description

meta http-equiv of refresh is often used to periodically refresh pages or to redirect users to another page. If the time interval is too short, and there is no way to turn auto-refresh off, people who are blind will not have enough time to make their screen readers read the page before the page refreshes unexpectedly and causes the screen reader to begin reading at the top. Sighted users may also be disoriented by the unexpected refresh.

Examples

Failure Example 1

This is a deprecated example that changes the user's page at regular intervals. Content developers should not use this technique to simulate "push" technology. Developers cannot predict how much time a user will require to read a page; premature refresh can disorient users. Content developers should avoid periodic refresh and allow users to choose when they want the latest information. (The number in the content attribute is the refresh interval in seconds.)

Example Code:


<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>     
    <title>HTML Techniques for WCAG 2.0</title>     
    <meta http-equiv="refresh" content="60" />   
  </head>   
  <body>
    ...     
  </body> 
</html>

(none currently listed)

Tests

Procedure

  1. Find meta elements in the document.

  2. For each meta element, check if it contains the http-equiv attribute with value "refresh" (case-insensitive) and the content attribute with a number (representing seconds) equals to or greater than 0 and without "; url=" (case-insensitive).

  3. check to see if there is a mechanism to turn off the refresh.

Expected Results

  • If step 2 is true and step 3 is false then this failure condition applies and content fails these Success Criteria.


F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links

Applicability

HTML and XHTML

This failure relates to:

Description

This failure occurs when JavaScript event handlers are attached to elements to emulate links. A link created in this manner cannot be tabbed to from the keyboard and does not gain keyboard focus like other controls and/or links. If scripting events are used to emulate links, user agents including assistive technology may not be able to identify the links in the content as links. They may be recognized as interactive controls but still not recognized as links. Such elements do not appear in the links list generated by user agents or assistive technology.

It is possible to use the ARIA role attribute to identify an anonymous element as link control for assistive technologies. However, best practice for ARIA calls for making use of native elements whenever possible, so the use of the role attribute to identify anonymous elements as links is not recommended.

The a and area elements are intended to mark up links.

Examples

Failure Example 1: Scripting a span element

Scripted event handling is added to a span element so that it functions as a link when clicked with a mouse. Assistive technology does not recognize this element as a link.

Example Code:


<span onclick="location.href='newpage.html'">
    Fake link
</span>

Failure Example 2: Scripting an img element

Scripted event handling is added to an img element so that it functions as a link when clicked with a mouse. Assistive technology does not recognize this element as a link.

Example Code:


   <img src="go.gif" 
   alt="go to the new page" 
   onclick="location.href='newpage.html'">

Failure Example 3: Scripting an img element, with keyboard support

Scripted event handling is added to an img element so that it functions as a link. In this example, the link functionality can be invoked with the mouse or via the Enter key if the user agent includes the element in the tab chain. Nevertheless, the element will not be recognized as a link.

Example Code:


function doNav(url)
{
   window.location.href = url;
}

function doKeyPress(url)
{
   //if the enter key was pressed
   if (window.event.type == "keypress" &&
       window.event.keyCode == 13)
   {
      doNav(url);
   }
}

The markup for the image is:

Example Code:


<p>
	<img src="bargain.jpg"
		tabindex="0" 
		alt="View Bargains"
		onclick="doNav('viewbargains.html');"
		onkeypress="doKeyPress('viewbargains.html');">
</p>

Failure Example 4: Scripting a div element

This example uses script to make a div element behave like a link. Although the author has provided complete keyboard access and separated the event handlers from the markup to enable repurposing of the content, the div element will not be recognized as a link by assistive technology.

Example Code:


window.onload = init;

function init()
{
	var objAnchor = document.getElementById('linklike');

	objAnchor.onclick = function(event){return changeLocation(event,
'surveyresults.html');};
	objAnchor.onkeypress = function(event){return changeLocation(event,
'surveyresults.html');};
}

function changeLocation(objEvent, strLocation)
{
	var iKeyCode;

	if (objEvent && objEvent.type == 'keypress')
	{
		if (objEvent.keyCode)
			iKeyCode = objEvent.keyCode;
		else if (objEvent.which)
			iKeyCode = objEvent.which;

		if (iKeyCode != 13 && iKeyCode != 32)
			return true;
	}

	window.location.href = strLocation;
}

The markup for the div element is:

Example Code:


<div id="linklike">
View the results of the survey.
</div>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

For all elements presented as links which use JavaScript event handlers to make the element emulate a link:

  1. Check if the programmatically determined role of the element is link.

  2. Check if the emulated link can be activated using the keyboard.

Expected Results

  • If check #1 is false then this failure condition applies and the content fails Success Criteria 1.3.1 and 4.1.2. If check #2 is false then this failure condition applies and the content fails Success Criteria 2.1.1 and 2.1.3.


F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content

Applicability

HTML and XHTML

This failure relates to:

Description

The objective of this technique is to describe a failure that occurs when structural markup is used to achieve a presentational effect, but indicates relationships that do not exist in the content. This is disorienting to users who are depending on those relationships to navigate the content or to understand the relationship of one piece of the content to another. Note that the use of HTML tables for layout is not an example of this failure as long as the layout table does not include improper structural markup such as <th> or <caption> elements.

Note: Though an element's semantic meaning is generally exposed to AT, the WAI-ARIA presentation role can be used to suppress the native semantics of an element so that they are not mapped to the accessibility API. Setting an element's role to presentation may avoid this failure by hiding that element's semantics from the user.

Examples

Failure Example 1: A heading used only for visual effect

In this example, a heading element is used to display an address in a large, bold font. The address does not identify a new section of the document, however, so it should not be marked as a heading.

Example Code:


<p>Interested in learning more? Write to us at</p> 
<h4>3333 Third Avenue, Suite 300 · New York City</h4>

<p>And we'll send you the complete informational packet absolutely Free!</p>

Failure Example 2: Using heading elements for presentational effect

In this example, heading markup is used in two different ways: to convey document structure and to create visual effects. The h1 and h2 elements are used appropriately to mark the beginning of the document as a whole and the beginning of the abstract. However, the h3 and h4 elements between the title and the abstract are used only for visual effect — to control the fonts used to display the authors' names and the date.

Example Code:


<h1>Study on the Use of Heading  Elements in Web Pages</h1>
<h3>Joe Jones and Mary Smith<h3>
<h4>March 14, 2006</h4>
<h2>Abstract</h2>
<p>A study was conducted in early 2006 ...
</p>

Failure Example 3: Using blockquote elements to provide additional indentation

The following example uses blockquote for text that is not a quotation to give it prominence by indenting it when displayed in graphical browsers.

Example Code:


<p>After extensive study of the company Web site, the task force 
identified the following common problem.</p>

<blockquote>
<p>The use of markup for presentational effects made Web 
pages confusing to screen reader users.</p>
</blockquote>

<p>The committee lists particular examples of the problems 
introduced by this practice below.</p>

Failure Example 4: Using the fieldset and legend elements to give a border to text

Example Code:


<fieldset>
<legend>Bargain Corner</legend>
<p>Buy today, and save 20%</p>
</fieldset>

Resources

No resources available for this technique.

Tests

Procedure

  1. Check that the element's semantic meaning is exposed to assistive technology and appropriate for the content of the element.

Expected Results

  • If check #1 is false then this failure condition applies.


F44: Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that does not preserve meaning and operability

Applicability

HTML and XHTML

This failure relates to:

Description

This document describes a failure that occurs when the tab order does not follow logical relationships and sequences in the content.

Focusable elements like links and form elements have a tabindex attribute. The elements receive focus in ascending order of the value of the tabindex attribute. When the values of the tabindex attribute are assigned in a different order than the relationships and sequences in the content, the tab order no longer follows the relationships and sequences in the content.

One of the most common causes of this failure occurs when editing a page where tabindex has been used. It is easy for the tab order and the content order to fall out of correspondence when the content is edited but the tabindex attributes are not updated to reflect the changes to the content.

Examples

Failure Example 1

The following example incorrectly uses tabindex to specify an alternative tab order:

Example Code:


<ol>
   <li><a href="main.html" tabindex="1">Homepage</a></li>
   <li><a href="chapter1.html" tabindex="4">Chapter 1</a></li>
   <li><a href="chapter2.html" tabindex="3">Chapter 2</a></li>
   <li><a href="chapter3.html" tabindex="2">Chapter 3</a></li>
</ol>

If this list is navigated by the tab key, the list is navigated in the order Homepage, chapter 3, chapter 2, chapter 1, which does not follow the sequence in the content.

Failure Example 2

The tab order has been set explicitly in a Web page by providing tabindex attributes for all fields. Later, the page is modified to add a new field in the middle of the page, but the author forgets to add a tabindex attribute to the new field. As a result, the new field is at the end of the tab order.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. If tabindex is used, check that the tab order specified by the tabindex attributes follows relationships in the content.

Expected Results

  • If check #1 is false, then this failure condition applies and content fails the Success Criterion.


F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables

Applicability

HTML and XHTML

This failure relates to:

Description

The objective of this technique is to describe a failure that occurs when a table used only for layout includes either th elements, a summary attribute, or a caption element. This is a failure because it uses structural (or semantic) markup only for presentation. The intent of the HTML and XHTML table elements is to present data.

Although not commonly used in a layout table, the following structural markup would also be failures of Success Criterion 1.3.1 if used in a layout table:

  • headers attributes

  • scope attributes

Assistive technologies use the structure of an HTML or XHTML table to present data to the user in a logical manner. The th element is used to mark the column and row headers of the table. A screen reader uses the information in th elements to speak the header information that changes as the user navigates the table. The summary attribute on the table element provides a textual description of the table that describes its purpose and function. Assistive technologies make the summary attribute information available to users. The caption element is part of the table and identifies the table.

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. When a table is used for layout purposes the th element should not be used. Since the table is not presenting data there is no need to mark any cells as column or row headers. Likewise, there is no need for an additional description of a table which is only used to layout content. Do not include a summary attribute and do not use the summary attribute to describe the table as, for instance, "layout table". When spoken, this information does not provide value and will only distract users navigating the content via a screen reader. Empty summary attributes are acceptable on layout tables, but not recommended.

Examples

Failure Example 1

Here is a simple example that uses a table to layout content in a three column format. The navigation bar is in the left column, the main content in the middle column, and an additional sidebar is on the right. At the top is a page title. The example marks the page title as <th>, and provides a summary attribute indicating that the table is a layout table.

Example Code:


 <table summary="layout table">
 <tr>
   <th colspan=3>Page Title</th>
 </tr>
 <tr>
   <td><div>navigation content</div></td>
   <td><div>main content</div></td>
   <td><div>right sidebar content</div></td>
 </tr>
 <tr>
   <td colspan=3>footer</td>
 </tr>
 </table>

Resources

No resources available for this technique.

Tests

Procedure

  1. Examine the source code of the HTML or XHTML document for the table element

  2. If the table is used only to visually lay out elements within the content

    1. Check that the table does not contain any th elements.

    2. Check that the table element does not contain a non-empty summary attribute.

    3. Check that the table element does not contain a caption element.

Expected Results

  • If any check above is false, then this failure condition applies and the content fails the Success Criterion.


F47: Failure of Success Criterion 2.2.2 due to using the blink element

Applicability

HTML and XHTML

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F47.

Description

The blink element, while not part of the official HTML or XHTML specification, is supported by many user agents. It causes any text inside the element to blink at a predetermined rate. This cannot be interrupted by the user, nor can it be disabled as a preference. The blinking continues as long as the page is displayed. Therefore, content that uses blink fails the Success Criterion because blinking can continue for more than three seconds.

Examples

Failure Example 1

A product list page uses the blink element to draw attention to sale prices. This fails the Success Criterion because users cannot control the blink.

Example Code:


<p>My Great Product <blink>Sale! $44,995!</blink></p>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Examine code for the presence of the blink element.

Expected Results

  • If #1 is true, the content fails the Success Criterion.


F48: Failure of Success Criterion 1.3.1 due to using the pre element to markup tabular information

Applicability

HTML and XHTML

This failure relates to:

Description

This document describes a failure caused by use of the HTML pre element to markup tabular information. The pre element preserves only visual formatting. If the pre element is used to markup tabular information, the visually implied logical relationships between the table cells and the headers are lost if the user cannot see the screen or if the visual presentation changes significantly.

Instead, the HTML table element is intended to present tabular data. Assistive technologies use the structure of an HTML table to present data to the user in a logical manner. This structure is not available when using the pre element.

Examples

Failure Example 1: A schedule formatted with tabs between columns

Example Code:


 <pre>
 	Monday	Tuesday	Wednesday	Thursday	Friday
 8:00-
 9:00	Meet with Sam				
 9:00-
 10:00			Dr. Williams	Sam again	Leave for San Antonio
 </pre>

Failure Example 2: Election results displayed using preformatted text

Example Code:


 <pre>
   CIRCUIT COURT JUDGE BRANCH 3
                                                  W
                                                   R
                                          M R E     I
                                           A . L     T
                                     M L    R   B     E
                                      I A    Y   E     -
                                       K N        R     I
                                        E G        T     N
                                       -----   -----   -----
0001 TOWN OF ALBION WDS 1-2               22      99       0
0002 TOWN OF BERRY WDS 1-2                52     178       0
0003 TOWN OF BLACK EARTH                  16      49       0
0004 TOWN OF BLOOMING GROVE WDS 1-3       44     125       0
0005 TOWN OF BLUE MOUNDS                  33     117       0
0006 TOWN OF BRISTOL WDS 1-3             139     639       1
0007 TOWN OF BURKE WDS 1-4                80     300       0
0008 TOWN OF CHRISTIANA WDS 1-2           22      50       0

 </pre>

Resources

No resources available for this technique.

Tests

Procedure

  1. Check to see if the pre element is used

  2. For each occurrence of the pre element, check whether the enclosed information is tabular.

Expected Results

  • If check #2 is true, then this failure condition applies and the content fails the Success Criterion.


F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized

Applicability

HTML and XHTML

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F49.

Description

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. If a layout table is used, however, it is important that the content make sense when linearized.

This failure occurs when a meaningful sequence of content conveyed through presentation is lost because HTML tables used to control the visual placement of the content do not “linearize" correctly. Tables present content in two visual dimensions, horizontal and vertical. However, screen readers present this two-dimensional content in linear order of the content in the source, beginning with the first cell in the first row and ending with the last cell in the last row. The screen reader reads the table from top to bottom, reading the entire contents of each row before moving to the next row. The complete content of each cell in each row is spoken—including the complete content of any table nested within a cell. This is called linearization.

Suppose that a Web page is laid out using a table with 9 columns and 22 rows. The screen reader speaks the content of the cell at Column 1, Row 1 followed by the cells in columns 2, 3, 4 and so on to column 9. However, if any cell contains a nested table, the screen reader will read the entire nested table before it reads the next cell in the original (outer) table. For example, if the cell at column 3, row 6 contains a table with 6 columns and 5 rows, all of those cells will be read before Column 4, Row 6 of the original (outer) table. As a result, the meaningful sequence conveyed through visual presentation may not be perceivable when the content is spoken by a screen reader.

Examples

Failure Example 1: A layout table that does not linearize correctly

An advertisement makes clever use of visual positioning, but changes meaning when linearized.

Example Code:


<table>
<tr>
  <td ><img src="logo.gif" alt="XYZ mountaineering"></td>
  <td rowspan="2" valign="bottom">top!</td>
</tr>
<tr>
  <td>XYZ gets you to the</td>
</tr>
</table>

The reading order from this example would be:

  • XYZ mountaineering top!

  • XYZ gets you to the

Failure Example 2: A layout table that separates a meaningful sequence when linearized

A Web page from a museum exhibition positions a navigation bar containing a long list of links on the left side of the page. To the right of the navigation bar is an image of one of the pictures from the exhibition. To the right of the image is the kind of "placard" text you'd see on the wall next to the object if you were at the museum. Below that text is a heading that says "Description," and below that heading is a description of the image. The image, placard text, Description heading, and text of the description form a meaningful sequence.

A layout table is used to position the elements of the page. The links in the navigation bar are split into different cells in the leftmost column.

Example Code:


<table>
<tr>
	<td><a href="#">Link 1</a></td>
	<td rowspan="20"><img src="img.png" alt="Museum Picture"></td>
	<td rowspan="6"><img src="placard.png" alt="Placard text"></td> 
</tr> 
<tr>
	<td><a href="#">Link 2</a></td>
</tr>
<tr>
	<td><a href="#">Link 3</a></td>
</tr>
<tr>
	<td><a href="#">Link 4</a></td>
</tr>
<tr>
	<td><a href="#">Link 5</a></td>
</tr>
<tr>
	<td><a href="#">Link 6</a></td>
</tr>
<tr>
	<td><a href="#">Link 7</a></td>
	<td rowspan="2"><h2>Image Heading</h2></td> 
</tr> 
<tr>
	<td><a href="#">Link 8</a></td>
</tr>
<tr>
	<td><a href="#">Link 9</a></td>
	<td rowspan="12">Description of the image</td> 
</tr> 
<tr>
	<td><a href="#">Link 10</a></td>
</tr>
 ...
<tr>
	<td><a href="#">Link 20</a></td>
</tr>
</table>

The reading order from this example would be:

  • Link 1

  • Image

  • Placard Text

  • Link 2

  • Link 3

  • Link 4

  • Link 5

  • Link 6

  • Link 7

  • Image Heading

  • Link 8

  • Link 9

  • Link 10

  • ...

  • Link 20

Because the navigation bar links are interleaved with the content describing the image, screen readers cannot present the content in a meaningful sequence corresponding to the sequence presented visually.

Resources

No resources available for this technique.

Tests

Procedure

  1. Linearize the content in either of the following ways:

    • Present the content in source code order

    • Remove the table markup from around the content

  2. Check that the linear reading order matches any meaningful sequence conveyed through presentation.

Expected Results

  • If check #2 is false, then this failure condition applies and the content fails this Success Criterion.


F50: Failure of Success Criterion 2.2.2 due to a script that causes a blink effect without a mechanism to stop the blinking at 5 seconds or less

Applicability

Technologies that support script-controlled blinking of content.

This failure relates to:

Description

Scripts can be used to blink content by toggling the content's visibility on and off at regular intervals. It is a failure for the script not to include a mechanism to stop the blinking at 5 seconds or earlier. See SCR22: Using scripts to control blinking and stop it in five seconds or less (Scripting) for information about how to modify the technique to stop the blinking.

Examples

Failure Example 1

The following example uses script to blink content, but the blink continues indefinitely rather than stopping after five seconds.

Example Code:


...
<script type="text/javascript">
<!--
// blink "on" state
function show()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "visible";
	settime-out("hide()", 450);
}
// blink "off" state
function hide()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "hidden";
	settime-out("show()", 450);
}
// kick it off
show();
//-->
</script>
...
<span id="blink1">This content will blink</span>

Tests

Procedure

For each instance of blinking content:

  1. Determine if the blinking stops in 5 seconds or less.

Expected Results

If #1 is false, then the content fails the Success Criterion.


F52: Failure of Success Criterion 3.2.1 and 3.2.5 due to opening a new window as soon as a new page is loaded

Applicability

Applies when scripting is used to open new windows.

This failure relates to:

Description

Some Web sites open a new window when a page is loaded, to advertise a product or service. The objective of this technique is to ensure that pages do not disorient users by opening up one or more new windows that automatically attain focus as soon as a page is loaded.

Examples

Note: There are multiple methods by which this failure may be triggered. Two common examples that are supported differently in various versions of user agents are listed as examples below.

Failure Example 1:

The following example is commonly used in HTML 4.01 to open new windows when pages are loaded.

Example Code:


window.onload = showAdvertisement;
 function showAdvertisement()
 {
  window.open('advert.html', '_blank', 'height=200,width=150');
 }

Failure Example 2:

The following example commonly used in XHTML to open new windows when pages are loaded.

Example Code:


if (window.addEventListener) { 
    window.addEventListener("load", showAdvertisement, true);
}
if (window.attachEvent) {
    window.attachEvent("onload", showAdvertisement);
}
function showAdvertisement()
{
window.open('noscript.html', '_blank', 'height=200,width=150');
}

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. load a new page

  2. check to see whether a new window has been opened as a result of loading the new page

  3. Check to see whether the new window is automatically given focus

Expected Results

  • If step 2 and step 3 are true, then this failure condition applies and content fails the Success Criterion.


F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function

Applicability

Technologies that have event handlers specific to pointing devices.

User Agent and Assistive Technology Support Notes

  • None listed.

This failure relates to:

Description

When pointing device-specific event handlers are the only mechanism available to invoke a function of the content, users with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as users who must use alternate keyboards or input devices that act as keyboard emulators will be unable to access the function of the content.

Examples

Failure Example 1

The following example is of an image that responds to a mouse click to go to another page. This is a failure because the keyboard cannot be used to move to the next page. <p><img onmousedown="nextPage();" src="nextarrow.gif" alt="Go to next page"></p>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Check to see whether pointing-device-specific event handlers are the only means to invoke scripting functions.

Expected Results

  • If any are found, then this failure condition applies and content fails the Success Criterion.


F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received

Applicability

Applies to all content that supports script.

User Agent and Assistive Technology Support Notes

  • None listed.

This failure relates to:

Description

Content that normally receives focus when the content is accessed by keyboard may have this focus removed by scripting. This is sometimes done when designer considers the system focus indicator to be unsightly. However, the system focus indicator is an important part of accessibility for keyboard users. In addition, this practice removes focus from the content entirely, which means that the content can only be operated by a pointing device such as a mouse.

Examples

Failure Example 1

Example Code:

<input type="submit" onFocus="this.blur();"> 

Failure Example 2

Example Code:

<a onFocus="this.blur()" href="Page.html"><img src="myImage.gif"></a> 

Failure Example 3

Example Code:

<a href="link.html" onfocus="if(this.blur)this.blur();">Link Phrase</a> 

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Use the keyboard to verify that you can get to all interactive elements using the keyboard.

  2. Check that when focus is placed on each element, focus remains there until user moves it.

Expected Results

  • If #2 is false then this failure condition applies and content fails the Success Criterion.


F58: Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically redirect pages after a time-out

Applicability

  • Any server-side scripting language

  • Content does not meet the exceptions in the Success Criterion for permitted time limits.

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F58.

Description

Server-side scripting languages allow developers to set the non-standard HTTP header "Refresh" with a time-out (in seconds) and a URI to which the browser is redirected after the specified time-out. If the time interval is too short, people who are blind will not have enough time to make their screen readers read the page before the page refreshes unexpectedly and causes the screen reader to begin reading at the top. Sighted users may also be disoriented by the unexpected refresh.

The HTTP header that is set is Refresh: {time in seconds}; url={URI of new location}. It is also possible to omit the URI and obtain a periodically refreshing page, which causes the same problem. The HTTP header that is set is Refresh: {time in seconds}.

Examples

Failure Example 1

The following example is a failure because a timed server-side redirect is implemented in Java Servlets or JavaServer Pages (JSP).

Example Code:


public void doGet (HttpServletRequest request, HttpServletResponse response)
      throws IOException, ServletException {
        response.setContentType("text/html");
	PrintWriter out = response.getWriter();
	response.setHeader("Refresh", "10; URL=TargetPage.html");
	out.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
	 \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">");
	out.println("<html><head><title>Redirect</title></head><body>");
	out.println("<p>This page will redirect you in 10 seconds.</p>");
	out.println("</body></html>");
  }

Failure Example 2

The following example is a failure because a timed server-side redirect is implemented in Active Server Pages (ASP) with VBScript.

Example Code:


 <% @Language = "VBScript" %>
 <% option explicit 
 Response.Clear
 Response.AddHeader "Refresh", "5; URL=TargetPage.htm"
 %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
 …
 <!--HTML code for content that is shown before the redirect is triggered-->
 

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. When a Web page is rendered, check to see if it automatically redirects to another page after some period of time without the user taking any action.

Expected Results

  • If such a redirect is found then this failure condition applies and content fails the Success Criterion.


F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control

Applicability

HTML and XHTML

This failure relates to:

Description

This failure demonstrates how using generic HTML elements to create user interface controls can make the controls inaccessible to assistive technology. Assistive technologies rely on knowledge of the role and current state of a component in order to provide that information to the user. Many HTML elements have well defined roles, such as links, buttons, text fields, etc. Generic elements such as div and span do not have any predefined roles. When these generic elements are used to create user interface controls in HTML the assistive technology may not have the necessary information to describe and interact with the control.

Attaching event handlers to elements that are not normally interactive, such as span and div, can be disorienting to users. Even if care is taken to provide keyboard access to such elements, users may have a difficult time discovering that there are interactive controls in the content or understanding what type of behavior to expect from them. For example, users may not know which keystrokes are supported by the script to activate the element. Additionally, these elements do not generate the same operating system events as interactive elements, so assistive technology may not be notified when the user activates them.

The W3C Candidate Recommendation "Accessible Rich Internet Applications (WAI-ARIA) 1.0" describes mechanisms to provide the necessary role and state information to create fully accessible user interface controls.

Examples

Failure Example 1

The following example fails because it creates a checkbox using a span and an image.


  <p> 
  <span  onclick="toggleCheckbox('chkbox')"> 
  <img src="unchecked.gif"  id="chkbox" alt=""> Include Signature 
  </span> 
  </p>

Here is the scripting code which changes the image source when the span is clicked with the mouse.

 
  var CHECKED = "check.gif"; 
  var UNCHECKED = "unchecked.gif"; 
  function toggleCheckbox(imgId) { 
  var theImg = document.getElementById(imgId); 
  if ( theImg.src.lastIndexOf(CHECKED)!= -1 ) { 
  theImg.src = UNCHECKED; 
  // additional code to implement unchecked action 
  } 
  else { 
  theImg.src = CHECKED; 
  // additional code to implement checked action 
  } 
  } 

A checkbox created in this manner will not work with assistive technology since there is no information that identifies it as a checkbox. In addition, this example is also not operable from the keyboard and would fail guideline 2.1.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Examine the parsed source code for elements which have event handlers assigned within the mark-up or via scripting (indicating that the element is a user interface control).

  2. Check if the role of the control is already defined natively in the mark-up language.

  3. Check if another valid method, such as the assignment of a fitting WAI-ARIA role, has been used to define the role of the control.

Expected Results

If check #2 AND check #3 are false, the failure condition applies.


F60: Failure of Success Criterion 3.2.5 due to launching a new window when a user enters text into an input field

Applicability

General

This failure relates to:

Description

This document describes a failure that occurs when a new window is created in response to a user filling in a text field for other than error reporting.

Examples

Failure Example 1:

This is a deprecated example showing a failure: A user is filling in his mailing address. When he fills in his postal code, a new window opens containing advertisements for services available in his city.

Failure Example 2:

This example is acceptable: A user is filling in his mailing address in a form. When he fills in the postal code field, a script runs to validate that it is a valid postal code. If the value is not valid, a window opens with instructions on how to fill in the field.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Find all text input form fields

  2. Change the value in each form field

  3. Check if new windows open

  4. For any new windows that open, check if they contain an error message and a button that closes the window returning focus to the initiating form element.

Expected Results

  • If #3 is true and #4 is false then failure condition applies and the content fails this Success Criterion.


F61: Failure of Success Criterion 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content

Applicability

General

This failure relates to:

Description

This document describes a failure that occurs when the content in the main viewport viewport is automatically updated, and there there is no option for a user to disable this behavior.

Two procedures are presented below to test for the existence of a failure against Success Criterion 3.2.5. Procedure 1 is the preferred procedure and assumes that content authors have access to the code that generates the viewport content.

However there may be instances where this may not be possible (eg: in certain content management systems, application environments such as django or ruby-on-rails, or content generated through scripting languages such as AJAX or PHP that are generated by third parties.) To that end, the second procedure is supplied to allow testing in these instances. Note that timeframes are indicative only, and that any change after any amount of time should be treated as a failure if the test otherwise does not pass the other step evaluations.

Examples

Failure Example 1:

A news site automatically refreshes itself to ensure that it has the newest headlines. There is no option to disable this behavior.

Failure Example 2:

A slideshow fills the entire viewport and advances to the next slide automatically. There is no stop button.

Failure Example 3:

A search engine automatically generates results and dynamically updates content based on user input. There is no option to disable this behavior.

Resources

Resources are for information purposes only, no endorsement implied.

(none currently listed)

Tests

Procedure

  1. Open the source code in an appropriate editing tool.

  2. Examine the source code thoroughly.

  3. Confirm that content is dynamically generated or the code will trigger a change of context for the viewport on an event or after a time period.

  4. Confirm that there does not exist an appropriate mechanism for users to disable this behavior.

Expected Results

  • If both checks 3 and 4 are true, then this failure condition applies and the content fails this Success Criterion

Tests

Procedure

  1. Measure or estimate the amount of time that the average user spends on the page.

  2. Go to the page

  3. Wait for 10 times the length of time the average user stays on the page. (From Step 1)

  4. Check to see if there is a change in context during this time.

  5. If there is no change of context STOP.

  6. If there is a change in context, then check to see if there is any mechanism on the page that would have prevented that change of context.

  7. If there IS a mechanism for preventing that change of context, use that mechanism to prevent that change of context and run the test over.

  8. If there is a change of context and there are no mechanism to prevent that change in context then you have a failure.

Note 1: One way to measure or estimate the amount of time in step 1 would be to check a web site's analytics to see how long the average user looks at the page.

Note 2: An example of step 6 would be a mechanism for turning off auto updates.

Expected Results

  • If you reach step 8 then the content fails this success criterion.


F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that is not related to the link

Applicability

HTML and XHTML

This failure relates to:

Description

This describes a failure condition when the context needed for understanding the purpose of a link is located in content that is not programmatically determined link context. If the context for the link is not provided in one of the following ways:

  • in the same sentence, paragraph, list item, or table cell as the link

  • in the preceding heading

  • via a suitable ARIA property such as aria-label or aria-labelledby

then the user will not be able to find out where the link is going with any ease. If the user must leave the link to search for the context, the context is not programmatically determined link context and this failure condition occurs.

Examples

Failure Example 1: A Link in an Adjacent Paragraph

A news service lists the first few sentences of an article in a paragraph. The next paragraph contains the link "Read More...". Because the link is not in the same paragraph as the lead sentence, the user cannot easily discover what the link will let the user read more about.


<p>A British businessman has racked up 2 million flyer miles and plans to 
travel on the world's first commercial tourism flights to space.</p>

<p><a href="ff.html">Read More...</a></p>

Failure Example 2: A Link in an Adjacent Cell Within a Layout Table

An audio site provides links to where its player can be downloaded. The information about what would be downloaded by the link is in the preceding row of the layout table, which is not programmatically determined context for the link.


 <table>
   <tr> 
       <td>Play music from your browser</td>
   </tr>
   <tr>
       <td>
       <a href="http://www.example.com/download.htm">
       <img src="download.jpg" width="165" height="32" alt="Download now"></a>
       </td>
   </tr>
 </table>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

Locate links where some additional link context is needed to understand the purpose of the link. For each link:

  1. Check whether the context is contained in the same sentence, paragraph, list item, table cell, associated table headers, or preceding heading.

  2. Check whether the link context can be programmatically determined in some other way, for example, by using a WAI-ARIA property such as aria-label, aria-labelledby or aria-describedby on the link to provide sufficient context

Expected Results

  • If check #1 AND check #2 are false, the content fails the Success Criterion.


F65: Failure of Success Criterion 1.1.1 due to omitting the alt attribute or text alternative on img elements, area elements, and input elements of type "image"

Applicability

HTML and XHTML

This failure relates to:

Description

This describes a failure condition for text alternatives on images. If there is no source of text to provide an alternative for the image then assistive technologies are not able to identify the image or to convey its purpose to the user. The alt attribute continues to be the preferred way to provide alternative text for images. Appropriate WAI-ARIA attributes may be used to provide alternative text, as long as they are accessibility supported. For more information about accessibility support, see Documenting Accessibility Support. The Accessible Rich Internet Applications (WAI-ARIA) 1.0 Specification describes the Text Alternative Computation, for computing the text alternative from the HTML and WAI-ARIA attributes of an element.

Some Assistive Technologies attempt to compensate for the missing text alternatives by reading the file name of the image. But it is insufficient to rely simply on the file name for many reasons. For example, file names may not be descriptive (e.g., images/nav01.gif), and technology specifications do not require descriptive file names. And some Assistive Technologies do not read the file name if there is no text alternative provided via HTML attributes.

Examples

Failure Example 1: Missing text alternative

In the code example below, the person using a screen reader would not know the purpose of the image.

Example Code:


<img src="../images/animal.jpg" />

Resources

Tests

Procedure

Identify img, area and input elements of type "image". For each of these elements:

  1. Check if the alt attribute is present.

  2. Check if aria-labelledby attribute is present AND references one or more id elements in the page AND check if aria-labelledby is accessibility supported.

  3. Check if the aria-label attribute is present AND check if aria-label is accessibility supported.

  4. Check if the title attribute is present AND check if title is accessibility supported.

Expected Results

  • If all of #1, #2, #3 and #4 are false then this failure condition applies.


F66: Failure of Success Criterion 3.2.3 due to presenting navigation links in a different relative order on different pages

Applicability

Applies to all technologies

This failure relates to:

Description

This describes a failure condition for all techniques involving navigation mechanisms that are repeated on multiple Web pages within a set of Web pages (Success Criterion 3.2.3). If the mechanism presents the order of links in a different order on two or more pages, then the failure is triggered.

Examples

Failure Example 1: An XHTML menu presenting a series of links that are in a different relative order on two different pages

Examples of a navigation mechanism that presents links in a different order.

Page 1 Menu

Example Code:


<div id="menu"> 
    <a href="Brazil.htm">Brazil</a><br />
    <a href="Canada.htm">Canada</a><br />
    <a href="Germany.htm">Germany</a><br />
    <a href="Poland.htm">Poland</a> 
</div>

Page 2 Menu

Example Code:


<div id="menu"> 
    <a href="Canada.htm">Canada</a><br />
    <a href="Brazil.htm">Brazil</a><br />
    <a href="Germany.htm">Germany</a><br />
    <a href="Poland.htm">Poland</a> 
</div>

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Check to see if a navigation mechanism is being used on more than one Web page.

  2. Check the default presentation of the navigation mechanism on each page to see if the list of links are in the same relative order on each Web page.

Note: "Same relative order" means that secondary navigation items may be in between the link items on some pages. They can be present without affecting the outcome of this test.

Expected Results

  • If #1 is true and #2 is false, then this failure condition applies and content fails the Success Criterion.


F67: Failure of Success Criterion 1.1.1 and 1.2.1 due to providing long descriptions for non-text content that does not serve the same purpose or does not present the same information

Applicability

All technologies.

This failure relates to:

Description

The objective of this technique is to describe the failure that occurs when the long description for non-text content does not serve the same purpose or does not present the same information as the non-text content. This can cause problems for people who cannot interpret the non-text content because they rely on the long description to provide the necessary information conveyed by the non-text content. Without a long description that provides complete information, a person may not be able to comprehend or interact with the Web page.

Examples

  • An image showing the locations of venues for events at the Olympic Games displayed on a street map. The image also contains an icon for each type of sporting event held at each venue. The long description states, "Map showing the location of each Olympic venue. Skating, hockey and curling are held at the Winter Park Ice Arena, Downhill skiing and jumping are held at Snow Mountain, Gymnastics is held at the JumpUp Arena, Cross Country Skiing is held at the Kilometer Forest". While this description provides useful information, it does not convey the same information as the image because it provides no specific location information such as the address or the distance of each location from some fixed point. Note that long descriptions do not always need to be in prose form; sometimes the information may best be presented in a table or other alternate format.

Resources

No resources available for this technique.

Tests

Procedure

For all non-text content that requires a long description

  1. Check that the long description serves the same purpose or presents the same information as the non-text content.

Expected Results

  • If step #1 is false, then this failure condition applies and the content fails this Success Criterion.


F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name

Applicability

HTML controls

This failure relates to:

Description

This failure describes a problem that occurs when a form control does not have a name exposed to assistive technologies. The result is that some users will not be able to identify the purpose of the form control. The name can be provided in multiple ways, including the label element. Other options include use of the title attribute and aria-label which are used to directly provide text that is used for the accessibility name or aria-labelledby which indicates an association with other text on a page that is providing the name. Button controls can have a name assigned in other ways, as indicated below, but in certain situations may require use of label, title, aria-label, or aria-labelledby.

Note 1: Elements that can use an explicitly-associated label element are:

  • input

  • textarea

  • select

Note 2: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button):

  • Submit and Reset buttons (input type="submit" or input type="reset")

  • Image buttons (input type="image")

  • Hidden input fields (input type="hidden")

  • Buttons (button elements or <input type="button">)

Examples

Failure Example 1:

The following example demonstrates a form that visually presents labels for form controls, but does not use the label element to associate them with their controls. The code example below is a failure because assistive technology may not be able to determine which label goes with which control.


<form>
 First name: 
 <input type="text" name="firstname">
 <br>
 Last name: 
 <input type="text" name="lastname">
 <br>
 I have a dog <input type="checkbox" name="pet" value="dog">
 I have a cat <input type="checkbox" name="pet" value="cat">
</form>

Failure Example 2:

In the following code example, label elements are present, but they are not programmatically linked to the corresponding input controls and may therefore not be properly determined by assistive technology.


<form action="..." method="post"> 
<p> 
<label>First Name</label>
<input type="text" name="firstname"> 
<label>Last Name</label> 
<input type="text" name="lastname"> 
</p> 
</form>

Failure Example 3:

The search text box in the following code example does not have a programmatically determinable name. The name can be supplied with any of the approaches mentioned above.


<input type="text" value="Type your search here"><input type="submit" type="submit" value="Search">

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

For all input, textarea and select elements in the Web page (except inputs of type "hidden", "submit", "reset", or "button":

  1. Check that each element has a programmatically determined name using one of the following ways:

    1. the text label or labels are programmatically associated with the control element via the aria-labelledby attribute (each id given as a value in the aria-labelledby attribute matches the id of the text label element).

    2. the control is programmatically determined through the value of its aria-label attribute.

    3. the text label is contained in a label element that is correctly associated to the respective input element via the label's for attribute (the id given as value in the for attribute matches the id of the input element).

    4. the control is contained within a label element that also contains the label text.

    5. the control is an input of type "image" and the alt attribute provides a text label.

    6. the control is programmatically determined through the value of title attribute.

Expected Results

  • If all options of check #1 are false, then this failure condition applies and the content fails the Success Criteria.


F69: Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured

Applicability

HTML, XHTML and CSS

This failure relates to:

Description

The objective of this failure condition is to describe a problem that occurs when changing the size of text causes text to be clipped, truncated, or obscured, so that it is no longer available to the user. In general, this failure occurs when there is no way for a user agent's layout engine to honor all the layout hints in the HTML at the new font size. Some of the ways in which this can occur include:

  • Setting the overflow property of the enclosing element to hidden

  • Using absolutely positioned content

  • Creating popups that aren't big enough for their content at the new font size

Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.

Examples

Failure Example 1:

The font size is set in a scalable way, but the container is set to a fixed pixel size. A gray border shows the boundaries of the text container. When the text is resized, it spills out of its container, and obsures the next paragraph.

Example Code:


<div style="font-size:100%; width:120px; height:100px; border: thin solid gray;"> 
  Now is the time for all good men to come to the aid of their country. 
</div>
<p>Now is the time for all good men to come to the aid of their country.</p>

Illustration of example 1:

Example showing text that spills outside of its container, obscuring other text on the page.

Failure Example 2:

This example is identical to the last one, except that the container is set to clip the text. The text is no longer bleeding into the next paragraph, but now it is truncated. This is also a failure.

Example Code:


<div style="font-size:100%; width:120px; height:100px; overflow: hidden; border: thin solid gray;">
 Now is the time for all good men to come to the aid of their country. 
</div>
<p>Now is the time for all good men to come to the aid of their country.</p>

Illustration of example 2:

Example showing text that truncated due to resized text.

(none currently listed)

Tests

Procedure

Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.

  1. Increase the text size of the content by 200%.

  2. Check that no text is clipped, truncated, or obscured.

Expected Results

  • If check #2 is false, then the failure condition applies and the content fails these Success Criteria.


F70: Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute markup

Applicability

Markup languages: HTML, XHTML, and other SGML or XML-based technologies.

This failure relates to:

Description

The objective of this failure is to identify examples of markup errors in element tags that could cause assistive technology to be unable to generate a satisfactory model of the page. Different user agents may implement different heuristics to recover from errors, resulting in inconsistent presentations of the page between user agents.

Some common types of problems with start and end tags that lead to this failure condition (though this is not an exhaustive list):

  • Opening and closing tags that are missing the opening < and closing > brackets.

  • Closing tag missing the initial / to indicate it is a closing tag.

  • Attribute values that have an opening quote but not a closing quote. Attribute values must be either fully quoted or, in some markup languages, may be unquoted.

  • Lack of whitespace between attributes.

  • Unquoted attribute values that have whitespace in the value.

  • Failure to provide a closing element tag for elements that do not accept empty-element syntax.

Examples

Failure Example 1: Missing angle brackets in XHTML

The following code fails because the opening tag is missing an angle bracket, and the intended boundary of the tag is unclear.

Example Code:


<p This is a paragraph</p>

Failure Example 2: Missing slash on closing tag in XHTML

The following code fails because the closing tag is missing the slash, making it look like it is in fact another opening tag.

Example Code:


<p>This is a paragraph<p>

Failure Example 3: Unbalanced attribute quoting

The following code fails because the attribute value is missing the closing quote, which makes the boundary of the attribute-value pair unclear.

Example Code:


<input title="name type="text">

Failure Example 4: Lack of whitespace between attributes

The following code fails because the there is not whitespace between attributes, which makes the boundary between attribute-value pairs unclear.

Example Code:


<input title="name"type="text">

Failure Example 5: Unquoted attribute with whitespace value

The following code fails because an attribute value is not quoted and contains whitespace, which makes the boundary of the attribute-value pair unclear.

Example Code:


<input title=Enter name here type=text>

Failure Example 6: Missing end tags in XHTML

The following code fails because the closing tag of the first paragraph is missing, making it unclear whether the second paragraph is a child or sibling of the first.

Example Code:


<p>This is a paragraph
<p>This is another paragraph</p>

(none currently listed)

Tests

Procedure

  1. Check the source code of pages implemented in markup languages.

  2. Check whether any opening tags, closing tags or attributes are malformed.

Expected Results

  • If check #2 is true, then the failure condition applies and the content does not meet this Success Criterion.


F71: Failure of Success Criterion 1.1.1 due to using text look-alikes to represent text without providing a text alternative

Applicability

Any technology.

This failure relates to:

Description

The objective of this failure condition is to avoid substituting characters whose glyphs look similar to the intended character, for that intended character. The Unicode character set defines thousands of characters, covering dozens of writing systems. While the glyphs for some of these characters may look like the glyphs for other characters in visual presentation, they are not processed the same by text-to-speech tools.

For example, the characters U+0063 and U+03F2 both look like the letter "c", yet the first is from the Western alphabet and the second from the Greek alphabet and not used in Western languages. The characters U+0033 and U+04E0 both look like the number "3", yet the second is actually a letter from the Cyrillic alphabet.

Note: This failure also applies to the use of character entities. It is the incorrect character used because of its glyph representation that comprises a failure, not the mechanism by which that character is implemented.

Examples

Failure Example 1: Characters

The following word looks, in browsers with appropriate font support, like the English word "cook", yet is composed of the string U+03f2 U+043E U+03BF U+006B, only one of which is a letter from the Western alphabet. This word will not be processed meaningfully, and a text alternative is not provided.

Example Code:


ϲоοk

Failure Example 2: Character entities

The following example, like the one above, will look like the English word "cook" when rendered in browsers with appropriate font support. In this case, the characters are implemented with character entities, but the word will still not be processed meaningfully, and a text alternative is not provided.

Example Code:


&#x03F2;&#x043E;&#x03BF;&#x006B;

Working Example: "ϲоοk"

(none currently listed)

Tests

Procedure

  1. Check the characters or character entities used to represent text.

  2. If the characters used do not match the appropriate characters for the displayed glyphs in the human language of the content, then look-alike glyphs are being used.

Expected Results

  • If look-alike glyphs are used, and there is not a text alternative for any range of text that uses look-alike glyphs, then the content does not meet the Success Criterion.


F72: Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text alternative

Applicability

Any technology.

This failure relates to:

Description

The objective of this failure condition is to avoid the use of ASCII art when a text alternative is not provided. Although ASCII art is implemented as a character string, its meaning comes from the pattern of glyphs formed by a visual presentation of that string, not from the text itself. Therefore ASCII art is non-text content and requires a text alternative. Text alternatives, or links to them, should be placed near the ASCII art in order to be associated with it.

Examples

Failure Example 1: ASCII Art chart without a text alternative

The following ASCII art chart lacks a text alternative and therefore does not meet Success Criterion 1.1.1. Note this failure example does in fact cause this page to fail, but you may skip over the example.

Example Code:


<pre>
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Flash frequency (Hz)
</pre>

(none currently listed)

Tests

Procedure

  1. Access a page with ASCII art.

  2. For each instance of ASCII art, check that it has a text alternative.

Expected Results

  • If check #2 is false, then this failure condition applies and the content fails this Success Criterion.


F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision

Applicability

Any technology.

This failure relates to:

Description

The objective of this failure is to avoid situations in which people who cannot perceive color differences cannot identify links (when people with color vision can identify links). Link underlines or some other non-color visual distinction are required (when the links are discernible to those with color vision).

While some links may be visually evident from page design and context, such as navigational links, links within text are often visually understood only from their own display attributes. Removing the underline and leaving only the color difference for such links would be a failure because there would be no other visual indication (besides color) that it is a link.

Note 1: Red and Pink are the same color (hue) but they have different lightness (which is not color ). So red and pink would pass the requirement for "not distinguished by color (hue) alone" since they differ by lightness (which is not color) - as long as the difference in lightness (contrast) is 3:1 or greater. (e.g. if surrounding text is RED and the link is PINK it would pass. Similarly a light green and a dark red differ BOTH by color AND by lightness so they would pass if the contrast (lightness) difference is 3:1 or greater) before focus or pointing. )

Note 2: There is no requirement that links be identifiable by people who cannot perceive color if they are not perceivable for those with color vision. (e.g. if the links are hidden for everyone – as in a game or test).

Note 3: If the non-color cue only happens when the mouse hovers over the link or when the link receives focus, it is still a failure.

Note 4: If the link is a different color and bold it would not fail because the boldness is not color dependent.

Examples

Failure Example 1:

A Web page includes a large number of links within the body text. The links are styled so that they do not have underlines and are very similar in color to the body text. This would be a failure because users would be unable to differentiate the links from the body text.

Failure Example 2:

The following code is an example of removing the underline from a link in a sentence or paragraph without providing another visual cue besides color.

Example Code:


<head>
<style type="text/css">
p a:link {text-decoration: none}
p a:visited {text-decoration: none}
p a:active {text-decoration: none}
p a:hover {text-decoration: underline; color: red;}
</style>
</head>

<body>

<p>To find out more about the <a href="rain_in_spain.htm">rain in spain</a>there are many resources.</p>

</body>

Note: If the visual cue is only provided on hover (as in the example above), it would still fail.

Tests

Procedure

  1. Check that each link in the page that is identifiable by color (hue) is visually identifiable via some other means (e.g., underlined, bolded, italicized, sufficient difference in lightness, etc).

Expected Results

  • If check #1 is false, then this failure condition applies and the content fails this Success Criterion.


F74: Failure of Success Criterion 1.2.2 and 1.2.8 due to not labeling a synchronized media alternative to text as an alternative

Applicability

Pages that provide synchronized media alternatives to text.

This failure relates to:

Description

The objective of this failure is to avoid situations in which synchronized media alternatives are not labeled with the text for which they are alternatives. Synchronized media alternatives provide enhanced access to users for whom synchronized media is a more effective format than text. Since they are alternatives to text, they do not need themselves to have redundant text alternatives. However, they need to be clearly labeled with the text for which they substitute, so users can find them and so users who normally expect text alternatives to synchronized media know not to look for them.

Examples

Failure Example 1: Synchronized media alternatives provided elsewhere on page

A page with instructions to complete a tax form provides a prose description of the fields to complete, data to provide, etc. Additionally, a synchronized media alternative provides spoken instructions, with video of a person completing the section being discussed in the audio. Although both versions are provided on the page, the synchronized media version is provided elsewhere on the page and is not clearly labeled with the part of the text for which it is a substitute. This makes it difficult for users encountering the text to find it, and users encountering the video do not know where its text alternative is.

(none currently listed)

Tests

Procedure

  1. Check pages that provide synchronized media alternatives to text.

  2. Check that synchronized media is clearly labeled with the text for which it is an alternative.

Expected Results

  • If check #2 is false, then this failure condition applies and the content fails these Success Criteria.


F75: Failure of Success Criterion 1.2.2 by providing synchronized media without captions when the synchronized media presents more information than is presented on the page

Applicability

Any technology.

This failure relates to:

Description

The objective of this failure is to avoid situations in which synchronized media alternatives provide more information than the text for which they are alternatives, but do not provide their own text alternatives to provide access to the extra information. Synchronized media alternatives provide enhanced access to users for whom synchronized media is a more effective format than text. Since they are alternatives to text, they do not need themselves to have redundant text alternatives in the form of captions, audio descriptions or full text alternatives. However, if they provide more information than the text for which they are an alternative, then they are not just alternatives but are synchronized media content in their own right. In this case they are subject to the full requirements of Success Criterion 1.2.2 to provide captions and to Success Criterion 1.2. and 1.2.5.

Examples

(none currently listed)

Tests

Procedure

  1. Check for captions on synchronized media alternatives.

  2. Check that the synchronized media alternative does not provide more information than is presented on the page in text.

    Note: Synchronized media alternatives often use different words to present what is on the page but it should not present new information on the topic of the page.

Expected Results

  • If check #2 is false, then this failure condition applies and the content fails these Success Criteria.


F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID

Applicability

HTML5, and any XML-based markup languages including HTML 4 and SVG

This failure relates to:

Description

This describes a failure condition where duplicate ID errors are known to cause problems for assistive technologies when they are trying to interact with content. Duplicate values of type ID can be problematic for user agents that rely on this attribute to accurately convey relationships between different parts of content to users. For example, a screen reader may use ID values to identify the applicable header content for a data cell within a data table, or an input control to which a given label applies. If these values are not unique, the screen reader will be unable to programmatically determine which headers are associated with the data cell or which control is associated with which label or name.

Checking that ID attribute values are unique within a document can be done by validating the document against its specification, because the specification defines which attributes contain document-wide unique identifiers.

Note 1: In most markup languages, ID values are attribute values, for example in HTML and SVG.

Note 2: XML documents that use only the xml:id attribute as an ID attribute, parsing the XML document with a validating parser that supports the xml:id specification is sufficient.

Examples

Failure Example 1

An author uses an online validation service to check that all id attribute values are unique.

Failure Example 2

A developer utilizes features in their authoring tool to ensure that id attribute values are unique.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Check that all values of type ID are unique in the Web page

Expected Results

  • If Step #1 is false, then this failure condition applies and the content fails the Success Criterion.


F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator

Applicability

Any technology

This failure relates to:

Description

This describes a failure condition that occurs when the user agent's default visual indication of keyboard focus is turned off or rendered non-visible by other styling on the page without providing an author-supplied visual focus indicator. Turning off the focus indicator instructs the user agent not to present the focus indicator. Other styling may make it difficult to see the focus indicator even though it is present, such as outlines that look the same as the focus outline, or thick borders that are the same color as the focus indicator so it cannot be seen against them.

Examples

Failure Example 1: The focus indicator is turned off with CSS

The following CSS example will remove the default focus indicator, which fails the requirement to provide a visible focus indicator.

Example Code:

:focus {outline: none}

Failure Example 2: The outline of elements is visually similar to the focus indicator

The following CSS example will create an outline around links that looks the same as the focus indicator. This makes it impossible for users to determine which one in fact has the focus, even though the user agent does draw the focus indicator.

Example Code:

a {outline: thin dotted black}

Failure Example 3: Elements have a border that occludes the focus indicator

The following CSS example creates a border around links that does not have enough contrast for the focus indicator to be seen when drawn on top of it. In this case the focus indicator is drawn just ouside the border, but as both are black and the border is thicker than the focus indicator, it no longer meets the definition of "visible".

Example Code:

a {border: medium solid black}

Resources

No resources available for this technique.

Tests

Procedure

  1. Set the focus to all focusable elements on a page using the keyboard.

  2. Check that the focus indicator is visible.

Expected Results

  • #2 is true.


F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available

Applicability

All technologies

This failure relates to:

Description

Whether a user interface component has focus is a particularly important facet of its state. Many types of assistive technology rely on tracking the current keyboard focus. Screen readers will move the user's point of regard to the focused user interface component, and screen magnifiers will change the display of the content so that the focused component is visible. If assistive technology is not notified when focus moves to a new component, the user will become confused when they attempt to interact with the wrong component.

While user agents usually handle this functionality for standard controls, custom-scripted user interface components are responsible for using accessibility APIs to make focus information and notifications available.

Examples

A custom menu displays menu items by rendering them explicitly, handling mouse and key events directly and highlighting the currently selected menu item. The programmer does not expose the menu item that has focus via the Accessibility API, so assistive technology can only determine that focus is somewhere within the menu and cannot determine which menu item has focus.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check the controls to see if they expose the focus state through the accessibility API.

  2. Using the accessibility checker for the technology (or if that is not available, inspect the code or test with an assistive technology), check whether assistive technology is notified when focus moves from one control to another.

Expected Results

  • If Check #1 or Check #2 is false, then this failure condition applies and the content fails this Success Criterion.


F80: Failure of Success Criterion 1.4.4 when text-based form controls do not resize when visually rendered text is resized up to 200%

Applicability

HTML, XHTML, and CSS

This failure relates to:

Description

The objective of this failure condition is to describe a problem that occurs when changing the size of text does not cause the text-based form controls to resize accordingly. This means that the user may have difficulty entering text and being able to read what they have entered because the text is not displayed at the text size required by the user.

Text-based form controls include input boxes (text and textarea) as well as buttons.

Examples

Failure Example 1: A Contact Form

A Contact Us form has some introductory information and then form controls for users to enter their first name, last name, telephone number and email address. The heading, introductory text and form control labels have been implemented in a scalable way but the form controls themselves have not.

The XHTML component:

Example Code:

 <h1>Contact Us</h1>
 <p>Please provide us with your details and we will contact you as soon as we can. Note that all of the form fields are required.</p>
 <label for="fname">First Name</label><input type="text" name="fname" id="fname" /><br />
 <label for="lname">Last Name</label><input type="text" name="lname" id="lname" /><br />
 <label for="phone">Telephone</label><input type="text" name="phone" id="phone" /><br />
 <label for="email">Email</label><input type="text" name="email" id="email" /><br />
 <input type="submit" name="Submit" value="Submit" id="Submit" />

The CSS component:

Example Code:

 h1 { font-size: 2em; }
 p, label { font-size: 1em; }
 input {font-size: 12pt}

Resources

No resources available for this technique.

(none currently listed)

Tests

Procedure

  1. Enter some text into text-based form controls that receive user entered text.

  2. Increase the text size of the content by 200%.

  3. Check that the text in text-based form controls has increased by 200%.

Expected Results

  • If check #3 is false, then the failure condition applies and the content fails these Success Criteria.


F81: Failure of Success Criterion 1.4.1 due to identifying required or error fields using color differences only

Applicability

All technologies

This failure relates to:

Description

This objective of this technique is to describe the failure that occurs when a required field or an error field is marked with color differences only, without an alternate way to identify the required field or error field. This can cause problems for people who are blind or colorblind, because they may not be able to perceive the color differences that indicate which field is required or which field is causing an error.

Examples

  • A user is completing an online form, and the phone number field is required. To indicate that the phone number field is required, the label "Phone Number" is displayed in a color different from the color used for optional fields, without any other indication that "Phone Number" is a required field. A blind or colorblind user may not be able to identify that "Phone Number" is a required field.

  • A user submits an online form and leaves a required field blank, resulting in an error. The form field that caused the error is indicated by red text only, without an additional non-color indication that the field caused an error.

Note: In both examples, the color could be used without failure if the text was sufficiently different in visual presentation (e.g. bold or in a different font) that it would be easily differentiated from the surrounding text if the color were removed. It would also not fail if the color chosen had sufficient luminosity difference (lightness) from the other text that it would be easily be seen as different if viewed in black and white. In these cases - the information would not be displayed in color (hue) alone but also in "presentation" or "lightness" respectively.

Tests

Procedure

For all required fields or error fields in the Web page that are identified using color differences:

  1. Check that an non-color way to identify the required field or error field is provided.

Expected Results

  • If step #1 is false, then this failure condition applies and content fails the Success Criterion.


F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label

Applicability

Any technology

This failure relates to:

Description

This failure ensures that people with visual or cognitive disabilities will recognize phone number fields and understand what information to provide to fill in the fields. Phone numbers are frequently formatted in fixed, distinctive ways, and authors may feel that just providing visual formatting of the fields will be sufficient to identify them. However, even if all the fields have programmatically determined names, a text label must also identify the set of fields as a phone number.

Examples

Failure Example 1:

In the United States, phone numbers are broken into a three digit area code, a three digit prefix, and a four digit extension. A web page creates fixed length text input fields for the three parts of the phone number, surrounding the first field with parenthesis and separating the second and third fields with a dash. Because of this formatting, some users recognize the fields as a phone number. However, there is no text label for the phone number on the web page. This is because the label for each field will be the closest preceding text, so the three fields would be labeled "(", ")" , and "-" respectively.

Tests

Procedure

  1. For each set of phone number fields in the web page that represents a single phone number, check that the set of fields are labeled with a visible text label that is positioned near the set of phone number fields.

  2. For each set of phone number fields in the Web page that represent a single phone number, instructions are provided about how to fill in the fields.

Expected Results

  • If both check #1 and check #2 are false, then this failure condition applies and the content fails this success criterion.


F83: Failure of Success Criterion 1.4.3 and 1.4.6 due to using background images that do not provide sufficient contrast with foreground text (or images of text)

Applicability

Any technology

This failure relates to:

Description

This failure occurs when people with low vision are not able to read text that is displayed over a background image. When there is not sufficient contrast between the background image and the text, features of the background image can be confused with the text making it difficult to accurately read the text.

To satisfy Success Criterion 1.4.3 and 1.4.6, there must be sufficient contrast between the text and its background. For pictures, this means that there would need to be sufficient contrast between the text and those parts of the image that are most like the text and behind the text.

Examples

Failure Example 1: Failure Example 1

Black text overlays an image with black lines. The lines cross behind the letters making F's look like E's etc.

Failure Example 2: Failure Example 2

Black text overlays an image with with dark gray areas. Wherever the text crosses a dark gray area the contrast is so bad that the text cannot be read.

Tests

Procedure

  1. Quickcheck: First do a quick check to see if the contrast between the text and the area of the image that is darkest (for dark text) or lightest (for light text) meets or exceeds that required by the Success Criterion (1.4.3 or 1.4.5). If the contrast meets or exceeds the specified contrast, then there is no failure.

  2. If the Quickcheck is false, then check to see if the background behind each letter has sufficient contrast with the letter.

Expected Results

  • If Quickcheck is false and #2 is false as well then this failure condition applies and the content fails the contrast Success Criterion.


F84: Failure of Success Criterion 2.4.9 due to using a non-specific link such as "click here" or "more" without a mechanism to change the link text to specific text.

Applicability

HTML and XHTML

This failure relates to:

Description

This failure describes a common condition where links such as "click here" or "more" are used as anchor elements where you need to have the surrounding text to understand their purpose and where there isn't any mechanism to make the destination clear by itself, such as a button to expand the link text.

Many blind people who use screen readers call up a dialog box that has a list of links from the page. They use this list of links to decide where they will go. But if many of the links in that list simply say "click here" or "more" they will be unable to use this feature in their screen reader, which is a core navigation strategy. That's why it's a failure of 2.4.9 to not provide any way of allowing them to know the destination from the link text alone. It is also true for people who tab through links. If all they hear as they tab through the document is "click here, click here, click here etc." they will become confused.

Examples

Failure Example 1

Example Code:

<a href="file110.htm">Click here</a> for more information on the Rocky Mountains.

Failure Example 2

Example Code:

<h2>News headlines</h2>
The middle east peace meetings have yielded fruitful dialogue. 
<a href="r4300.htm">read more</a>

Tests

Procedure

  1. Examine each link on the page.

  2. Check to see if it has non-descript link text such as "click here" or "more" whose purpose can be determined from the surrounding text but not from the link text alone.

  3. Check to see if there is a mechanism on the page which turns all non-descript links on the page into descriptive links.

Expected Results

  • If step #2 is true AND #3 is false, then this failure condition applies and content fails the success criterion.


F85: Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent to their trigger control in the sequential navigation order

Applicability

All technologies.

This failure relates to:

Description

This describes the failure condition that results when a Web page opens a dialog or menu interface component embedded on the page in a way that makes it difficult for a keyboard user to operate because of its position in the sequential navigation order. When the user opens the dialog or menu embedded on the page by activating a button or link, his next action will be to interact with the dialog or menu. If focus is not set to the dialog or menu, and it is not adjacent to the trigger control in the sequential navigation order, it will be difficult for the keyboard user to operate the dialog or menu.

Examples

Failure Example 1: Adding a dialog or menu embedded on the page to the end of the sequential navigation order

When a DHTML menu or dialog is activated, it is created dynamically, positioned visually near the trigger, and appended to the end of the DOM. Because it is appended to the end of the DOM, it is at the end of the sequential navigation order. The user must tab through the rest of the web page before he can interact with the dialog or menu.

Failure Example 2: Setting focus to the document after dismissing a menu embedded on the page

When a menu is dismissed, it is removed or hidden from the web page and focus is set to the document. The user must tab from the beginning of the navigation sequence to reach the point from which the menu was opened.

Tests

Procedure

For each menu or dialog embedded on a Web page that is opened via a trigger control:

  1. Activate the trigger control via the keyboard.

    • Check whether focus is in the menu or dialog.

    • Check whether advancing the focus in the sequential navigation order puts focus in the menu or dialog.

  2. Dismiss the menu or dialog.

    • Check whether focus is on the trigger control.

    • Check whether advancing the focus backwards in the sequential navigation order puts focus in the trigger control.

Expected Results

  • If both points under step 1 are false, then this failure condition applies and the content fails this success criterion.

  • If both points under step 2 are false, then this failure condition applies and the content fails this success criterion.


F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number

Applicability

General

This failure relates to:

Description

This describes a failure condition of Success Criterion 4.1.2 where some or all of the parts of multi-part form field do not have names. Often there is a label for the multi-part field, which is either programatically associated with the first part, or not programatically associated with any parts.

Note: A name does not necessarily have to be visible, but is visible to assistive technologies.

Examples

Failure Example 1

A US telephone number consists of a 3-digit area code, a 3-digit prefix, and a 4-digit suffix. They are typically formatted as follows ([area code]) [prefix]-[suffix], such as (206) 555-1212. Often, forms asking for a telephone number will include 3 separate fields, but with a single label, such as:

Phone number: 
(<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

The failure occurs when there is not a name for each of the 3 fields in the Accessibility API. A user with assistive technology will experience these as three undefined text fields. Some assistive technologies will read the punctuation as identification for the text fields, which can be even more confusing. In the case of a 3-field US phone number, some assistive technologies would name the fields "(", ")" and "-", which is not very useful.

Failure Example 2

The same US telephone number. In this case, the label is not programatically associated with any of the parts.

Phone number: (<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

A user with assistive technology will experience these as three undefined text fields.

Failure Example 3

The same US telephone number. In this case, the label is programatically associated with the first part.

<label for="area">Phone number:</label> 
(<input id="area" type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

A user with assistive technology will be led to believe that the first field is for the entire phone number, and will experience the second and third fields as undefined text fields.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

For each subfield in the multi-part form field:

  1. Check that there is a programmatically determined name for the field.

Expected Results

  • If check #1 is false for any subfield, then the failure condition applies and the content fails the success criterion.


F87: Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using :before and :after pseudo-elements and the 'content' property in CSS

Applicability

All technologies that support CSS.

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F87.

Description

The CSS :before and :after pseudo-elements specify the location of content before and after an element's document tree content. The content property, in conjunction with these pseudo-elements, specifies what is inserted. For users who need to customize or turn off style information in order to view content according to their needs, assistive technologies may not be able to access the information that is inserted using CSS. Therefore, it is a failure to use these properties to insert non-decorative content.

Examples

Failure Example 1

In the following example, :before and :after are used to indicate speaker changes and to insert quotation marks in a screenplay.

The CSS contains:

Example Code:

 p.jim:before {	content: "Jim: " }
p.mary:before { content: "Mary: " }

q:before { content: open-quote }
q:after  { content: close-quote }

It is used in this excerpt:

Example Code:

 <p class="jim">
 <q>Do you think he's going to make it?</q>
</p>
<p class="mary">
 <q>It's not looking good.</q>
</p>

Failure Example 2

In this example, :before is used to differentiate facts from opinions.

The CSS contains:

Example Code:

 p.fact:before { content: "Fact: "; font-weight: bold; }
 p.opinion:before { content: "Opinion: "; font-weight: bold; }

It is used in this excerpt:

Example Code:

 <p class="fact">
 The defendant was at the scene of the crime when it occurred. 
</p>
<p class="opinion">
 The defendant committed the crime. 
</p>

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Examine all content inserted through use of the :before and :after pseudo-elements and the content property

  2. Verify that the content is decorative.

  3. If the inserted content is not decorative, check that the information is provided to assistive technologies and is also available when CSS is turned off.

Expected Results

  • If checks #2 or #3 are false, then this failure condition applies and the content fails this Success Criterion.


F88: Failure of Success Criterion 1.4.8 due to using text that is justified (aligned to both the left and the right margins)

Applicability

All technologies.

This failure relates to:

Description

Many people with cognitive disabilities have a great deal of trouble with blocks of text that are justified (aligned to both the left and the right margins). The spaces between words create "rivers of white" running down the page, which can make the text difficult for some people to read. This failure describes situations where this confusing text layout occurs. The best way to avoid this problem is not to create text layout that is fully justified (aligned to both the left and the right margins).

Examples

Failure Example 1

In the following example of a failure, the HTML align attribute is used to create justified text.

Example Code:

 
<p align="justify">Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus 
nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec 
ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus. 
Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum 
primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo 
justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.
</p>

Failure Example 2

In this example of a failure, the CSS text-align property is used to create justified text.

Example Code:

 
...
p {text-align: justify}

...

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus 
nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec 
ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus. 
Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum 
primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo 
justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.</p>

Tests

Procedure

  1. Open the page in a common browser.

  2. Verify that content is not justified (aligned to both the left and the right margins).

Expected Results

  • If test procedure #2 is false, then this failure condition applies and the content fails to meet Success Criterion 1.4.8.


F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link

Applicability

Content that contains links.

This failure relates to:

Description

This failure condition occurs when a link contains only non-text content, such as an image, and that link cannot be identified by an accessible name. The accessible name for a link is defined according to the Accessible Name Calculation.

This also applies when both text and images are used separately on a page to link to the same target. In this case success technique H2: Combining adjacent image and text links for the same resource (HTML) is the recommended approach to reduce the number of separate links and the undesirable redundancy.

Examples

Failure Example 1: HTML Search Results

A search site returns search results that include both a text link and an image link to the match site. The image has a null alt attribute, since the result already contains a link with a text description. However, the screen reader does not ignore the image link but uses heuristics to find some text that might describe the purpose of the link. For example, the screen reader might announce, "football dot gif Football Scorecard."

Example Code:

 <a href="scores.html">
   <img src="football.gif" alt="" />
 </a>
 <a href="scores.html">
   Football Scoreboard
 </a>
}

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Check whether the link contains only non-text content.

  2. Check whether the non-text content has been implemented in a way that it can be ignored by assistive technologies, such as using role="presentation" or alt="" .

  3. Check that the link does not have an accessible name provided in another way such as aria-label or aria-labelledby.

Expected Results

  • If all checks are true, then this failure condition applies and the content fails the success criteria.


F90: Failure of Success Criterion 1.3.1 for incorrectly associating table headers and content via the headers and id attributes

Applicability

HTML and XHTML.

This failure relates to:

Description

One way for authors to explicitly associate header cells to data cells is by using the id and headers attributes. These allow the author to associate multiple header cells to a particular data cell, which can be necessary when complex data tables with more than one level of heading are used.

The failure occurs when the relationship between data cells and corresponding header cells cannot be programmatically determined correctly because the association of id and headers attributes is faulty. This can happen, for example, when copying code within tables and forgetting to update the code.

Examples

Note: The example below is based on the complex data table presented as example 1 of H43: Using id and headers attributes to associate data cells with header cells in data tables (HTML) .

Failure Example 1: Table content not correctly associated to nested headers

In this example, nested headers are used, but the content cells are incorrectly associated via the id and headers attributes. All cells reference top level header 'Exams' (id="e") - this isn't correct for the last three columns which should reference header 'Projects'. Also, the referencing of the second level column headers has been accidentally swapped even though in this example this makes no difference as the contents (1, 2, Final) are repeated.

Example Code:


<table>
   <tr>
     <th rowspan="2" id="h">Homework</th>
     <th colspan="3" id="e">Exams</th>
     <th colspan="3" id="p">Projects</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">Final</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">Final</th>
   </tr>
   <tr>
     <td headers="h">15%</td>       
     <td headers="e p1">15%</td>  // should be "e e1"
     <td headers="e p2">15%</td>  // should be "e e2"
     <td headers="e pf">20%</td>  // should be "e ef"
     <td headers="e e1">10%</td>  // should be "p p1"
     <td headers="e e2">10%</td>  // should be "p p2"
     <td headers="e ef">15%</td>  // should be "p pf"
   </tr>
</table>
							

Failure example of table incorrectly associating headers attributes in table content (td) to table headers (th).

Tests

Procedure

  1. For tables that associate data cells to header cells via the id and headers attributes, check that the programmatic association is correct.

Expected Results

  • If check #1 is false, then this failure condition applies and the content fails the Success Criterion.


F91: Failure of Success Criterion 1.3.1 for not correctly marking up table headers

Applicability

HTML and XHTML.

This failure relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for F91.

Description

This failure occurs when data tables do not use header elements (th) or other appropriate table mark-up (the scope attribute, headers and id or the ARIA roles columnheader / rowheader) to make the headers programatically determinable from within table content. Making headers programmatically determinable is especially important when data cells are only intelligible together with header information. When screen reader users navigate through the table content horizontally or vertically, the headers that change can be read out to provide the necessary context for the information in the data cells.

Examples

Failure Example 1: Headers not marked up appropriately

This table does not use th (or other appropriate header markup) for headers. Instead, it uses td elements for all cells. Navigating cell by cell, screen readers will often fail to read the header cells associated with content.

Example Code:


<table>
   
   <tr>
      <td>Name</td>
      <td>Age</td>
      <td>Height (cm)</td>
      <td>Weight (kg)</td>
   </tr>   
   
   <tr>
      <td>Linda</td>
      <td>33</td>
      <td>169</td>
      <td>59</td>
   </tr>   
   
   <tr>
      <td>Jack</td>
      <td>37</td>
      <td>184</td>
      <td>74</td>
   </tr>    
   
   <tr>
      <td>Kira</td>
      <td>8</td>
      <td>120</td>
      <td>21</td>
   </tr>   
   
   <tr>
      <td>Daniel</td>
      <td>3</td>
      <td>79</td>
      <td>14</td>
   </tr>  
</table>
							

View example 1 (opens in same browser window)

Tests

Procedure

For all data tables, check if table headers can be correctly programmatically determined by use of one of the following mechanisms:

  1. headers marked up with table header (th) elements

  2. scope attributes on th for tables with more than a single row or column of table headers.

  3. scope attributes on th for tables with more than a single row or column of table headers.

  4. headers and data cells associated using headers and id attributes

  5. headers marked up as td elements with the scope attribute

  6. headers marked up with ARIA role attributes rowheader or columnheader

Expected Results

  • If all checks are false, then this failure condition applies and the content fails the Success Criterion.


F92: Failure of Success Criterion 1.3.1 due to the use of role presentation on content which conveys semantic information

Applicability

HTML and XHTML

This failure relates to:

Description

This failure occurs when a role of presentation is applied to an element whose purpose is to convey information or relationships in the content. Elements such as table, can convey information about the content contained in them via their semantic markup. The WAI-ARIA role of "presentation" on the other hand, is intended to suppress semantic information of content from the accessibility API and prevent user agents from conveying that information to the user. Use of the "presentation" role for content which should convey semantic information may prevent the user from understanding that content.

Examples

Failure Example 1:

In this example, tabular data is marked up with role=presentation. Though design layout tables can be marked up in such a way, data tables need to retain their semantic information and should therefore not be marked up with role=presentation.

Example Code:


<table role="presentation">
   <caption>Fruits and their colors</caption>
   <tr>
     <th>Name</th>
     <th>Color</th>
   </tr>
   <tr>
    <td scope="row">banana</td>
    <td>yellow</td>
   </tr>
   <tr>
    <td scope="row">orange</td>
    <td>orange</td>
   </tr>
  </table>
                            

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Check if an element which conveys information, structure, or relationships through its semantic markup

  2. Element has the attribute role="presentation".

Expected Results

  • If check #2 is true, then this failure condition applies and the content fails the Success Criterion.


F93: Failure of Success Criterion 1.4.2 for absence of a way to pause or stop an HTML5 media element that autoplays

Applicability

HTML5

This failure relates to:

Description

This failure occurs when an audio or video element with an audio track contains the autoplay attribute and does not contain the muted attribute, and no controls or commands have been provided to pause or stop the media resource.

When the autoplay attribute is present, the user agent will automatically begin playback of the media resource as soon as it can do so without stopping. When the muted attribute is present, the user agent will initially mute the media resource's audio output, overriding any user preference.

If the media element is shorter than 3 seconds, the failure does not occur. If the user agent provides user preferences to override autoplay behavior, the failure does not occur.

The HTML spec contains the following notes:

  • User agents do not need to support autoplay, and it is suggested that user agents honor user preferences on the matter. Authors are urged to use the autoplay attribute rather than using script to force the video to play, so as to allow the user to override the behavior if so desired.

  • Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired, e.g. when using a screen reader. Authors are also encouraged to consider not using the automatic playback behavior at all, and instead to let the user agent wait for the user to start playback explicitly.

Examples

Example 1: An auto-playing audio track

In this example, the advertising video contains an audio track. The video will play continuously because of the loop attribute, and the video will start automatically because of the autoplay attribute and because there does not appear to be any controls to allow the user to stop the video.

Example Code:


				 <video src="ads.cgi?kind=video" autoplay loop></video>
            

Resources

Resources are for information purposes only, no endorsement implied.

(none currently listed)

Tests

Procedure

  1. Check if an audio or video element has an active audio track.

  2. Check if the audio or video lasts longer than 3 seconds.

  3. Check if the element has an autoplay attribute.

  4. Check if the element does not have a muted attribute.

  5. Check if no command or control has been provided to stop or pause the media element.

Expected Results

  • If checks 1-5 are true, then this failure condition applies and the content fails the Success Criterion.