20. UI Control Role, Name, State & Options

Use standard user input controls (e.g. HTML form controls, Flash accessible components) for their intended purpose or, if no appropriate standard controls exist, create or repurpose controls so that screen readers present the role, name, current state (including changes in state) and available options.

Rationale

When you choose to include a standard user interface element in a piece of media, it comes with much more than is seen by the typical user. For example, in HTML if you place a set of radio buttons on the screen, screen reader users will hear what the control is, how many options there are, what the options are*, which option is currently selected and which option has focus. In addition, screen reader users can work through the screen reader to select an option.

When we create custom UI components, we need to ensure that the same information is available and that the same interactions can take place.

*Requires proper labeling, see Pearson Guideline 14

General Techniques

Use standard controls, when they meet the need

When possible, use a pre-existing standard UI control. These will work well in more assistive technologies than you’ll be able to test in, and users will be used to using them.

When creating a custom UI control or evaluating/fixing a custom UI control from a Library:

• Give each control a name or label much like the labels used for standard form controls, as described in Pearson Guideline 14. Test with a screen reader to be sure the name or label is available to the screen reader.
• Indicate the role of each control. In other words, indicate what type of UI control it is (e.g. pulldown menu, link, radio button). This provides insight into how the control will be used and, in the best cases, allows screen readers to walk users through the process of using the control. Test with a screen reader to be sure this information is available to the screen reader.
• Indicate the state of each control. In other words, indicate which option is currently selected. Test with a screen reader to be sure that screen reader users will know the state of the control.
• Make sure the list of options is available to screen reader as well. Test with a screen reader to be sure the options are available and can be selected through a screen reader.

HTML & JavaScript

When standard HTML elements are used creatively

Often CSS and images are used with form elements, image maps and links to create controls that appear to be custom widgets, but that are actually standard HTML elements. For example, a piano interface can be created using a simple image map:

<map name=“piano”>
<area shape=“rect” coords=“20,20,40,40” onclick=“play(‘c’);” alt=“C”>
<area shape=“rect” coords=“50,20,70,40” onclick=“play(’d’);” alt=“D”>
<area shape=“rect” coords=“80,20,100,40” onclick=“play(‘e’);” alt=“E”>
<area shape=“rect” coords=“110,20,130,40” onclick=“play(‘f’);” alt=“F”>
<area shape=“rect” coords=“140,20,160,40” onclick=“play(‘g’);” alt=“G”>
</map>
<img src=“piano.gif” width=“180” height=“60” alt=“Select a note to play the note” usemap=“#piano” />

Whenever using HTML/XHTML elements in unique ways, follow basic accessibility standards, like adding alt-text and form labels. Also, be sure to test the experience with a screen reader. In the example above, testing with a screen reader and user testing with screen reader users reveals that many users would like to turn off the alt-text for each key, once they’ve read through the keys a couple times. To do this, you can position a link for this off screen so that it will be available only to screen reader users:

.screen_readers_only {
position: absolute;
left: -999px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}

Connect the link to a JavaScript that uses the DOM to set the alt-text for each area element to null.

Links that make changes to the page | Toggle buttons

Sometimes seemingly simple links can be custom controls requiring role and state information.

Normally, a link brings you to a new location. When this is the case, the role information that automatically comes with a link is appropriate and no state information is needed.

Role

However, if a link is used with JavaScript to make changes to the page, it may need both role and state information. There are several ways to provide role information for this type of link or button:

• The link text might make this clear on it’s own. For example a screen reader will read an a href element with link text of “Show Details about Registration”, as “Show Details about Registration Link”. That makes the situation pretty clear.

• A <button> or an <input type=“image”> element can be used instead of a link element. This will cause screen readers to announce a role of “button” rather than a role of “link”. This more accurately describes the control and helps to let screen reader users know what to expect. This is a particularly good idea if this item looks like a button visually. This will help facilitate conversations about the user interface between blind and sighted users. You can control the appearance of the HTML button element using CSS:

  button.clearformatting {
  /* remove browser-provided 3d edge effect /
  border: 0;
  / remove extra spacing, and animated effect /
  padding: 0;
  / remove color assigned by browser /
  background: transparent;
  / add any formatting you like */
  background: url(‘button_texture.gif’) repeat;
  }

• Another option if you’d like your element announced as a button, but you are using a link, is to use the WAI-ARIA role attribute to change an <a href> element’s role to button: role=“button”.

State

Links and buttons that change the page often require state information. In general, ask yourself, “Will users know which choice is currently active, without exploring the page, and without trying options multiple times to compare the differences?” If the answer is “no”, you need to add state information.

There are several ways to provide role information for this type of link or button:

• CLEAN UP The example above suggests adding a link that toggles alt-text on and off for some piano keys. In this case, the script that toggles the alt-text on and off should change the link text to reflect the current state (i.e. “turn off alt-text”, “turn on alt-text”).
• ARIA
• Finally, you might choose to use a completely different type of control! Consider again, the controls to turn off alt-text for piano keys in the example described above. Two radio buttons might be used, instead, as these standard HTML form elements automatically provide information about their state to screen readers. For example, a screen reader would present this set of radio buttons as “radio button, one of two, alt-text on, checked”.
• If you need to create a complex custom UI element, check JavaScript libraries to see if someone has already developed and tested an accessible UI control that meets the need. Libraries to check include:Be sure that the documentation indicates that the specific item is accessible & still be sure to test with a screen reader.
  • http://wiki.fluidproject.org/display/fluid/Components
  • http://www.dojotoolkit.org/developer/a11yStatement
  • http://developer.yahoo.com/yui
  • www.mozilla.org/access/dhtml
  • http://jquery.com/
