Web checklist

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

The intent of this success criterion is to ensure that Assistive Technologies (AT) can gather information about, activate (or set) and keep up to date on the status of user interface controls.

When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.

Custom widgets not included in the (X)HTML host language but found in many Web applications, do not expose proper role, state and property information needed for assistive technologies. Therefore, it is often difficult for people with disabilities to identify and interact with them. When this information is not conveyed to assistive technologies, widgets created through the use of CSS and JavaScript are difficult if not impossible to identify and operate. Common examples are menus, trees, data grids, accordions, and dialogs. Embedding WAI-ARIA markup and implementing arrow key navigation in Web widgets enables people with disabilities to identify and interact with the widgets in the same way they identify and interact with desktop application widgets.

Back to top

Compliance with this checkpoint requires at least one of the following techniques to be met. These techniques are defined in the Level A Success Criterion for item 4.1.2 from the WCAG 2.0 checklist (link resides outside of ibm.com).

1. Markup to expose name and role: Use markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes.
2. Accessibility API to expose name and role: Use the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes.
3. Use components to support accessibility API: Create components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.
4. Allow user-settable properties: Expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

Examples for General developers

1. Markup to expose name and role: Use markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes.

To comply with this technique, the following example must be implemented.

Example 1

Please refer to WCAG 2.0 examples for using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes (link resides outside of ibm.com) for information on how to satisfy this technique.

2. Accessibility API to expose name and role: Use the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes.

To comply with this technique, at least one of the following examples must be implemented.

Example 1

If using a standard user interface component in a programming technology, refer to WCAG 2.0 examples for using accessibility API features (link resides outside of ibm.com).

3. Use components to support accessibility API. Create components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

To comply with this technique, the following example must be implemented.

Example 2

To create your own user interface component in a programming language, refer to WCAG 2.0 examples for creating components using a technology that supports the accessibility API (link resides outside of ibm.com) features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

4. Allow user-settable properties: Expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

There are no specific techniques for general developers.

Back to top

Examples for HTML developers

1. Markup to expose name and role: Use markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes.

To comply with this technique, at least one of the following examples must be implemented.

Example 3

HTML form controls and links are natively accessible, as long as the developer follows the HTML examples throughout the checkpoints in this checklist. When possible, developers are encouraged to rely on standard HTML form controls and links.

Example 4

Use label elements to associate text labels with form controls. This requirement is satisfied by completing technique #1 in checkpoint 1.3d Forms.

Example 5

Using the title attribute of the frame and iframe elements. This requirement is satisfied by completing technique #2 in checkpoint 2.4c Frames.

Example 6

Use the title attribute to identify form controls when the label element cannot be used. This requirement is satisfied by completing technique #1 in checkpoint 1.3d Forms.

Example 7

Using HTML according to spec. To verify that your pages fully conform to specifications, you should run your code through an automated validator and ensure that all HTML specification errors are corrected.

Please refer to WCAG 2.0 examples for using HTML according to spec (link resides outside of ibm.com) for more information.

Example 8

Until recently, screen readers generally had trouble reading frequently changing dynamic Web content such as stock ticker quotes or news feeds. Therefore, dynamic content was sometimes completely inaccessible to screen reader users. With the advent of WAI-ARIA live regions, Web application developers can easily make dynamic content accessible to screen reader users.

See the live region example in checkpoint 2.2b and Implementing Live Regions (link resides outside of ibm.com) in the WAI-ARIA Best Practices (link resides outside of ibm.com).

2. Accessibility API to expose name and role: Use the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes.

To comply with this technique, at least one of the following examples must be implemented.

Example 9

Note that WAI-ARIA examples are not supported by all browsers. If your product needs to be accessible in multiple browsers one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique.

Standard HTML controls expose role and state information to assistive technologies through the Microsoft Active Accessibility (link resides outside of ibm.com) technology. However, when standard HTML controls are repurposed into custom widgets such as trees, menus and grids, there is no mechanism to expose role and state.

WAI-ARIA provides a mechanism to expose custom widget role and state information by assigning role and state properties to standard HTML elements. For example, the following code fragment repurposes an HTML list into a tree by assigning a tree role to the <ul> element.The <li> element containing fruits is repurposed into a tree node by assigning a treeitem role to it. When a blind user navigates to the fruits node, a screen reader will say the fruits node is expanded.

<ul id="tree1" role="tree" tabindex="0">
<li role="treeitem" tabindex="-1" aria-expanded="true">
Fruits
</li>
...
</ul>

For more information on assigning roles and states to custom widgets, see the WAI-ARIA specification (link resides outside of ibm.com) and WAI-ARIA Best Practices (link resides outside of ibm.com).

3. Use components to support accessibility API: Create components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

There are no specific techniques for HTML developers.

4. Allow user-settable properties: Expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

There are no specific techniques for HTML developers.

Examples for Script developers

1. Markup to expose name and role: Use markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes.

To comply with this technique, the following example must be implemented.

Example 10

Use functions of the Document Object Model (DOM) to add content to a page.

If using script or code to re-purpose a standard user interface component in a markup language, refer to the WCAG 2.0 examples for Using functions of the Document Object Model (DOM) to add content to a page (link resides outside of ibm.com) when implementing this technique.

2. Accessibility API to expose name and role: Use the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes.

There are no specific examples for scripting developers.

3. Use components to support accessibility API: Create components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

There are no specific examples for scripting developers.

4. Allow user-settable properties: Expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes.

To comply with this technique, at least one of the following examples must be implemented.

Example 11

Use functions of the Document Object Model (DOM)

To use script or code to re-purpose a standard user interface component in a markup language, refer to the following WCAG 2.0 examples for using functions of the Document Object Model (DOM) to add content to a page (link resides outside of ibm.com) when implementing this technique.

Example 12

Custom dialog widgets developed with CSS and JavaScript do not expose correct role, state and property information to assistive technologies. Therefore, blind users often find it difficult to operate a dialog or to even know it is present when rendered (i.e., a screen reader doesn't tell a blind user that a dialog has appeared).

The following example demonstrates the use of the WAI-ARIA roles application, dialog and header to inform assistive technologies that the Javascript/CSS widget is a dialog. The WAI-ARIA aria-labelledby and level properties are also used to label the dialog and indicate that the label is a level one heading.

<p>Activate the button to render a dialog.<input id="dialogOpen" type="button" value="Show dialog" onclick="showDialog();"/>
</p>
<div role="application">
<div class="dialogContainer" id="dialogContainer" role="dialog" aria-labelledby="dialogLabel">
<div class="dialogBody" id="dialog1">
<div class="header">
<span class="headertext" id="dialogLabel" role="header" level="1">Personal information</span>
</div>
<form>
<div>
<label for="firstName">
First name:
</label>
<input type="text" id="firstName" name="firstName">
</div>
<div>
<label for="lastName">
Last name:
</label>
<input type="text" id="lastName" name="lastName">
</div>
<label for="phone">
Phone number:
</label>
<input type="text" id="phone" name="phone">
<div class="paddingTop"><input id="dialogClose" type="button" value="Submit" onclick="hideDialog();"/></div>
</form>
</div>
</div>
</div>

Back to top

Implementation of recommended techniques is not required to comply with this checkpoint, but these techniques should be reviewed since they can improve the accessibility and usability of the solution.

Please refer to the Additional Techniques (Advisory) for WCAG 2.0 guideline 4.1.2 (link resides outside of ibm.com)

Back to top

The following test tools and techniques are required to verify this checkpoint.

1. Test tools
2. Required accessibility verification test techniques

Back to top