Overview of Name, Role, Value
Purpose
One of the most challenging requirements to consistently meet. This requirement ensures that people that rely on screen readers know the exact value, state, role and name of every control. Additionally this requirement includes the need to programmatically announce notifications of changes to the user interface.
How to Test
- Run an automated accessibility checker
- Any violations of “Buttons must have discernible text” or “form elements must have labels” are a failure of control does not provide role, state, and value information
- Any violation related to aria attribute are a failure of inaccurate role, state, or value information supplied
- Manual review with a screen reader can also find
Best Practices
Include accessibility in design
When creating specifications for new features call out the controls names, it’s role and it’s possible values. When dynamic content is expected explain what information should be exposed as a live region.
For example if a team wanted to replace a basic edit box and search button with a new design. They might request the existing Search edit box, provide a dynamically populated dropdown list of possible search terms. The design of this new feature should include if assistive technologies should be told about all the search options displayed OR a summary of the result. The summary could be something like “500 possible search terms start with ‘a’” down to “3 possible search teams start with ‘accessibil’”
Exceptions
None