• Do not use inaccessible components of JavaScript libraries without adapting them for accessibility. Keep in mind, if the component is not accessible, using a library can make it more difficult to add accessibility. This is because the JavaScript code used in libraries is often more complex than JavaScript written especially for the task at hand.

ARIA / HTML 5 Widgets

This section will be updated with additional widgets as testing confirms that the HTML 5 and the Web Accessibility Initiative, Accessible Rich Internet Applications (WAI-ARIA) elements and attributes are well supported.

Slider / Range

Sliders are user interface controls that allow users to select a value from a range of values. Sliders define minimum and maximum values.

Eventually, the HTML 5 <input type=“range”> element will be a way to create a slider. However, as November 2012, most browsers render these as simple text inputs. (That’s for all users.)

So, for now, sliders are usually created using JavaScript or using JavaScript libraries. To make these custom controls accessible, use WAI-ARIA (or a library that uses WAI-ARIA). (And don’t forget to make the slider keyboard accessible. You should be able to tab to the slider, and use the arrow keys to change the value.)

Here are the WAI-ARIA attributes to use:

role=“slider”	Says, “this is a slider”
value-now=“5”	Gives the current value. Use JavaScript to update this as the slider is moved.
value-min=“0”	Says, “this is the lowest value allowed”. This value shouldn’t change as the slider is used.
value-max=“176”	Says, “this is the highest value allowed”. This value shouldn’t change as the slider is used.
value-text=“5 balloons”	Use this to tell screen readers how you’d like the value-now value to be expressed.
aria-label=“Mylar balloons for your party” or aria-labelledby=“idOfOnScreenLabel”	Use this to tell screen readers users which slider this is.

Here are JavaScript Library Sliders that already have these built in:

• Open info on Glow Slider in a new window
• Open info on jQuery UI Slider in a new window

Android Applications

The role, name, state and options are provided for standard widgets and extensions of standard widgets. Use contentDescription to provide role and changes of state information for custom controls.

See Android's Custom View documentation for information on supporting the directional controller and on how to implement the accessibility API methods.

iOS Applications

In iOS native UIKit views and controls will automatically have most of the necessary accessibility properties set. See UIKit User Interface Catalog for specific information about the different views and controls and what is required to make them accessible.

Custom accessible interface elements, should define the attributes for label, traits, and value as needed for the type of interface element. If additional information is needed to communicate how to interact with a control, use the accessibilityHint property.

• Label – defines the name of the control
• Traits – describes element’s state, behavior or usage. A control can have more than one trait. View the full list of traits.
• Value – current value of an element
• Hint - additional information about a control

Flash

CheckBoxes and RadioButtons

When using Flash CheckBox and RadioButton Components, you need to include enableAccessibility so that screen readers will know these are not just buttons, but are RadioButtons or CheckBoxes and so that screen readers will convey the state of the control (e.g. checked/unchecked). This code varies slightly depending on your authoring environment, so get the code from the code library of your particular authoring tool. Here are the steps in CS3:

1. Window
2. Actions
3. (if needed) Show Toolbox
4. fl.accessibility (or similar)
5. Open the folder for the component you used.
6. Drag “enableAccessibility” into the code window.

To make fully accessible checkBoxes and radioButtons, see also Pearson Guideline 14, which discusses providing labels for form controls.

Testing HTML

Testing technique	Description
Tools	Review the page to see if there are any custom widgets, such as icons that open and close sections of the document or form controls that are not standard HTML controls. They might be created in Flash or through custom HTML and JavaScript. One clue is that, when you test for Pearson Guideline 14, these won’t be hightlighted by the form labels favelet. If there are custom widgets, test the interactions with at least JAWS, and ideally with other screen readers as well.
Output	If things are going well, JAWS will announce all information needed to use the custom widget: Role of the Widget–What is this? examples: group of radio buttons, timer Name of the widget–What is this being used for on this site? examples: select car color, time quiz State of the widget–What option is selected or what is the widget like right now? examples: blue selected, timer running Available options–What are my choices? examples: blue|silver|black, stop|restart|pause|resume Alternatively, if things are not going well, the widget will visually reveal its role, name, state and options, but some of this essential information will not be announced in JAWS.
Analysis	Will a screen reader user have the information needed to use the widget? If not, this is an error.

Testing Mobile Applications

Testing technique	Description
Tools	Review the screen and identify the different types of user interface controls used. Use the device screen reader (VoiceOver on iOS and TalkBack on Android) to read the controls.
Output	If things are going well, the screen reader will announce all information needed to use the custom widget: Role of the Widget–What is this? examples: group of picker control, segmeneted control Name of the widget–What is this being used for on this site? examples: visible control text label State of the widget–What option is selected or what is the widget like right now? examples: blue selected, students selected 1 of 2 Available options–What are my choices? examples: blue|silver|black, students|instructors Alternatively, if things are not going well, the widget will visually reveal its role, name, state and options, but some of this essential information will not be announced in screen reader.
Analysis	Will a screen reader user have the information needed to use the widget? If not, this is an error. Note: Android applications are limited in the roles, states and options that can be programmatically set. If these are not being read, this information should be added the control label.

Related Guidelines

508 Web 1194.22 (l)

When pages utilize scripting languages to display content or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

508 Software 1194.21 (d)

Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.

WCAG 2.0 Level A – SC 4.1.2 Name, Role, Value:

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. (Level A)

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