Understanding 4.1.2 Name, Role, Value
"If custom controls are created, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies..."
This criteria applies specifically at web developers who script their own custom interface elements, which is an uncommon use case. If you're just using standard HTML elements, you'll resolve this criteria and be compliant by default. No manual intervention will be required, and you can stop reading right here!
The criterion's purpose is to ensure that your user will be able to easily interact with your custom controls when using assistive technologies such as screen readers or speech recognition software.
Assistive technology must be able to understand what your control elements do and how they change when used, including:
- The name of the element. In some cases, this is also the element's label.
- What the element does. For example, does it expand a collapsible menu?
- State changes. In particular, the user must know when the element is in focus.
By providing information on the role, state, and value information on all your custom user interface components, you'll ensure your interface is compatible with assistive technology.
There are many different ways you can include this information. Some developers insert markup language including aria-labels. Others might pull in accessibility APIs, such as the the Microsoft Active Accessibility (MSAA) API.
As you develop your custom programming, think about accessibility from the very beginning of your project. Identify how you want to ensure the name, role, and value of each element is included (either markup or an accessibility API). If you want to create an entirely new type of user interface component, you'll want to know that too, so you can code in your own accessibility provisions yourself.
Once you've developed your interface, you'll test it by:
- Visiting your web page using an assistive technology such as a screen reader.
- Checking that every interface component contains a name and role/
- Changing the value on each applicable component, and confirm that your tech is alerted to the value change (i.e. click an element to bring it into focus and make sure your screen reader caught the change).