Skip to main content

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

Provide correct name, role and value

    If repurposing a standard component, use ARIA to set the correct name and role

  • 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>

    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.

    Requirements and resources
  • On custom components, use ARIA to expose name, role, and value

  • 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>

    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.

    Requirements and resources

Level 2

Reduce conflict between the visible label and a component’s accessible name

    Match the accessible name to the visible label

  • 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, .

    Requirements and resources
  • Include the text of the label in the accessible name

  • What to do

    Take care when using aria-label or aria-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.

    Requirements and resources

Level 3

Indicate the purpose of common inputs