Develop - user input
A critical accessibility failure occurs when there is no programmatic connection between related content, such as between an input and its label. Since users with limited vision cannot see the proximity between label and input, the developer must make the connection clear in the programming. Similar considerations apply for other content, such as the connection between an error message and the relevant form field.
Level 1
Associate labels with inputs
What to do
Designers should connect each label and input in the wireframes. The developer’s job is to use appropriate techniques to make that connection programmatically.
Techniques
- H44: Using label elements to associate text labels with form controls
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- ARIA17: Using grouping roles to identify related form controls
- H65: Using the title attribute to identify form controls when the label element cannot be used
- H71: Providing a description for groups of form controls using fieldset and legend elements
- H85: Using OPTGROUP to group OPTION elements inside a SELECT
- ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls
Requirements and resources
- 1.3.1 Info and Relationships, IBM accessibility requirements
- 3.3.2 Labels or Instructions, IBM accessibility requirements
- Labeling controls, W3C web accessibility tutorials
What to do
Sometimes an input element doesn’t have a visible label. Multi-line address fields and telephone numbers are the most common examples. The content designer should . The developer’s job is to use ARIA or another technology to programmatically assign the accessible name to the element.
Techniques
- ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- H65: Using the title attribute to identify form controls when the label element cannot be used
- G211: Matching the accessible name to the visible label
Requirements and resources
- 4.1.2 Name, Role, Value, IBM accessibility requirements
- Labeling controls: hiding label text, W3C web accessibility tutorials
Programmatically associate inputs with labels
Add accessible names for inputs lacking visible labels
Provide correct name, role and value
What to do
Sometimes developers repurpose standard HTML elements to build elements that are not available in HTML. In such cases, ARIA is used to give the repurposed elements a new role. Use the
aria-labelledby
property to provide the name, or programmatic label, of the ARIA element by associating it with the visual label on the HTML element.The following code fragment repurposes an HTML list into a tree by assigning a tree role to the
<ul>
element. The<li>
element containing fruits is repurposed into a tree node by assigning a role=“treeitem” attribute to it. When a blind user navigates to the fruits node, the screen reader announces that the fruits node is expanded.<div id="tree1" role="tree" tabindex="0"><li role="treeitem" tabindex="-1" aria-expanded="true" aria-selected="true" onkeydown="navKey"> Fruits </li>...</div>Pro tip: Using ARIA also means you must implement keyboard access. Make sure the element is reachable by keyboard and all functionality is operable by the keyboard.
Techniques
- ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
- ARIA16: Using aria-labelledby to provide a name for user interface controls
Requirements and resources
- 4.1.2 Name, Role, Value, IBM accessibility requirements
- Design patterns and widgets, ARIA authoring practices
- Naming with referenced content via aria-labelledby, ARIA authoring practices
- What is WAI-ARIA, Mozilla Developer Network
What to do
Custom components may not expose proper role, state, and property information needed for assistive technologies. As a result, people with disabilities have difficulty identifying and interacting with them. Common examples are menus, trees, data grids, accordions, and dialog boxes.
All custom interactive user interface components need accessibility markup so that assistive technologies can programmatically obtain the role, name, value, and states of the element. ARIA is used to provide the markup which is well supported in modern browsers. Choose the role that best relates to the interaction in the design. The name of the element comes from the content design. Use the ARIA authoring practices for implementation guidance on custom components.
<!-- The following code fragment creates a toolbar widget by assigning a --><!-- toolbar role to a <div> incorporating three HTML buttons. Note, this --><!-- example does not show the keyboard event handling required to make --><!-- the toolbar fully keyboard accessible. --><div class="format" role="toolbar" aria-label="Text formatting" aria-controls="textarea1"><button type="button" class="item bold popup" aria-pressed="false" value="bold" tabindex="0"><span class="fas fa-bold" aria-hidden="true"></span><span class="popup-label">Bold</span></button>Pro tip: Using ARIA also means you must implement keyboard access. Make sure the element is reachable by keyboard and all functionality is operable by the keyboard. Any time a keyboard event handler is added to a non-form or non-anchor element (e.g.
<div>
or<ul>
), it must have a valid ARIA role.Techniques
- ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
- ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
- ARIA16: Using aria-labelledby to provide a name for user interface controls
Requirements and resources
- 4.1.2 Name, Role, Value, IBM accessibility requirements
- Design patterns and widgets, ARIA authoring practices
- Naming with referenced content via aria-labelledby, ARIA authoring practices
If repurposing a standard component, use ARIA to set the correct name and role
On custom components, use ARIA to expose name, role, and value
Level 2
Reduce conflict between the visible label and a component’s accessible name
What to do
When using ARIA to provide an accessible name for a UI element, be sure it exactly matches the visible label. Doing so will enable users of voice control software to speak the visible label to navigate to the element.
If you need additional accessibility information in the label, .
Techniques
Requirements and resources
- 2.5.3 Label in Name, IBM accessibility requirements
What to do
Take care when using
aria-label
oraria-labelledby
to provide the accessible name. Be sure to include the text of the visual label, exactly as it appears, in the accessible name - preferably in the beginning. If done incorrectly, a low vision user sees one label in the UI and hears a different name from the screen reader, which is confusing.Techniques
Requirements and resources
- 2.5.3 Label in Name, IBM accessibility requirements
Match the accessible name to the visible label
Include the text of the label in the accessible name
Level 3
Efficient and effective user input
What to do
Users with some cognitive disabilities benefit from the ability to paste passwords and one-time verification codes during authentication. This allows the use of password managers and other mechanisms. Developers should not prevent pasting into such inputs, which forces users to recall passwords or transpose information, both of which constitute cognitive function tests.
Techniques
- H100: Providing properly marked up email and password inputs
- H98: Using HTML 5.2 autocomplete attributes
Requirements and resources
- 3.3.8 Accessible Authentication, IBM accessibility requirements (7.3 only)
- Let them paste passwords", UK's National Cyber Security Centre
Related toolkit topics
- Authentication, Design - UX
What to do
Users with some cognitive disabilities can benefit when common input fields are automatically populated with their default values. In HTML, use the autocomplete attributes to identify the purpose of the field so that the automated input will be correct.
Techniques
Requirements and resources
- 1.3.5 Identify Input Purpose, IBM accessibility requirements
- Input purposes for user interface components, WCAG
- The HTML autocomplete attribute, Mozilla Developer Network