Tech Notes
As a blind accessibility tester with 16 years of screen reader experience, the most frequent accessibility issue I encounter while using and testing digital assets on both mobile and web platforms is the violation of the “Name, Role, Value” guideline, which often poses some serious challenges to screen reader users as it essentially makes navigation a guessing game.
While we at AFB always champion usability over basic compliance, we also always root our findings in the Web Content Accessibility Guidelines (WCAG) as our foundation, and this particular accessibility guideline is fundamental to both the usability and compliance of a digital product.
The WCAG 2.1 success criterion for “Name, Role, Value” (4.1.2) is as follows: "For all user interface components, 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.”
Let’s break down what this actually means in real terms.
The aim of this rule is to make sure that assistive technology receives the necessary semantic information from all the interactive elements present on the page. Each element should have an accessible name (label or identity), role (usage, function, or purpose), value (current data entry), state, and property, all of which enable assistive technology users to interact with these elements.
The rule is mostly violated when custom controls are used that do not expose the expected information to user agents and assistive technology.
Common Issues
Here is a list of some commonly reported accessibility issues and challenges that are caused by “Name, Role, Value” violations:
Name: the control is missing the name/label; e.g., an unlabeled button, checkbox, radio button, or menu.
Role: the control is missing the role attribute and is not announced as a control by the screen reader; e.g., button, checkbox, radio button, link, and menu.
Value: the control is missing the value or state attribute and, therefore, does not announce the state of the control when activated; e.g., the screen reader is unable to inform the user about the state of the toggle button, radio button, checkbox, or menu.
For example, suppose you’re shopping for shoes online. Next to a product, you might see a “Plus (+)” button. This example presumes a sighted user would know that the “Plus (+)” button meant “add an item to the cart” due to the visual page layout or grouping. Because that visual grouping would not be directly conveyed to the user by the screen reader, we need an aria-label attribute to make the intention clear. That would look something like:
<button aria-label= “Add to cart” > + </button>
Name: Add to cart
Role: Button, provided by the button tag
Value: Not applicable
Note: This button does not have value or state. A toggle button, for example, would include the value, or state of the button (that being “pressed” or “not pressed”).
General Tips
Use native HTML elements wherever possible.
Use WAI-ARIA attributes while constructing custom controls, components, and widgets.
Provide the tabindex="0" attribute for custom controls and widgets so that they correctly receive the tab focus
Make sure custom controls and widgets are keyboard operable using “Tab,” “Spacebar,” and “Enter” keys. These are the keyboard keys that are generally used to interact with most controls.
Make sure to read ARIA specifications to understand the implications and consequences of ARIA roles, states, and properties before using them.
This all may look like a lot of work on the development side. However, if you use the native HTML button element, all these features are provided by default, and no extra code is required. It is only required when some features cannot be coded using standard HTML which require WAI-ARIA to provide the necessary name, role, value, state, and other related attributes. This could include features like tab controls, expandable content, and modal dialogs. It is also commonly encountered when using highly customized libraries for front-end frameworks like React and Angular.
Therefore, our overall best advice is to avoid reinventing the wheel, and let the framework do the work for you as much as possible.
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.
