4.1.2 Name, Role, Value

MCS Accessibility Team

MCS Accessibility Team
Last Updated July 23, 2020

The following directions are part of a full step-by-step guide to making a HubSpot website WCAG 2.1 AA compliant. These recommendations are intended for websites managed on the HubSpot CMS but can be adapted for other content management systems.

LEVELA
Principle: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Guideline: Compatible
Maximize compatibility with current and future user agents, including assistive technologies.

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.

Note 1: 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.

View Official WCAG 2.1 Compliance Techniques

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

Recommended Solutions

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).

For more information, please visit the official W3C article: Understanding 4.1.2 Name, Role, Value


Questions?

Let us know if we can help you address this specific WCAG Recommendation.