Tech Notes
In order for an assistive technology user to be able to identify every necessary aspect of an element on a website/application, this element needs to have their name, role, and values properly implemented through the respective markup language (commonly HTML). This is because the screen reader receives the information about each element that will be announced to the user through these name, role, value properties. So it is important to make proper use of HTML semantics and utilize HTML attributes and tags accordingly.
This might seem simple enough, but name, role, value issues are one of the most common issues you will run into when testing for accessibility. This is often because of the use of custom controls (such as non-standard HTML controls) that do not expose the name, role, or value properties to assistive technologies. These custom controls can be made accessible in different ways, but we will focus on WAI-ARIA as it is the most widely accepted way of handling custom controls. Through the use of ARIA attributes, you can customize a website/application element further than with HTML. But doing this can complicate the element, and HTML will not be enough to define its name, role, and value. Therefore, a developer will have to use ARIA to ensure that the proper name, role, and values are being conveyed. Because of this, a developer who uses ARIA needs to properly understand the specifications and consequences behind using ARIA.
When designing an element on a website, it is always important to note WCAG’s 4.1.2 success criteria: “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.” Its definition can be boiled down to making sure that assistive technologies receive all necessary semantic information from all interactive elements on a page.
What Are Names, Roles, And Values?
Name:
The identifier to a component that can be interpreted by assistive technology. For example, the text on a button, label on an input field, or link text for a hyperlink.
When trying to identify the name of a component, ask yourself: What is this component called? What does it refer to?
Role:
The function of a component that can be interpreted by assistive technology. For example, links, buttons, checkboxes, headings, radio buttons, alerts, etc.
When trying to identify the role of a component, ask yourself: What is the purpose of this component?
Value:
The state or input of a component that can be interpreted by assistive technology. For example, a checkbox’s current state, an edit field’s input, carousel value, video player value, date picker value, etc.
When trying to identify the value of a component, ask yourself: What is the current state or input of the component? It is important to note that value is not always applicable for a component, such as a button or link. These elements do not take an input or have their state change, so the value cannot be examined here.
HTML Examples
Name, Role, and Value for a HTML Button:
<button>Add to cart</button>
Name: Add to cart
Role: Button (provided by the button tag)
Value: Not applicable
Note: You can also use WAI-ARIA to do something similar:
<button aria-label= “Add to cart” > + </button>
In this context, ARIA allows the screen reader to interpret the name of this element as “Add to cart” while representing this element visually as a “plus” sign. It is important to note the difference this makes between a screen reader user and a sighted user when they encounter this element. A screen reader user will miss out on the visual “plus” indication but will hear an announcement from the screen reader that this is an “Add to cart” button. While a sighted user will miss out on the “Add to cart” aspect of this element, and this aspect is implied through the visual plus symbol.
Name, Role, and Value for a HTML Checkbox
<input type="checkbox" id="subscribe">
<label for="subscribe">I would like monthly email updates</label>
Name: I would like monthly email updates
Role: Checkbox (provided by the input “checkbox” tag)
Value: Checked or unchecked
Note: The “id” and “label for” attributes are used to establish a relationship between the label and the checkbox, allowing the screen reader to interpret and announce the checkboxes value.
General tips
- Be sure to provide meaningful and descriptive names for components. Names/labels are great for providing context to components.
- Name, role, value issues are quite common. If a screen reader does not announce its current value, the element's purpose, or name/label, you’ve encountered a name, role, value issue.
- Roles can be considered implicit or explicit. An implicit role is automatically assigned to some HTML elements based on their semantic meaning. For example
<header>
,<footer>
,<article>
, etc. Explicit roles are explicitly defined using ARIA attributes, and can allow developers to properly define an element's role when the default implicit role is not accurate enough.
About AFB Talent Lab
The AFB Talent Lab aims to meet the accessibility needs of the tech industry – and millions of people living with disabilities – through a unique combination of hands-on training, mentorship, and consulting services, created and developed by our own digital inclusion experts. To learn more about our internship and apprenticeship programs or our client services, please visit our website at www.afb.org/talentlab.