This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Difference between revisions of "ARIA-edit: 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"

From WCAG WG
Jump to: navigation, search
m (removed reference to tabindex from test procedure)
Line 63: Line 63:
  
 
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.
 
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.
 
===Failure Example 2===
 
 
The following example is a different version of Failure Example 1. Here, the [http://www.w3.org/TR/wai-aria/roles#checkbox ARIA <code>role="checkbox"</code>] has been applied, but the content is still inaccessible to keyboard users because the <code>tabindex</code> attribute has not been on the <code>span</code> to ensure it is included in tabbing order.
 
 
<pre>
 
<p>
 
  <span role="checkbox" onclick="toggleCheckbox('chkbox')">
 
  <img src="unchecked.gif"  id="chkbox" alt=""> Include Signature
 
  </span>
 
  </p>
 
</pre>
 
  
 
==Resources==
 
==Resources==
Line 92: Line 80:
 
#Examine the source code for elements which have event handlers assigned within the markup or via scripting.
 
#Examine the source code for elements which have event handlers assigned within the markup or via scripting.
 
#If those elements are acting as user interface controls, check that either the role of the control is defined or an alternative method is provided to provide the same functionality.
 
#If those elements are acting as user interface controls, check that either the role of the control is defined or an alternative method is provided to provide the same functionality.
#Check that those elements are included in the tab order (usually by setting the <code>tabindex</code> attribute to a value of 0 or higher)
 
  
 
===Expected Results===
 
===Expected Results===
  
 
# If check #2 is false and the created user interface control does not have role information, this failure condition applies.
 
# If check #2 is false and the created user interface control does not have role information, this failure condition applies.

Revision as of 15:03, 20 June 2013


Status

20. April 2013 (Detlev)

  • Cleaned up Failure Example 1 (this was spread over Failure Example 1 and Failure Example 2)
  • Added a variant of Example 1 to show a situation where an ARIA role has been applied but tabindex has not been set
  • Added a check for tabindex in the test procedure
  • Added references to WAI/ARIA spec & Authoring practices in section Resources (20 April 2013)
  • Deleted references to "Dynamic Accessible Web Content Roadmap" (2006) and invalid link to "Accessible DHTML" (CodeTalks) in section Resources (20 April 2013)

Original version of F59

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.

See the resources section below for links to specifications which 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 (See section Resources).

Examples

Failure Example 1

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


Example Code:

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


Related Techniques

Tests

Procedure

  1. Examine the source code for elements which have event handlers assigned within the markup or via scripting.
  2. If those elements are acting as user interface controls, check that either the role of the control is defined or an alternative method is provided to provide the same functionality.

Expected Results

  1. If check #2 is false and the created user interface control does not have role information, this failure condition applies.