This Web page lists ARIA Techniques 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.
To improve accessibility, WAI-ARIA provides Web developers with the option to add the following semantic information to Web pages and rich Internet widgets which are then exposed to the browser:
Roles to describe the type of widget presented, such as "menu", "treeitem", "slider" and "progressbar."
Roles to describe the structure of the Web page, such as headings, regions, search areas and navigation areas.
Properties to describe the state widgets are in, such as "checked" for a check box, "haspopup" for a menu that renders a sub-menu or other popup and "expanded/collapsed" for a tree node.
Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates. Assistive technologies may present critical updates as soon as they are rendered. However, incidental updates are presented only after completing the current task. For example, a screen reader informs a user of an incidental update only after it finishes reading the current paragraph.
Properties for drag-and-drop that describe drag sources and drop targets
A method to provide keyboard navigation for rich internet widgets.
The combination of these features and the structural information conveyed by the DOM structure allow authors to produce an interoperable solution to assistive technologies. (Source: WAI-ARIA Overview)
User Agent support for WAI-ARIA varies, but overall support for WAI-ARIA is improving. Browsers which support WAI-ARIA map WAI-ARIA roles and properties to platform accessibility APIs.
Firefox 1.5 and Firefox 2.0 partially supports WAI-ARIA, however it requires the use of namespaces, and doesn't support the use of Liveregions.
Firefox 3+ contains better support for WAI-ARIA, including Liveregions.
IE8 partially supports WAI-ARIA.
JAWS 8 and Window-Eyes 5.5+ partially support WAI-ARIA.
Jaws 10+ supports WAI-ARIA.
FireVox, a self-voicing extension to Firefox, also supports WAI-ARIA via direct DOM access.
NVDA partially supports WAI-ARIA.
Using technologies in an Accessibility Supported way is required for conformance claims. Read more about Accessibility Support. The WCAG Working Group plans to review which WAI-ARIA techniques are sufficient when Accessible Rich Internet Application specifications reach W3C Recommendation status. Refer to WAI-ARIA Overview for the latest information on the status of WAI-ARIA.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA1. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to demonstrate how to use the WAI-ARIA aria-describedby property to provide programmatically determined, descriptive information about a user interface element. The aria-describedby property may be used to attach descriptive information to one or more elements through the use of an id reference list. The id reference list contains one or more unique element ids.
Refer to Supporting ARIA in XHTML and HTML 4.01 for information on how to provide WAI-ARIA States and Properties with XHTML and HTML. WAI-ARIA States and Properties is compatible with other languages as well; refer to documentation in those languages.
Note: The aria-describedby property is not designed to reference descriptions on an external resource — since it is an ID, it must reference an element in the same DOM document.
A button that functions as a 'close' button on a dialog is described elsewhere in the document. The aria-describedby property is used to associate the description with the link.
<button aria-label="Close" aria-describedby="descriptionClose"
onclick="myDialog.close()">X</button>
...
<div id="descriptionClose">Closing this window will discard any information entered and
return you back to the main page</div>
Working example: Example 1
Sample form field using aria-describedby to associate instructions with form fields while there is a form label.
<form>
<label for="fname">First name</label>
<input name="" type="text" id="fname" aria-describedby="int2">
<p id="int2">A bit of instructions for this field linked with aria-describedby. </p>
</form>
<p><span id="fontDesc">Select the font faces and sizes to be used on this page</span>
<button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">Fonts</button>
</p>
<p><span id="colorDesc">Select the colors to be used on this page</span>
<button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">Colors</button>
</p>
<p><span id="customDesc">Customize the layout and styles used on this page</span>
<button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">Customize</button>
</p>
The following code snippet shows how to use aria-describedby and the onfocus="tooltipShow() function to display the tooltip when focus is placed on an element.
<html lang="en-us">
<head>
<title>inline: Tooltip Example 1</title>
<link rel="stylesheet" href="css/tooltip1_inline.css" type="text/css">
<script type="text/javascript" src="js/tooltip1_inline.js"></script>
<script type="text/javascript" src="../js/widgets_inline.js"></script>
<script type="text/javascript" src="../js/globals.js"></script>
<link rel="icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon">
<link rel="shortcut icon" href="http://www.cites.uiuc.edu/favicon.ico" type="image/x-icon">
</head>
...
<body onload="initApp()">
<div id="container">
<h1>Tooltip Example 1</h1>
<h2>Create Account</h2>
<div class="text">
<label for="first">First Name:</label>
<input type="text" id="first" name="first" size="20"
onmouseover="tooltipShow(event, this, 'tp1');"
onfocus="tooltipShow(event, this, 'tp1');"
aria-describedby="tp1"
aria-required="false"/>
<div id="tp1" role="tooltip" aria-hidden="true">Your first name is optional. </div>
</div>
This example is coded in XHTML with a MIME type of application/xhtml+xml. This MIME type is not supported in all user agents. The aria-describedby property is added directly into the XHTML markup, and no additional scripting is needed.
Example Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+ARIA 1.0//EN"
"http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
<title>Demonstration of aria-describedby property</title>
<style type="text/css">
div.form p { clear:left; margin: 0.3em 0;}
.left {
float:left;
width:400px;
}
.right {
width:100px;
text-align:right;
}
</style>
</head>
<body>
<p>The buttons on this page use the Accessible Rich Internet Applications aria-describedby property
to provide more detailed information about the button action</p>
<div class="form">
<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
<span class="right"><button id="fontB" onclick="doAction('Fonts');" aria-describedby="fontDesc">
Fonts </button></span></p>
<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
<span class="right"><button id="colorB" onclick="doAction('Colors');" aria-describedby="colorDesc">
Colors </button></span></p>
<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
<span class="right"><button id="customB" onclick="doAction('Customize');" aria-describedby="customDesc">
Customize </button></span></p>
</div>
</body>
</html>
This example uses scripting to add an aria-describedby property to buttons on a page. The example creates a buttonIds array variable to hold the ids of the elements that contain description text. The setDescribedBy() function is called from the onload event of the window object.
The setDescribedBy() function loops through all of the button elements and calls setAttribute() on each button element to set the aria-describedby property. Each button's aria-describedby property is set to the id of the element containing its descriptive text.
Using a user agent and/or assistive technology which supports WAI-ARIA, the description will be provided when the user interface controls receive focus.
Example Code:
<html lang="en-us">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Demonstration of aria-describedby property</title>
<style type="text/css">
div.form p { clear:left; margin: 0.3em 0;}
.left {
float:left;
width:400px;
}
.right {
width:100px;
text-align:right;
}
</style>
<script type="text/javascript">
//<![CDATA[
// array entries for each button on the page that associates the button id
// with the id of the element containing the text which describes the button
var buttonIds = new Array();
buttonIds["fontB"]= "fontDesc";
buttonIds["colorB"] = "colorDesc";
buttonIds["customB"] = "customDesc";
// function that is run after the page has loaded to set the aria-describedBy
// property on each of the elements referenced by the array of id values
function setDescribedBy(){
if (buttonIds){
var buttons = document.getElementsByTagName("button");
if (buttons){
var buttonId;
for(var i=0; i<buttons.length; i++){
buttonId = buttons[i].id;
if (buttonId && buttonIds[buttonId]){
buttons[i].setAttribute("aria-describedby", buttonIds[buttonId]);
}
}
}
}
}
// simulated action function - currently just displays an alert
function doAction(theAction){
alert("Perform the " + theAction + " action");
}
window.onload=setDescribedBy;
//]]>
</script>
</head>
<body>
<p>The buttons on this page use the Accessible Rich Internet Applications
aria-describedby property to provide more detailed information
about the button action.
</p>
<div class="form">
<p><span class="left" id="fontDesc" >Select the font faces and sizes to be used on this page</span>
<span class="right"><button id="fontB" onclick="doAction('Fonts');"> Fonts </button></span>
</p>
<p><span class="left" id="colorDesc" >Select the colors to be used on this page</span>
<span class="right"><button id="colorB" onclick="doAction('Colors');"> Colors </button></span>
</p>
<p><span class="left" id="customDesc" >Customize the layout and styles used on this page</span>
<span class="right"><button id="customB" onclick="doAction('Customize');"> Customize </button></span>
</p>
</div>
</body>
Resources are for information purposes only, no endorsement implied.
Check that there is a user interface control having an aria-describedby attribute that references one or more elements via unique id.
Check that the referenced element or elements provide additional information about the user interface control.
Checks #1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA2. Also see WAI-ARIA Technology Notes.
The objective of this technique is to provide programmatic indication that a form field (which shown through presentation to be required) is mandatory for successful submission of a form.
The fact that the element is required is often visually presented (via a text or non-text symbol, or text indicating input is required or color / styling) but this is not programmatically determinable as part of the field's name.
The WAI-ARIA aria-required property indicates that user input is required before submission. The aria-required property can have values of "true" or "false". For example, if a user must fill in an address field, then aria-required is set to "true".
Note 1:
Note: Use of aria-required="true" might be beneficial even when an asterisk or other text symbol is programmatically associated with the field as it may reinforce its required property for some assistive technology users.
Note 2:
The fact that the element is required is often visually presented (such as a sign or symbol after the control). Using the aria-required property in addition to the visual presentation makes it much easier for user agents to pass on this important information to the user in a user agent-specific manner. Refer to Supporting ARIA in XHTML and HTML 4.01 for information on how to provide WAI-ARIA States and Properties with XHTML and HTML. WAI-ARIA States and Properties is compatible with other languages as well; refer to documentation in those languages.
The required property is indicated by an asterisk placed next to the label element:
<form action="#" method="post" id="login1" onsubmit="return errorCheck1()">
<p>Note: [*]denotes mandatory field</p>
<p>
<label for="usrname">Login name: </label>
<input type="text" name="usrname" id="usrname" aria-required="true"/>[*]
</p>
<p>
<label for="pwd">Password</label>
<input type="password" name="pwd" id="pwd" size="12" aria-required="true" />[*]
</p>
<p>
<input type="submit" value="Login" id="next_btn" name="next_btn"/>
</p>
</form> The required property is indicated by the word "required" placed next to the label element:
<form action="#" method="post" id="step1" onsubmit="return errorCheck2()">
<p>
<label for="fname">First name: </label>
<input type="text" id="fname" aria-required="true" />
[required]
</p>
<p>
<label for="mname">Middle name: </label>
<input type="text" id="mname" />
</p>
<p>
<label for="lname">Last name: </label>
<input type="text" id="lname" aria-required="true" />
[required]
</p>
<p>
<label for="email">Email address: </label>
<input type="text" id="email" aria-required="true" />
[required]
</p>
<p>
<label for="zip_post">Zip / Postal code: </label>
<input type="text" id="zip_post" size="6" aria-required="true" />
[required]
</p>
<p>
<input type="submit" value="Next Step" id="step_btn" name="step_btn" />
</p>
</form> Required fields are indicated by a red border around the fields and a star icon rendered via CSS using content:before. This example also uses custom radio buttons with role=radio but the script to make the span actually work like radio buttons is not included in this example. The CSS properties are available below the form.
<form action="#" method="post" id="alerts1">
<label for="acctnum" data-required="true">Account Number</label>
<input size="12" type="text" id="acctnum"
aria-required="true" name="acctnum" />
<p id="radio_label" data-required="true">Please send an alert when balance exceeds $3,000.</p>
<ul id="rg" role="radiogroup" aria-required="true" aria-labelledby="radio_label">
<li id="rb1" role="radio">Yes</li>
<li id="rb2" role="radio">No</li>
</ul>
</form>
Related CSS style definition for this example:
[aria-required=true] {
border: red thin solid;
}
[data-required=true]:after {
content: url('/iconStar.gif');
}
The following example shows an XHTML document using the aria-required property to indicate that a form field must be submitted. The mandatory nature of the field is also indicated in the label as a fallback for user agents that do not support WAI-ARIA.
Example Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1
For Accessible Adaptable Applications//EN"
"http://www.w3.org/WAI/ARIA/schemata/xhtml-aria-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en">
<head>
<title>Required Input</title>
</head>
<body>
<h1>Required Input</h1>
<p>The following form input field must be completed by the user
before the form can be submitted.</p>
<form action="http://example.com/submit">
<p>
<label for="test">Test (required)</label>
<input name="ariaexample" id="example" aria-required="true" aria-label="Test"/>
</p>
<p>
<input type="submit" value="Submit" />
</p>
</form>
</body>
</html>
This example uses scripting to add the aria-required property to a form element. The required property is assigned using the setAttribute() API.
The array variable, requiredIds, is created with the ids of the elements which need to be marked as required. The setRequired() function is called from the onload event of the window object.
The setRequired() function loops through all of the ids provided, retrieves the element and assigns the aria-required property of true using the setAttribute() function.
When this page is accessed using Firefox 3.0 or later and a screen reader that supports WAI-ARIA, the screen reader will speak "required" when reading the label for the input fields.
Example Code:
<head>
<script type="text/javascript">
//<![CDATA[
// array or ids on the required fields on this page
var requiredIds = new Array( "firstName", "lastName");
// function that is run after the page has loaded to set the aria-required property on each of the
//elements in requiredIds array of id values
function setRequired(){
if (requiredIds){
var field;
for (var i = 0; i< requiredIds.length; i++){
field = document.getElementById(requiredIds[i]);
field.setAttribute("aria-required", "true");
}
}
}
window.onload=setRequired;
//]]>
</script>
</head>
<body>
<p>Please enter the following data. Required fields have been programmatically identified
as required and marked with an asterisk (*) following the field label.</p>
<form action="submit.php">
<p>
<label for="firstName">First Name *: </label><input type="text" name="firstName"
id="firstName" value="" />
<label for="lastName">Last Name *: </label><input type="text" name="lastName"
id="lastName" value="" />
</p>
</form>
</body>
Resources are for information purposes only, no endorsement implied.
For each control which is shown via presentation to be required.
Check whether the aria-required attribute is present:
Check whether the value of the aria-required attribute is the correct required state of the user interface component.
Checks #1 and #2 are true
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA4. Also see WAI-ARIA Technology Notes.
The objective of this technique is to define the role of an element using the role attribute with one of the non-abstract values defined in the WAI-ARIA Definition of Roles. The WAI-ARIA specification provides an informative description of each role, how it relates to other roles, and the states and properties for each role. When rich internet applications define new user interface widgets, exposing the roles enables users to understand the widget and how to interact with it.
The WAI-ARIA Authoring Practices document demonstrates a toolbar containing three buttons. The div element has a role of "toolbar", and the img elements have "button" roles:
<div role="toolbar"
tabindex="0"
id="customToolbar"
onkeydown="return optionKeyEvent(event);"
onkeypress="return optionKeyEvent(event);"
onclick="return optionClickEvent(event);"
onblur="hideFocus()"
onfocus="showFocus()"
>
<img src="img/btn1.gif"
role="button"
tabindex="-1"
alt="Home"
id="b1"
title="Home">
<img src="img/btn2.gif"
role="button"
tabindex="-1"
alt="Refresh"
id="b2"
title="Refresh">
<img src="img/btn3.gif"
role="button"
tabindex="-1"
alt="Help"
id="b3"
title="Help">
</div>
The Authoring Practices Toolbar Pattern provides a working example of a toolbar..
The WAI-ARIA Authoring Practices demonstrates a tree widget. Note the use of the roles "tree", "treeitem", and "group" to identify the tree and its structure. Here is a simplified excerpt from the code:
<ul role="tree" tabindex="0">
<li role="treeitem">Birds</li>
<li role="treeitem">Cats
<ul role="group">
<li role="treeitem">Siamese</li>
<li role="treeitem">Tabby</li>
</ul>
</li>
<li role="treeitem">Dogs
<ul role="group">
<li role="treeitem">Small Breeds
<ul role="group">
<li role="treeitem">Chihuahua</li>
<li role="treeitem">Italian Greyhound</li>
<li role="treeitem">Japanese Chin</li>
</ul>
</li>
<li role="treeitem">Medium Breeds
<ul role="group">
<li role="treeitem">Beagle</li>
<li role="treeitem">Cocker Spaniel</li>
<li role="treeitem">Pit Bull</li>
</ul>
</li>
<li role="treeitem">Large Breeds
<ul role="group">
<li role="treeitem">Afghan</li>
<li role="treeitem">Great Dane</li>
<li role="treeitem">Mastiff</li>
</ul>
</li>
</ul>
</li>
</ul>
The Authoring Practices Tree View Pattern provides a working example of a tree.
Resources are for information purposes only, no endorsement implied.
(none currently listed)
For a user interface component using the role attribute:
Check that the value of the role attribute is one of the non-abstract roles from the values defined in the WAI-ARIA specification.
Check that the characteristics of the user interface component are described by the role.
#1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA5. Also see WAI-ARIA Technology Notes.
The objective of this technique is to use WAI-ARIA state and property attributes to expose the state, properties and values of a user interface component so that they can be read and set by assistive technology, and so that assistive technology is notified of changes to these values. The WAI-ARIA specification provides a normative description of each attribute, and the role of the user interface elements that they support. When rich internet applications define new user interface widgets, exposing the state and property attributes enables users to understand the widget and how to interact with it.
A widget with role button acts as a toggle button when it implements the attribute aria-pressed. When aria-pressed is true, the button is in a "pressed" state. When aria-pressed is false, it is not pressed. If the attribute is not present, the button is a simple command button.
The following snippet from The Open Ajax Accessibility Examples, Example 38, shows WAI-ARIA mark-up for a toggle button that selects bold text:
<li id="bold1"
class="toggleButton"
role="button"
tabindex="0"
aria-pressed="false"
aria-labelledby="bold_label"
aria-controls="text1">
<img src="http://www.oaa-accessibility.org/media/examples/images/button-bold.png" alt="bold text" align="middle">
</li>
The li element has a role of "button" and an "aria-pressed" attribute. The following excerpt from the Javascript for this example updates the value of the "aria-pressed" attribute:
/**
* togglePressed() toggles the aria-pressed atribute between true or false
*
* @param ( id object) button to be operated on
*
* @return N/A
*/
function togglePressed(id) {
// reverse the aria-pressed state
if ($(id).attr('aria-pressed') == 'true') {
$(id).attr('aria-pressed', 'false');
}
else {
$(id).attr('aria-pressed', 'true');
}
}
This button is available as part of the working example of Example 38 - Toolbar using inline images for visual state, on the OpenAjax Alliance site.
A widget with role slider lets a user select a value from within a given range. The slider represents the current value and the range of possible values via the size of the slider and the position of the handle. These properties of the slider are represented by the attributes aria-valuemin, aria-valuemax, and aria-valuenow.
The following snippet from The Open Ajax Accessibility Examples, Example 32, shows WAI-ARIA mark-up for a slider created in Javascript. Note that the javascript sets the attributes aria-valuemin, aria-valuemax, and aria-valuenow:
var handle = '<img id="' + id + '" class="' + (this.vert == true ? 'v':'h') +'sliderHandle" ' +
'src="http://www.oaa-accessibility.org/media/examples/images/slider_' + (this.vert == true ? 'v':'h') + '.png" ' + 'role="slider" ' +
'aria-valuemin="' + this.min +
'" aria-valuemax="' + this.max +
'" aria-valuenow="' + (val == undefined ? this.min : val) +
'" aria-labelledby="' + label +
'" aria-controls="' + controls + '" tabindex="0"></img>';The following excerpt from the Javascript for this example updates the value of the "aria-valuenow" attribute when the value of the slider handle is changed:
slider.prototype.positionHandle = function($handle, val) {
...
// Set the aria-valuenow position of the handle
$handle.attr('aria-valuenow', val);
...
}
This slider is available as part of the working example of Example 32 - Slider, on the OpenAjax Alliance site.
Resources are for information purposes only, no endorsement implied.
The WAI-ARIA specification, Section 5.3, Categorization of Roles defines the required and inherited states and properties for each role.
For a user interface component using the WAI-ARIA role attribute:
Check that the required states and properties for the role are present.
Check that no WAI-ARIA states or properties that are neither required, supported, nor inherited are present.
Check that the state and property values are updated to reflect the current state when the user interface component changes state.
#1, #2, and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA6. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide a label for objects that can be read by assistive technology. The aria-label attribute provides the text label for an object, such as a button. When a screen reader encounters the object, the aria-label text is read so that the user will know what it is.
Authors should be aware that aria-label may be disregarded by assistive technologies in situations where aria-labelledby is used for the same object. For more information on the naming hierarchy please consult the ARIA specification and the accessible name and description calculation in the HTML to Platform Accessibility APIs Implementation Guide. Authors should be aware that use of aria-label will override any native naming such as alt on images or label associated with a form field using the for attribute.
The following example shows how aria-label could be used to distinguish two navigation landmarks in a HTML4 and XHTML 1.0 document, where there are more than two of the same type of landmark on the same page, and there is no existing text on the page that can be referenced as the label.
<div role="navigation" aria-label="Primary">
<ul><li>...a list of links here ...</li></ul> </div>
<div role="navigation" aria-label="Secondary">
<ul><li>...a list of links here ...</li> </ul></div>The following example shows how a generic "region" landmark might be added to a weather portlet. There is no existing text on the page that can be referenced as the label, so it is labelled with aria-label.
<div role="region" aria-label="weather portlet">
...
</div>Below is an example of a MathML function, using the math role, appropriate label, and MathML rendering:
<div role="math" aria-label="6 divided by 4 equals 1.5">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mfrac>
<mn>6</mn>
<mn>4</mn>
</mfrac>
<mo>=</mo>
<mn>1.5</mn>
</math>
</div>Resources are for information purposes only, no endorsement implied.
For each element where a aria-label attribute is present.
Examine whether the text description accurately labels the object or provides a description of its purpose or provides equivalent information.
#1 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA7. Also see WAI-ARIA Technology Notes.
With the aria-labelledby attribute, authors can use a visible text element on the page as a label for a focusable element (a form control or a link). For example, a "read more..." link could be associated with the text of the heading of the preceding section to make the purpose of the link unambiguous (see example 1).
When associating text to a focusable element with the help of aria-labelledby, the target text element is given an ID which is referenced in the value of the aria-labelledby attribute of the focusable element.
It is also possible to use several text elements on the page as a label for a focusable element. Each of the text elements used must be given a unique ID which is referenced as a string of IDs (IDREF) in the value of the aria-labelledby attribute. The label text should then be concatenated following the order of IDs in the value of the aria-labelledby attribute.
When applied on links, aria-labelledby can be used to identify the purpose of a link that may be readily apparent for sighted users, but less obvious for screen reader users.
The specified behavior of aria-labelledby is that the associated label text is announced instead of the link text (not in addition to the link text). When the link text itself should be included in the label text, the ID of the link should be referenced as well in the string of IDs forming the value of the aria-labelledby attribute.
For more information on the naming hierarchy please consult the ARIA specification and the accessible name and description calculation for links in the HTML to Platform Accessibility APIs Implementation Guide.
This example will mean that the link text as shown on screen is then used as the start of the accessible name for the link. Popular screen readers like JAWS and NVDA will announce this as: "Read more ...Storms hit east coast" and will display that same text in the links list which is very useful for screen reader users who may browse by links.
<h2 id="headline">Storms hit east coast</h2>
<p>Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns.
<a id="p123" href="news.html" aria-labelledby="p123 headline">Read more...</a></p>There may be cases where an author will placed a tag around a section of code that will be referenced.
Note: The use of tabindex="-1" on the span element is not meant to support focusing by scripts - here, it merely serves to ensure that some browsers (IE9, IE10) will include the span element in the accessibility tree, thus making it available for reference by aria-labelledby. For more details see Accessible HTML Elements.
<p>Download <span id="report-title" tabindex="-1">2012 Sales Report</span>:
<a aria-labelledby="report-title pdf" href="#" id="pdf">PDF</a> |
<a aria-labelledby="report-title doc" href="#" id="doc">Word</a> |
<a aria-labelledby="report-title ppt" href="#" id="ppt">Powerpoint</a></p>Resources are for information purposes only, no endorsement implied.
(none currently listed)
For each link that has an aria-labelledby attribute:
Check that each ID in the value of the aria-labelledby attribute matches an ID of a text element used as part of the link purpose.
Check that the combined value of the text referenced by the one or more ID's in the aria-labelledby attribute properly describes the purpose of the link element.
Checks #1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA8. Also see WAI-ARIA Technology Notes.
The objective of this technique is to describe the purpose of a link using the aria-label attribute. The aria-label attribute provides a way to place a descriptive text label on an object, such as a link, when there are no elements visible on the page that describe the object. If descriptive elements are visible on the page, the aria-labelledby attribute should be used instead of aria-label. Providing a descriptive text label lets a user distinguish the link from links in the Web page that lead to other destinations and helps the user determine whether to follow the link. In some assistive technologies the aria-label value will show in the list of links instead of the actual link text.
Per the WAI-ARIA specification and the HTML to Platform Accessibility APIs Implementation Guide, the aria-label text will override the text supplied within the link. As such the text supplied will be used instead of the link text by AT. Due to this it is recommended to start the text used in aria-label with the text used within the link. This will allow consistent communication between users.
In some situations, designers may choose to lessen the visual appearance of links on a page by using shorter, repeated link text such as "read more". These situations provide a good use case for aria-label in that the simpler, non-descriptive "read more" text on the page can be replaced with a more descriptive label of the link. The words 'read more' are repeated in the aria-label (which replaces the original anchor text of "[Read more...]") to allow consistent communication between users.
<h4>Neighborhood News</h4>
<p>Seminole tax hike: Seminole city managers are proposing a 75% increase in
property taxes for the coming fiscal year.
<a href="taxhike.html" aria-label="Read more about Seminole tax hike">[Read more...]</a>
</p>
<p>Baby Mayor: Seminole voters elect the city's youngest mayor ever by voting in 3 year
old Willy "Dusty" Williams in yesterday's mayoral election.
<a href="babymayor.html" aria-label="Read more about Seminole's new baby mayor">[Read more...]</a>
</p>Resources are for information purposes only, no endorsement implied.
For link elements that use aria-label:
Check that the value of the aria-label attribute properly describes the purpose of the link element.
#1 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA9. Also see WAI-ARIA Technology Notes.
The aria-labelledby property can be used to label all visual objects. Applied to inputs, the aria-labelledby property can be used to label native inputs as well as non-native elements, such as custom text inputs constructed with div contenteditable="true".
One particular use of aria-labelledby is for text inputs in situations where a meaningful label should consist of more than one label string.
Authors assign unique ids to the label strings to be concatenated as the label for the input element. The value of the aria-labelledby attribute is then a space-separated list of all ids in the order in which the label strings referenced should be read by screen readers. Supporting user agents will concatenate the label strings referenced and read them as one continuous label of the input.
The concatenation of label strings can be useful for different reasons. In example 1, an input is nested within the context of a full sentence. The desired screen reader output is "Extend time-out to [ 20 ] minutes - edit with autocomplete, selected 20". Since the id of the text input is included in the string of ids referenced by aria-labelledby, the value of the input is included in the concatenated label at the right position.
Another application of aria-labelledby is when there is no space to provide a visible label next to the input, or when using native labels would create unnecessary redundancy. Here, the use aria-labelledby makes it possible to associate visible elements on the page as label for such inputs. This is demonstrated in example 2 where table column and row headings are concatenated into labels for the text input elements inside the table.
Note: The ARIA accessible name and description calculation specifies that the string specified in aria-labelledby should replace rather than add to the content of the element that carries the property. So adding the aria-labelledby property to a native label should replace the text content inside that label unless the label itself is referenced as part of the sequence of ids in aria-labelledby.
A text input allows users to extend the default time before a time-out occurs.
The string "Extend time-out to" is contained in a native label element and is associated with the input with the input by id="timeout-duration" . This label is associated with this input using the for/id association only on user agents that don't support ARIA. On user agents that support ARIA, the for/id association is ignored and the label for the input is provided only by aria-labelledby, per the accessible name and description calculation in the HTML to Platform Accessibility APIs Implementation Guide.
The aria-labelledby attribute on the text input references three elements: (1) the span containing the native label, (2) the text input containing the default text '20' (recall that this input is not labelled with the for/id associated label text), and (3) the string 'minutes' contained in a span. These elements should be concatenated to provide the full label for the text input
Note: The use of tabindex="-1" on the span element is not meant to support focusing by scripts - here, it merely serves to ensure that some browsers (IE9, IE10) will include the span element in the accessibility tree, thus making it available for reference by aria-labelledby. For more details see Accessible HTML Elements
<form>
<p><span id="timeout-label" tabindex="-1"><label for="timeout-duration">Extend time-out to</label></span>
<input type="text" size="3" id="timeout-duration" value="20"
aria-labelledby="timeout-label timeout-duration timeout-unit">
<span id="timeout-unit" tabindex="-1"> minutes</span></p>
</form>Working example, Time-out input field with concatenated label, adapted from Easy ARIA tip #2: aria-labelledby and aria-describedby, an example put together by Marco Zehe.
A simple data table containing text inputs. The input labels are concatenated through aria-labelledby referencing the respective column and row headers.
<table>
<tr>
<td></td>
<th id="tpayer">Taxpayer</th>
<th id="sp">Spouse</th>
</tr>
<tr>
<th id="gross">W2 Gross</th>
<td><input type="text" size="20" aria-labelledby="tpayer gross" /></td>
<td><input type="text" size="20" aria-labelledby="sp gross" /></td>
</tr>
<tr>
<th id="div">Dividends</th>
<td><input type="text" size="20" aria-labelledby="tpayer div" /></td>
<td><input type="text" size="20" aria-labelledby="sp div" /></td>
</tr>
</table>Working example, Using aria-labelledby for simple table with text inputs, based on an example by Jim Thatcher.
A conference workshop booking table with two parallel tracks allows users to select the workshop they want to attend. When tabbing through the checkbox inputs in the table, the track (1 or 2), the title, and the speaker of the workshop followed by the adjacent checkbox label "Attend" are provided as concatenated label for the checkboxes via aria-labelledby.
Some browser / screen reader combinations (e.g. Mozilla Firefox and NVDA) will in addition speak the relevant table cell headers.
<h1>Dinosaur Conference workshops timetable Thursday, 14. & Friday, 15. March 2013</h1>
<table>
<caption>Dinosaur Conference workshop booking table</caption>
<tbody><tr>
<td rowspan="2"></td>
<th colspan="2" scope="colgroup">Thursday</th>
<th colspan="2" scope="colgroup">Friday</th>
</tr>
<tr>
<th scope="col" id="am1">9 to 12 AM</th>
<th scope="col" id="pm1">2 to 5 PM</th>
<th scope="col" id="am2">9 to 12 AM</th>
<th scope="col" id="pm2">2 to 5 PM</th>
</tr>
<tr>
<th id="track1" scope="row">track 1</th>
<td>
<h2 id="title-TM1">The Paleozoic era </h2>
<p>2 places left</p>
<p><input type="checkbox" id="TM1" aria-labelledby="title-TM1 track1 am1 TM1-att">
<label id="TM1-att" for="TM1">Attend</label></p>
</td>
<td>
<h2 id="title-TA1">The Mesozoic era overview</h2>
<p>2 places left</p>
<p><input type="checkbox" id="TA1" aria-labelledby="title-TA1 track1 am2 TA1-att">
<label id="TA1-att" for="TA1">Attend</label></p>
</td>
<td>
<h2 id="title-FM1">The Triassic period, rise of the dinosaurs</h2>
<p>1 place left</p>
<p><input type="checkbox" id="FM1" aria-labelledby="title-FM1 track1 pm1 FM1-att">
<label id="FM1-att" for="FM1">Attend</label></p>
</td>
<td>
<h2 id="title-FA1">The Jurassic period</h2>
<p>11 places left</p>
<p><input type="checkbox" id="FA1" aria-labelledby="title-FA1 track1 pm2 FA1-att">
<label id="FA1-att" for="FA1">Attend</label></p>
</td>
</tr>
<tr>
<th id="track2" scope="row">track 2</th>
<td>
<h2 id="title-TM2">The Cretaceous period</h2>
<p>18 places left</p>
<p><input type="checkbox" id="TM2" aria-labelledby="title-TM2 track2 am1 TM2-att">
<label id="TM2-att" for="TM2">Attend</label></p>
</td>
<td>
<h2 id="title-TA2">The end of the dinosaurs</h2>
<p>2 places left</p>
<p><input type="checkbox" id="TA2" aria-labelledby="title-TA2 track2 am2 TA2-att">
<label id="TA2-att" for="TA2">Attend</label></p>
</td>
<td>
<h2 id="title-FM2">First discoveries of dinosaurs</h2>
<p>2 places left</p>
<p><input type="checkbox" id="FM2" aria-labelledby="title-FM2 track2 pm1 FM2-att">
<label id="FM2-att" for="FM2">Attend</label></p>
</td>
<td>
<h2 id="title-FA2">Emerging scholarship</h2>
<p>19 places left</p>
<p><input type="checkbox" id="FA2" aria-labelledby="title-FA2 track2 pm2 FA2-att">
<label id="FA2-att" for="FA2">Attend</label></p>
</td>
</tr>
</tbody>
</table>Working example: Conference workshop booking timetable.
Resources are for information purposes only, no endorsement implied.
Using WAI-ARIA in HTML: Section 2.7 aria-labelledby and aria-describedby
For inputs that use aria-labelledby:
Check that ids referenced in aria-labelledby are unique and match the ids of the text nodes that together provide the label
Check that the concatenated content of elements referenced by aria-labelledby is descriptive for the purpose or function of the element labeled
#1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
This technique applies to HTML with Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA10. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide a short description for an element that can be read by assistive technologies (AT) by using the aria-labelledby attribute. The aria-labelledby attribute associates an element with text that is visible elsewhere on the page by using an ID reference value that matches the ID attribute of the labeling element. Assistive technology such as screen readers use the text of the element identified by the value of the aria-labelledby attribute as the text alternative for the element with the attribute.
This example shows how to use the aria-labelledby attribute to provide a short text description for a read-only complex graphic of an star rating pattern; the graphic is composed of several image elements. The text alternative for the graphic is the label, visible on the page beneath the star pattern.
<div role="img" aria-labelledby="star_id">
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="fullstar.png" alt=""/>
<img src="emptystar.png" alt=""/>
</div>
<div id="star_id">4 of 5</div>Working example: Providing a short description for a complex graphic.
Resources are for information purposes only, no endorsement implied.
Examine each element where the aria-labelledby attribute is present and the element does not support the alt attribute.
Check whether the value of the aria-labelledby attribute is the id of an element on the web page.
Determine that the text of the element identified by the aria-labelledby attribute accurately labels the element, provides a description of its purpose, or provides equivalent information.
#2 and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA11. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide programmatic access to sections of a web page. Landmark roles (or "landmarks") programmatically identify sections of a page. Landmarks help assistive technology (AT) users orient themselves to a page and help them navigate easily to various sections of a page.
They also provide an easy way for users of assistive technology to skip over blocks of content that are repeated on multiple pages and notify them of programmatic structure of a page. For instance, if there is a common navigation menu found on every page, landmark roles (or "landmarks") can be used to skip over it and navigate from section to section. This will save assistive technology users and keyboard users the trouble and time of tabbing through a large amount of content to find what they are really after, much like a traditional "skip links" mechanism. (Refer to User Agent Notes above for specifics of AT support). A blind user who may be familiar with a news site's menu, and is only interested in getting to the top story could easily navigate to the "main" landmark, and bypass dozens of menu links. In another circumstance, a user who is blind may want to quickly find a navigation menu, and can do so by jumping to the navigation landmark.
Landmarks also can help sighted keyboard-only users navigate to sections of a page using a browser plugin.
Landmarks are inserted into the page using the role attribute on an element that marks the section. The value of the attribute is the name of the landmark. These role values are listed below:
banner: A region that contains the prime heading or internal title of a page.
complementary: Any section of the document that supports the main content, yet is separate and meaningful on its own.
contentinfo: A region that contains information about the parent document such as copyrights and links to privacy statements.
form: A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.
main: Main content in a document. In almost all cases a page will have only one role="main".
navigation: A collection of links suitable for use when navigating the document or related documents.
search: The search tool of a Web document.
application: A region declared as a web application, as opposed to a web document. (note: The role of application should only be used with caution because it gives a signal to screen reading software to turn off normal web navigation controls. Simple widgets should generally not be given the application role, nor should an entire web page be given the application role, unless it is not to be used at all like a web page, and not without much user testing with assistive technology.)
There are cases when a particular landmark role could be used more than once on a page, such as on primary and secondary navigation menus. In these cases, identical roles should be disambiguated from each other using a valid technique for labelling regions (see examples below).
Landmarks should supplement native semantic markup such as HTML headings, lists and other structural markup. Landmarks are interpretable by WAI-ARIA-aware assistive technologies and are not exposed by browsers directly to users.
It is a best practice to include ALL content on the page in landmarks, so that screen reader users who rely on them to navigate from section to section do not lose track of content.
The following example shows how landmarks might be added to an HTML4 or XHTML 1.0 document:
<div id="header" role="banner">A banner image and introductory title</div>
<div id="sitelookup" role="search">....</div>
<div id="nav" role="navigation">...a list of links here ... </div>
<div id="content" role="main"> ... Ottawa is the capital of Canada ...</div>
<div id="rightsideadvert" role="complementary">....an advertisement here...</div>
<div id="footer" role="contentinfo">(c)The Freedom Company, 123 Freedom Way, Helpville, USA</div>The following example shows a best practice of how landmarks might be added to an HTML4 or XHTML 1.0 document in situations where there are more than two of the same type of landmark on the same page. For instance, if a navigation role is used multiple times on a Web page, each instance may have a unique label specified using aria-labelledby:
<div id="leftnav" role="navigaton" aria-labelledby="leftnavheading">
<h2 id="leftnavheading">Institutional Links</h2>
<ul><li>...a list of links here ...</li> </ul></div>
<div id="rightnav" role="navigation" aria-labelledby="rightnavheading">
<h2 id="rightnavheading">Related topics</h2>
<ul><li>...a list of links here ...</li></ul></div>The following example shows a best practice of how landmarks might be added to an HTML4 or XHTML 1.0 document in situations where there are more than two of the same type of landmark on the same page, and there is no existing text on the page that can be referenced as the label.
<div id="leftnav" role="navigaton" aria-label="Primary">
<ul><li>...a list of links here ...</li></ul> </div>
<div id="rightnav" role="navigation" aria-label="Secondary">
<ul><li>...a list of links here ...</li> </ul></div>The following example shows a search form with a "search" landmark. The search role typically goes on the form field or a div surrounding the search form.
<form role="search">
<label for="s6">search</label><input id="s6" type="text" size="20">
...
</form> Resources are for information purposes only, no endorsement implied.
Examine each element with a landmark role.
Examine whether the landmark role attribute is applied to the section of the page that corresponds with that role. (i.e., the "navigation" role is applied to a navigation section, the "main" role is applied to where the main content begins.)
#1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA12. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide a way for Assistive Technologies (AT) to identify
a piece of content as a heading. Applying role="heading" to an element causes an AT (like a
screen reader) to treat it as though it were a heading.
If there is more than one heading on the page and the heading hierarchy is defined through the
visual presentation, the aria-level attribute should be used to indicate the hierarchical level of
the heading.
When possible, use native heading mark-up directly. For example, it is preferable
to use h1 rather than using <div role="heading" aria-level="1">. However, the use of the
heading role, instead of heading mark-up, may be necessary. For example, when retrofitting a legacy site where scripts depend on the existing element hierarchy.
The use of the heading role and nesting levels is discussed in WAI-ARIA Authoring Practices 1.1.
This example demonstrates how to implement simple headings using role="heading" when retrofitting a legacy site where scripts depend on the existing element hierarchy or the level is unknown. For example, web content which is syndicated from various sources may be constructed without knowledge of what the final presentation will be.
<div role="heading">Global News items</div>
... a list of global news with editorial comment....
<div role="heading">Local News items</div>
... a list of local news, with editorial comment ...This example demonstrates how to implement a level 7 heading using role="heading" and the aria-level attribute. Since HTML only supports headings through level 6, there is no native element to provide these semantics.
...
<h5>Fruit Trees</h5>
...
<h6>Apples</h6>
<p>Apples grow on trees in areas known as orchards...</p>
...
<div role="heading" aria-level="7">Jonagold/div>
<p>Jonagold is a cross between the Golden Delicious and Jonathan varieties...</p>Resources are for information purposes only, no endorsement implied.
Examine each element with the attribute role="heading".
Determine whether the content of the element is appropriate as a heading.
If the element has an aria-level attribute, determine whether the value is the appropriate hierarchical level.
#2 and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA13. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide names for regions of a page that can be read by assistive technology. The aria-labelledby attribute provides a way to associate an section of the page marked up as a region or landmarks with text that is on the page that labels it.
Landmark roles (or "landmarks") programmatically identify sections of a page. Landmarks help assistive technology (AT) users orient themselves to a page and help them navigate easily to various sections of a page.
Like aria-describedby, aria-labelledby can accept multiple ids to point to other regions of the page using a space separated list. It is also limited to ids for defining these sets.
Below is an example of aria-labelledby used on a complementary Landmark. The region of the document to which the heading pertains could be marked with the aria-labelledby property containing the value of the id for the header.
<p role="complementary" aria-labelledby="hdr1">
<h1 id="hdr1">
Top News Stories
</h1>
</p>The following code snippet for application landmarks with static prose. If you have a regional landmark of type application and static descriptive text is available, then on the application landmark, include an aria-describedby reference to associate the application and the static text as shown here:
<div role="application" aria-labelledby="p123" aria-describedby="info">
<h1 id="p123">Calendar<h1>
<p id="info">
This calendar shows the game schedule for the Boston Red Sox.
</p>
<div role="grid">
....
</div>Resources are for information purposes only, no endorsement implied.
Examine each element with attribute role=region or with a landmark role, where an aria-labelledby attribute is also present.
Check that the value of the aria-labelledby attribute is the id of an element on the page.
Check that the text of the element with that id accurately labels the section of the page.
#2 and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA14. Also see WAI-ARIA Technology Notes.
For sighted users, the context and visual appearance of an element can provide sufficient cues to determine the purpose. An example is the 'X' often used in the top right corner of pop-up divs (light boxes) to indicate the control for closing the div.
In some situations, elements can be given the attribute aria-label to provide an accessible name for situations when there is no visible label due to a chosen design approach or layout but the context and visual appearance of the control make its purpose clear.
In other situations, elements can be given the attribute aria-label to provide an accessible name when the native HTML labeling element is not supported by the control - for example, when a div set to contentEditable is used instead of native form elements such as input type="text" or textarea in order to provide a richer text editing experience.
On a page, a link displays a pop-up box (a div) with additional information. The 'close' element is implemented as a button containing merely the letter 'x'. The property aria-label="close" is used to provide an accessible name to the button.
<div id="box">
This is a pop-up box.
<button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>
</div>Working example: Close button example.
<div role="group" aria-labelledby="groupLabel">
<span id="groupLabel>Work Phone</span>
+<input type="number" aria-label="country code">
<input type="number" aria-label="area code">
<input type="number" aria-label="subscriber number">
</div>Resources are for information purposes only, no endorsement implied.
For elements that use aria-label:
Check that the value of the aria-label attribute properly describes the purpose of an element where user input is required
#1 is true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA15. Also see WAI-ARIA Technology Notes.
The objective of this technique is to provide descriptions of images when a short text alternative does not adequately convey the function or information provided in the object.
A feature of WAI-ARIA is the ability to associate descriptive text with a section, drawing, form element, picture, and so on using the aria-describedby property. This is similar to the longdesc attribute in that both are useful for providing additional information to help users understand complex images. Like longdesc, descriptive text provided using aria-describedby is separate from the short name provided using the alt attribute in HTML. Unlike longdesc, aria-describedby cannot reference descriptions outside of the page containing the image. An advantage of providing long descriptions using content from the same page as the image is that the alternative is available to all, including sighted people who do not have assistive technology. It is worth noting that as of the time of writing (October 2013) some assistive technologies read aria-describedby content immediately after an image's alt attribute information without user activation - whereas most implementations of longdesc require the user to take explicit action to read the additional description.
Like aria-labelledby, aria-describedby can accept multiple ids to point to other regions of the page using a space separated list. It is also limited to ids for defining these sets.
The following example shows how aria-describedby can be applied to an image to provide a long description, where that text description is on the same page as the image.
<img src="ladymacbeth.jpg" alt="Lady MacBeth" aria-describedby="p1">
<p id="p1">This painting dates back to 1730 and is oil on canvas. It was created by
Jean-Guy Millome, and represents ...</p>Resources are for information purposes only, no endorsement implied.
Examine each image element where a aria-describedby attribute is present.
Examine whether the aria-describedby attribute programatically associates an element with its text description, via the id attribute on the element where the text to be used as the description is found.
Examine whether the combined text equivalent and associated text description accurately describe or provide the equivalent purpose to the object.
#1, #2, and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA16. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to provide names for user interface controls that can be read by assistive technology. WAI-ARIA provides a way to associate text with a section, drawing, form element, picture, and so on, using the aria-labelledby property. This techniques uses the aria-labelledby attribute to associate a user interface control, such as a form field, with text on the page that labels it.
Like aria-describedby, aria-labelledby can accept multiple ids to point to other elements of the page using a space separated list. This capability makes aria-labelledby especially useful in situations where sighted users use information from the surrounding context to identify a control. Using aria-labelledby to concatenate a label from several text nodes contains more examples of situations where names are created from several other text elements on the page.
While the function of aria-labelledby appears similar to the native HTML label element, there are some differences:
aria-labelledby can reference more than one text element; label can only reference one.
aria-labelledby can be used for a variety of elements while the label element can only be used on form elements.
Clicking on a label focuses the associated form field. This does not occur with aria-labelledby. If this behaviour is required then use label or implement this functionality using scripting.
Note that as of December 2013, label has better support than aria-labelledby, especially in older browsers and assistive technologies.
The following is an example of aria-labelledby used on a simple text field to provide a label in a situation where there is no text available for a dedicated label but there is other text on the page that can be used to accurately label the control.
<input name="searchtxt" type="text" aria-labelledby="searchbtn">
<input name="searchbtn" id="searchbtn" type="submit" value="Search">Below is an example of aria-labelledby used to provide a label for a slider control. In this case the label text is selected from within a longer adjacent text string. Please note that this example is simplified to show only the labeling relationship; authors implementing custom controls also need to ensure that controls meet other success criteria.
<p>Please select the <span id="mysldr-lbl">number of days for your trip</span></p>
<div id="mysldr" role="slider" aria-labelledby="mysldr-lbl"></div>The following example of aria-labelledby with multiple references uses the label element. For additional detail on concatenating multiple sources of information into a label with aria-labelledby, please view the technique Using ARIA labelledby to concatenate a label from several text nodes.
<label id="l1" for="f3">Notify me</label>
<select name="amt" id="f3" aria-labelledby="l1 f3 l2">
<option value="1">1</option>
<option value="2">2</option>
</select>
<span id="l2" tabindex="-1">days in advance</span>Note: The use of the label element is included for a number of reasons. If the user clicks on the text of the label element, the corresponding form field will receive focus, which makes the clicking target larger for people with dexterity problems. Also the label element will always be exposed via the accessibility API. A span could have been used (but if so, it should receive a tabindex="-1" so that it will be exposed via the accessibility API in all versions of Internet Explorer). However, a span would lose the advantage of the larger clickable region.
Resources are for information purposes only, no endorsement implied.
For each user interface control element where an aria-labelledby attribute is present:
Check that the value of the aria-labelledby attribute is the id of an element or a space separated list of ids on the web page.
Check that the text of the referenced element or elements accurately labels the user interface control.
#1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA17. Also see WAI-ARIA Technology Notes.
The objective of this technique is to mark up a set of related controls within a form as a group. Any label associated with the group also serves as a common label or qualifier for individual controls in the group. Assistive technologies can indicate the start and end of the group and the group’s label as one navigates into and out of the group. This is a viable alternative for grouping form controls programmatically when the user interface’s design makes it difficult to employ the fieldset-legend technique (H71).
For a group of radio buttons, one could also use role="radiogroup" instead of role="group".
The group can be labeled using aria-labelledby.
This technique is not meant for wrapping all controls on a form within a single container with role="group".
Social security number fields which are 9 digits long and broken up into 3 segments can be grouped using role="group".
<div role="group" aria-labelledby="ssn1">
<span id="ssn1">Social Security#</span>
<span style="color: #D90D0D;"> * </span>
<input size="3" type="text" aria-required="true" title="First 3 digits" />-
<input size="2" type="text" aria-required="true" title="Next 2 digits" />-
<input size="4" type="text" aria-required="true" title="Last 4 digits" />
</div>Working example: Multiple part field groups.
This example demonstrates use role=radiogroup. Note also that the radio buttons are custom controls with role=radio. (But the script to make the span actually work like radio buttons is not included in this example. ) One may optionally employ CSS to place a border around groups of such fields to visually reinforce the group relationship. The CSS properties are available below the form.
<h3>Set Alerts for your Account</h3>
<div role="radiogroup" aria-labelledby="alert1">
<p id="alert1">Send an alert when balance exceeds $ 3,000</p>
<div>
<span role="radio" aria-labelledby="a1r1" name="a1radio"></span>
<span id="a1r1">Yes</span>
</div>
<div>
<span role="radio" aria-labelledby="a1r2" name="a1radio"></span>
<span id="a1r2">No</span>
</div>
</div>
<div role="radiogroup" aria-labelledby="alert2">
<p id="alert2">Send an alert when a charge exceeds $ 250</p>
<div>
<span role="radio" aria-labelledby="a2r1" name="a2radio"></span>
<span id="a2r1">Yes</span>
</div>
<div>
<span role="radio" aria-labelledby="a2r2" name="a2radio"></span>
<span id="a2r2">No</span>
</div>
</div>
<p><input type="submit" value="Continue" id="continue_btn" name="continue_btn" /></p>Related CSS Style Definition to place a border around the group of fields :
div[role=radiogroup] {
border: black thin solid;
} Working example: using grouping roles to identify related form controls.
Resources are for information purposes only, no endorsement implied.
For groups of related controls where the individual labels for each control do not provide a sufficient description, and an additional group level description is needed:
Check that the group of logically related input or select elements are contained within an element with role=group.
Check that this group has an accessible name defined using aria-label or aria-labelledby.
#1 and #2 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA18. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to alert people that an input error has occured. Using role="alertdialog" creates a notification. This notification should be modal with the following characteristics:
aria-label or aria-labelledby attribute gives the alertdialog an accessible name.
aria-describedby provides a reference to the text of the alert.
The alertdialog contains at least one focusable control, and the focus should move to that control when the alertdialog opens.
The tab order is constrained within the alertdialog whilst it is open.
When the dialog is dismissed, the focus moves back to the position it had before the dialog opened, if possible.
Note that the alertdialog should not be present in a way that it will be accessed by AT until it is needed. One way to do this is not to include it in the static HTML and instead to insert it into the DOM via script when the error condition is triggered. The insertion would correspond to the following HTML sample.
This example shows how a notification using role="alertdialog" can be used to notify someone they have entered invalid information.
<div role="alertdialog" aria-labelledby="alertHeading" aria-describedby="alertText">
<h1 id="alertHeading">Error</h1>
<div id="alertText">Employee's Birth Date is after their hire date. Please verify the birth date and hire date.</div>
<button>Save and Continue</button>
<button>Return to page and correct error</button>
</div>Working example: Alert dialog.
Resources are for information purposes only, no endorsement implied.
(none currently listed)
Trigger the error that causes the alertdialog to appear.
Determine that the alertdialog contains at least one focusable control, and the focus moves to that control when the alertdialog opens.
Determine that the tab order is constrained within the alertdialog while it is open, and when the dialog is dismissed, the focus moves back to the position it had before the dialog opene, if possible.
Examine the element with role="alertdialog" applied.
Determine that either the aria-label or aria-labelledby attribute has been correctly used to give the alertdialog an accessible name.
Determine that the contents of the alertdialog identifies the input error.
Determine whether contents of the alertdialog suggests how to fix the error.
Checks 2, 3, 5 and 6 are true. For SC 3.3.3, Check 7 is also true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications (WAI-ARIA).
This technique relates to:
See User Agent Support Notes for ARIA19. Also see WAI-ARIA Technology Notes.
The purpose of this technique is to notify Assistive Technologies (AT) when an input error occurs. The aria-live attribute makes it possible for an AT (such as a screen reader) to be notified when error messages are injected into a Live Region container. The content within the aria-live region is automatically read by the AT, without the AT having to focus on the place where the text is displayed.
There are also a number of special case live region roles which can be used instead of applying live region properties directly.
The following example uses role=alert which is equivalent to using aria-live=assertive.
In the example there is an empty error message container element with aria-atomic=true and an aria-live property or alert role present in the DOM on page load. The error container must be present in the DOM on page load for the error message to be spoken by most screen readers. aria-atomic=true is necessary to make Voiceover on iOS read the error messages after more than one invalid submission.
jQuery is used to test if the inputs are empty on submit and inject error messages into the live region containers if so. Each time a new submit is attempted the previous error messages are removed from the container and new error messages injected.
<script src="http://code.jquery.com/jquery.js"></script>
<script>
$(document).ready(function(e) {
$('#signup').submit(function() {
$('#errors').html('');
if ($('#first').val() === '') {
$('#errors').append('<p>Please enter your first name.</p>');
}
if ($('#last').val() === '') {
$('#errors').append('<p>Please enter your last name.</p>');
}
if ($('#email').val() === '') {
$('#errors').append('<p>Please enter your email address.</p>');
}
return false;
});
});
</script>
<form name="signup" id="signup" method="post" action="">
<p id="errors" role="alert" aria-atomic="true"></p>
<p>
<label for="first">First Name (required)</label><br>
<input type="text" name="first" id="first">
</p>
<p>
<label for="last">Last Name (required)</label><br>
<input type="text" name="last" id="last">
</p>
<p>
<label for="email">Email (required)</label><br>
<input type="text" name="email" id="email">
</p>
<p>
<input type="submit" name="button" id="button" value="Submit">
</p>
</form>Working example: Using role=alert to identify errors.
Resources are for information purposes only, no endorsement implied.
(none currently listed)
Determine that an empty error container role=alert or aria-live=assertive attribute is present in the DOM at page load.
Trigger the error that causes the content in the live region to appear or update.
Determine that the error message was injected into the already present error container.
#1 and #3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
Technologies that support Accessible Rich Internet Applications.
This technique relates to:
This technique demonstrates how to assign a generic region role to a section of a page so that user agents and assistive technologies may be able to programmatically identify it. The region role demarcates a segment of the page that contains content of significance so that it is more readily discoverable and navigable. The generic region should be used when the section cannot be marked up using a standard document landmark role (see ARIA11: Using ARIA landmarks to identify regions of a page (ARIA)
).
It is important to name regions, because they are generic grouping elements and users will need some way to tell which region they are in. Regions can be named using aria-labelledby, aria-label, or another technique. Doing so helps to better expose content and information relationships on the page. The role of region should be used prudently, because if overused they can make the page overly verbose for screen reader users.
A section on the home page of a news website that contains a poll that changes every week is marked up with role="region". The h3 text above the form is referenced as the region's name using aria-labelledby.
<div role="region" aria-labelledby="pollhead">
<h3 id="pollhead">This week's Poll</h3>
<form method="post" action="#">
<fieldset>
<legend>Do you believe the tax code needs to be overhauled?</legend>
<input type="radio" id="r1" name="poll" />
<label for="r1">No, it's fine the way it is</label>
<input type="radio" id="r2" name="poll" />
<label for="r2">Yes, the wealthy need to pay more</label>
<input type="radio" id="r3" name="poll" />
<label for="r3">Yes, we need to close corporate loopholes</label>
<input type="radio" id="r4" name="poll" />
<label for="r4">Changes should be made across the board</label>
</fieldset>
</form>
<a href="results.php">See Poll Results</a>
</div>
A user can expand links on a bank website after logging in to see details of term deposit accounts. The details are within a span marked up with region role. The heading for the region has role=heading and is included in the aria-labelledby that names the region.
<ol>
<li><a id="l1" href="#" aria-expanded="false" title="Show details" aria-controls="block1" >John Henry's Account</a><img src="images/panel_expand.gif" alt="" />
<div id="block1" class="nowHidden" tabindex="-1" aria-labelledby="l1 cd1" role="region"><span id="cd1" role="heading" aria-level="3">Certificate of Deposit:</span>
<table>
<tr><th scope="row">Account:</th> <td>25163522</td></tr>
<tr><th scope="row">Start date:</th> <td>February 1, 2014</td></tr>
<tr><th scope="row">Maturity date:</th><td>February 1, 2016</td></tr>
<tr><th scope="row">Deposit Amount:</th> <td>$ 3,000.00</td></tr>
<tr><th scope="row">Maturity Amount:</th> <td>$ 3,072.43</td></tr>
</table>
</div>
</li>
</ol>
This example shows how a generic region landmark might be added to a weather portlet. There is no existing text on the page that can be referenced as the label, so it is labelled with aria-label.
Example Code:
<div role="region" aria-label="weather portlet">
...
</div> Resources are for information purposes only, no endorsement implied.
For each section marked up with role="region":
Examine the content and ensure that it is important enough to have an independent landmark
Ensure that a standard landmark role is not appropriate for this content
Check that the region has a programmatically determined name
Checks #1-3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.
HTML with Accessible Rich Internet Applications.
This technique relates to:
This technique demonstrates how aria-invalid may be employed to specifically identify fields that have failed validation. Its use is most suitable when:
The error description does not programmatically identify the failed fields
The failed fields are identified in a manner that is not available to some users - for example by using an error-icon rendered visually by some technique that does not rely on color such as a visual cue like a border.
Note: One of the above two situations may be true for a field which has programmatically associated label and / or instructions that conveys data format, a data range, or the required property.
While it is always preferable to programmatically associate specific error description with the failed field, the page's design or the framework employed may sometimes constrain the author's ability to do so. In these cases, authors may programmatically set aria-invalid to "true" on the fields that have failed validation. This is interpretable mainly by assistive technologies (like screen readers / screen magnifiers) employed by users who are vision impaired. When a field has aria-invalid set to “true”, VoiceOver in Safari announces “invalid data” when the field gets focus; JAWS and NVDA notify the error as an “invalid entry”.
This ARIA attribute has to be set / turned on programmatically. It should not be set to “true” before input validation is performed or the form is submitted. Setting aria-invalid to “false” is the same as not placing the attribute for the form control at all. Quite understandably, nothing is conveyed by assistive technology to users in this case.
When visible text is used to programmatically identify a failed field and / or convey how the error can be corrected, setting aria-invalid to "true" is not required from a strict compliance standpoint but may still provide helpful information for users.
The aria-invalid attribute is used on required fields that have no input. A message above the form conveys that form submission has failed due to this.
A portion of the jQuery code and the HTML form markup follow:
<code>
<script>
...
...
if ($('#first').val() === '') {
$('#first').attr("aria-invalid", "true");
$("label[for='first']").addClass('failed');
}
if ($('#last').val() === '') {
$('#last').attr("aria-invalid", "true");
$("label[for='last']").addClass('failed');
}
if ($('#email').val() === '') {
$('#email').attr("aria-invalid", "true");
$("label[for='email']").addClass('failed');
}
...
...
</script>
<style type="text/css">
label.failed {
border: red thin solid;
}
</style>
<form name="signup" id="signup" method="post" action="#">
<p>
<label for="first">First Name (required)</label><br>
<input type="text" name="first" id="first">
</p>
<p>
<label for="last">Last Name (required)</label><br>
<input type="text" name="last" id="last">
</p>
<p>
<label for="email">Email (required)</label><br>
<input type="text" name="email" id="email">
</p>
<p>
<input type="submit" name="button" id="button" value="Submit">
</p>
</form>
</code> Aria-invalid and aria-describedby are used together to indicate an error when the personal identification number (PIN), email address, or start date are not in the expected format. The error message is associated with the field using aria-describedby, and aria-invalid makes it easier to programmatically find fields with errors.
Below is the rendered HTML code for the email address field in Example 1: When an invalid email address is entered by the user such as "samexample.com" (instead of [email protected]), the HTML code is:
<div class="control">
<p><label for="email">Email address: [*]</label>
<input type="text" name="email" id="email" class="error" aria-invalid="true" aria-describedBy="err_1" /></p>
<span class="errtext" id="err_1">Error: Incorrect data</span></div>
And when no data is entered in the email field, the HTML code is:
<div class="control">
<p><label for="email">Email address: [*]</label>
<input type="text" name="email" id="email" class="error" aria-invalid="true" aria-describedBy="err_2" /></p>
<span class="errtext" id="err_2">
Error: Input data missing</span>
</div> jQuery code: jQuery is used to add aria-invalid or aria-describedby attributes as well as the class attribute and append the error text. This is the code that inserts aria-invalid and class="error" but does not associate the error text "incorrect data" with the control programmatically:
$(errFld).attr("aria-invalid", "true").attr("class", "error");
// Suffix error text:
$(errFld).parent().append('<span class="errtext">Error: Incorrect data</span>');
CSS Code:
input.error {
border: red thin solid;}
span.errtext {
margin-bottom: 1em; padding: .25em 1.4em .25em .25em;
border: red thin solid; background-color: #EEEEFF;
background-image:url('images/iconError.gif');
background-repeat:no-repeat; background-position:right;
}
Resources are for information purposes only, no endorsement implied.
For each form control that relies on aria-invalid to convey a validation failure:
Check that aria-invalid is not set to true when a validation failure does not exist.
Check that aria-invalid is set to true when a validation failure does exist.
Check that the programmatically associated labels / programmatically associated instructional text for the field provide enough information to understand the error.
Checks #1-3 are true.
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.