Starting with Steve’s article ARIA Toggle Button and Tri-state Checkbox examples, we will be providing more examples about how to use ARIA roles and states in practice. As Steve mentioned, ARIA (Accessible Rich Internet Applications) is steadily gaining more support by all major browsers, now that Internet Explorer, Opera and Safari are all on board. Our aim is to demonstrate how simple adding ARIA can be.
In this article, I will be providing an example for the slider role.
Note: This post is the first in a series of three. Here I will cover the basic markup needed for adding ARIA information to a slider widget. The second post will focus on the additional accessibility factors to consider when creating sliders (such as focus, scalability, and progressive enhancement). Finally, the third post will demonstrate how to use two sliders to create double (ranged) sliders.
A Basic ARIA Slider Example
To see a working example of an ARIA slider, view the ARIA slider example.
This example contains a simple mockup for a volume control slider widget, composed using
a div element and a
button element The slider value ranges from 0 to 100%. Note that this for the purpose of keeping the example simple and focused on ARIA, this slider’s functionality has been kept very basic. More detailed and complex examples will be provided in my next post. The rest of the current article will discuss the ARIA related features of the example.
Applying a Role, and Where
To make an element be interpreted as a slider by assistive technology, you need to add the ‘role’ attribute with a value of ‘slider’.
So where do you have to apply this role? Sliders generally consist of two base components: the rail and the thumb. The user can change the slider’s value by dragging the thumb across the rail (or by using the keyboard to move it). However, as far as ARIA is concerned, you really only need one element to make a slider. This can be either the thumb element or the rail. The element you provide with the slider role is also the element that will need to be keyboard accessible (meaning that it must be part of the tab order and have key event handlers assigned to change the slider’s value).
For example, if we choose to give the slider thumb the role attribute, you could mark it up using the following code:
<button class="sliderThumb" role="slider"></button>
If we were to use the rail element, the role would be placed on the outer element instead. It is important to note that, in order to be keyboard accessible, only one element actually needs to be part of the tab order. To place both the thumb and the rail in the tab order would unnecessarily clutter it. In the following post I will discuss keyboard and focus related issues in more detail.
labeling and Describing
Like all form controls, sliders need to be identifiable by users. To label a slider, you can choose from the following approaches:
- Use the ‘aria-labelledby‘ property to point to the ID of an element containing the slider’s name.
- Use the HTML ‘title’ attribute to specify the name.
- Use an HTML ‘label’ element, and have it’s ‘for’ attribute point to the slider element.
All approaches cause the text to be exposed to the assistive technology. However, since we’re not only targetting screen readers, it is always required to have a visual label adjacent to the control, which cannot be achieved using the ‘title’ attribute alone.
One thing I have noted is that when using an image or image input element as a slider, its (required) ‘alt’ value will be incorrectly exposed as the slider’s name, regardless of specified ‘aria-labelledby’ or ‘title’ values. Also, IE8 beta 1 will incorrectly expose the image’s src attribute as the slider’s value, rather than the specified ‘aria-valuenow’ value. This unfortunately makes it harder to cater for users that are not ‘ARIA ready’, as you might want to use the alt attribute to specify additional information the users miss out on. For example, An image input control marked up as an ARIA slider could have the following alt text specified: “volume, 40 of 100%”. This text would then be read by screen readers and browsers not supporting ARIA, making the slider at least more readable. Since ARIA causes the ‘slider’ role to override the ‘push button’ role normally exposed by the image type input control, you would also expect the ‘alt’ value to be overridden by the chosen labeling method.
States and Properties
The following ARIA properties are required for a slider widget:
- The slider’s current value.
- The minimum of the value range
- The maximum of the value range
Additionally, you can use the ‘aria-valuetext‘ property, which exposes a more human readable value to the assistive technology. For example, instead of simply setting a slider’s aria-valuenow property to 50, the aria-valuetext property could be ’50 dollars’. This property is also crucial for sliders that have non-numeric values, which will be discussed in my next post.
As with all ARIA controls, you can specify the generic ‘aria-describedby‘ property to point to an element containing more detailed information, such as any constraints the slider might have.
The code example below shows the complete ARIA slider markup:
<p id="sliderDescription">Use the arrow keys to change the value.</p>
<button class="sliderThumb" role="slider" title="Volume"
aria-valuemax="100" aria-valuenow="20" aria-valuetext="20 percent">
The slider role is currently properly exposed by Firefox 1.5 and higher as well as Internet Explorer 8 beta 1. The aria-valuetext properly is supported by Firefox 3. I have not been able to confirm whether the ARIA is supported in Opera 9.5 beta, so if someone can tell me more about this I would like to hear it.
Below follows a list of commonly used assistive technology available for Windows:
- JAWS versions 7.1 to 9.0 recognize the slider role and value change, but will incorrectly announce every value as a percentage (such as
800%). Also, when using the ‘aria-valuetext’ property, JAWS will only read the value if that value actually starts with a number. Otherwise it will simply announce 0%. For example setting aria-valuetext to “9am” will cause JAWS to announce “9 percent”, but an ‘aria-valuetext’ value of “morning” will not be recognized.
- Window Eyes 5.5 and 6.1 Correctly announce both the role and value change correctly, including values set with ‘aria-valuetext’.
- NVDA also correctly announces the role as well as the value when it is changed.
- Zoomtext 9.1 announces the slider as a ‘custom control’, but does perceive the specified value correctly. However, the value is only announced when the slider receives focus, not when the value actually changes. Also, Zoomtext does not announce descriptions set with ‘aria-describedby’.