All interactive components must have an accessible name and role, and the state of the component must be communicated to assistive technologies. This ensures that screen reader users understand the purpose (role) of every component, how to identify it (name), and what state it is in.
Accessibility Requirements for 4.1.2 Name, role, value (A)
- All interactive elements and components have an accessible name;
- All interactive elements and components have a role (either implicit or explicit);
- All interactive elements and components communicate information about their state.
Common mistakes for 4.1.2 Name, role, value (A)
- An
<a>or<button>element contains no text content, and so has no accessible name; - A form field has no associated
<label>element, and so has no accessible name; - A set of tabs is created using
<ul>,<li>, and<a>elements, but ARIA has not been used to provide thetablist,tab, andtabpanelroles; - An
<a>element has been used as the basis for a button, but the ARIAbuttonrole has not been applied; - A button is used as the trigger to disclose content, but the
aria-expandedattribute has not been used to communicate the disclosure component’s current state; - A
<div>or<span>has been used as the basis for an interactive component, but ARIA has not been used to identify the purpose of the component (or its constituent parts).
Techniques for 4.1.2 Name, role, value (A)
HTML Technique
- H91: Using HTML form controls and links
- H44: Using label elements to associate text labels with form controls
- H64: Using the title attribute of the frame and iframe elements
- H65: Using the title attribute to identify form controls when the label element cannot be used
- H88: Using HTML according to spec
Common Failures for 4.1.2 Name, role, value (A)
The following are common mistakes that are considered failures of Success Criterion 4.1.2 by the WCAG Working Group.
- F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
- Note: This failure may be solved in the future using DHTML roadmap techniques.
- F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
- F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
- F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
- F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
- F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
- F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link
FAQS for Name, role, value
How to test this success criteria?
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).
What are standard web specification for this guidelines?
1.Every control has a name or label
2. Role of each control e.g. pull down menu, link, radio button, etc. is identified
3.The state of each control is visible and announced by AT
notifications about changes of focus are made to AT, such as -whether or not the control has focus.
-whether or not a control option is selected
-which option was selected, such as a checkbox, radio button, or if a collapsible list is expanded or collapsed.