4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), 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. (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Requirements

• All interactive components have an ‘Accessible Name’;
• All interactive components communicate what type of component they are to assistive technologies;
• All interactive components communicate information about their state.

Why?

Summary

• The code should enable assistive technologies to understand the name, role and state of every interactive UI component.
• Every user interface components that users can interact with should convey an ‘Accessible Name’, what type of component it is (for example “tab”, “switch” or “heading”), and its current state to assistive technologies.
• Native elements (meaning elements that come out of the box in HTML, iOS and Android) generally provide roles/traits and properties by default. But custom-built elements will require all accessibility roles/traits and properties to be set.

Common mistakes

• 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 <iframe> element used in the source code of the page doesn’t include a title attribute that accurately describes the frame content.
• Using ARIA role without implementing the keyboard support that is implied that by role 
• A set of tabs is created using <ul>, <li>, and <a> elements, but ARIA has not been used to provide the tablist, tab, and tabpanel roles;
• An <a> element has been used as the basis for a button, but the ARIA button role has not been applied;
• A button is used as the trigger to disclose content, but the aria-expanded attribute 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).

Design Guide

Examples for Android

Since the Android framework has baked-in accessibility in its default widgets, you should always try to extend these whenever possible. If a custom view is absolutely necessary, you need to make it accessible. If you don’t, a service like TalkBack will skip it entirely, badly degrading the experience for users.

Complex views that act as containers require special attention, since children need separate focus, clickable actions, etc.

Here are some APIs for making custom views accessible:

• Android provides the AccessibilityNodeProvider class, which helps you expose virtual view hierarchy, and allow for the exploration and control of subcomponents.
• The ExploreByTouchHelper class helps with support in custom views that represent a collection of view-like logical items, and it simplifies many aspects of providing information to accessibility services and managing accessibility focus.
• The AccessibilityDelegate class targets widget developers who extend basic views and want their applications to be backwards compatible.

Examples for Flutter

Flutter deals with assistive technologies like screen readers using the Semantics() widget.

If a widget does not have a ‘Accessible Name’ by default then use Semantics().

The Semantics() widget has many properties for adding semantics that can be read by a screen reader but for a custom one use label as shown below.

Semantics(
    lable: String, // lable for a custom semantic name
    child: // widget in need of semantics
)

Examples for Web

Requirement 1: Ensuring that UI components have an accessible name

Every user interface components that users can interact with needs to have a name that assistive technologies (like screen readers or speech-input software) can understand.

That name is called the ‘Accessible Name’. (In the official Web Content Accessibility Guidelines, that name is just called ‘name’).

For example:

• In a ‘Submit’ button, the text ‘Submit’ provides the name of the button.
• The name of a button represented by a magnifying glass icon might be ‘Search’. In this example, the word ‘Search’ name might not be visible on the screen, but the button still needs a name. That name can be set in code (using aria-label for the Web for example).

Where does the ‘Accessible Name’ of a UI components come from?

An interactive UI component might be given an Accessibility Name in a number of ways:

• from its content (like in the ‘Submit’ button example above);
• from a visible label it is associated with in code (in HTML this might be by associating an input element with a label element, or by using aria-labelledby);
• from a property set in code (like aria-label=”Search”).

For <iframe> elements

• Any <iframe> element used on the page should include a title attribute that accurately describes the frame content (e.g. “Travel form”).
  • This is important because some browsers and screen reader combinations won’t recognise the iframe content page’s <title> element as a source for the iframe’s ‘Accessible Name’ on your page

Requirement 2: Ensuring that Assistive Technologies can understand what type of component a UI component is

Coding of user interface components using native HTML controls

• Links, buttons and form fields should be implemented as native HTML controls (e.g. <a>, <button>, <input>, <select>), rather than as custom controls (e.g. using <div>, <span> elements and scripting that replicated the built-in behaviour of native HTML controls).
• When standard HTML controls do not exist (and only then), use generic HTML elements and provide equivalents via ARIA and via a method that does not require ARIA.

ARIA use case 1: If you need to fix HTML that has the wrong (or missing) semantics

Most HTML elements have an implied ‘role’, that communicate what type of component it is to Assistive Technologies. For example:

• a button element has an implicit role of button;
• an a element with an href attribute has an implicit role of link;
• a li element has an implicit role of listitem;
• a dd element has an implicit role of definition;
• some HTML elements like div and span do not convey any role to assistive technologies.

If incorrect HTML element was used to build a component, or if a div or span has been used where something more meaningful like a button or a href="..." should have been used, you can do two things:

• In almost every case, the best response is to fix the HTML if you can, so it conveys the right semantics, rather than using ARIA.
• If you really can’t fix the HTML itself, you might be able to fix the element’s semantics using ARIA. Please only do this if you know what you’re doing with ARIA and if you’re also testing the result yourself with a screen reader.

ARIA use case 2: If you need to build an interactive component that HTML semantics can’t express

Many common interactive components can be expressed with HTML alone. For example:

• a link can be expressed with a a element with an href="..." attribute
• a button can be expressed with a button element or a input element with type="button"
• a group of radio buttons can be expressed with the fieldset, legend and input type="radio" elements

But other very common interactive elements can’t be semantically expressed with HTML alone. For example:

• HTML doesn’t have any ‘tab’ element. So if you want to create a tabbed user interface that screen reader users can understand, you’ll need to use the ARIA tablist, tab and tabpanel roles on top of ul, li, a and div or section elements.
• HTML has a dialog element, but it’s not well supported. So, as of November 2019, if you want to build a modal dialog, you should use a div and add role="dialog" as well as aria-modal="true. The button triggering the modal should have aria-haspopup="true".

The HTML code of custom controls (e.g. sliders, tabs, accordions) should the right ARIA attributes to describe their role and status (e.g. tab, slider, selected, expanded, collapsed).

Example:

<!-- Example 1 - standard control -->
<input type="checkbox" id="c1" /><label for="c1">Remember me</label>

<!-- Example 2 - ARIA supported tree view with fall-back -->
<ul role="tree">
  <li aria-level="0" aria-expanded="true" role="treeitem">
    <a href="...">TV Shows <span class="offscrn"> - Expanded</span></a>
    <ul>
      <li aria-level="1" role="treeitem"><a href="...">Comedy</a></li>
      <li aria-level="1" role="treeitem"><a href="...">Drama</a></li>
      <li aria-level="1" role="treeitem"><a href="...">Sports</a></li>
    </ul>
  </li>
  <li aria-level="0" aria-expanded="true" role="treeitem">
    <a href="...">Radio Shows <span class="offscrn"> - Expanded</span></a>
    <ul>
      <li aria-level="1" role="treeitem"><a href="...">News</a></li>
      <li aria-level="1" role="treeitem"><a href="...">Soap</a></li>
      <li aria-level="1" role="treeitem"><a href="...">Sports</a></li>
    </ul>
  </li>
</ul>

Failure example:

<!-- Don't do this -->

<!-- Example 1 - non-standard control -->
<div><img src="chkbx" alt="checkbox" />Remember me</div>

<!-- Example 2 - inaccessible tree view -->
<div>
  <div onClick="toggle();">
    TV Shows
    <div>
      <div class="indent">Comedy</div>
      <div class="indent">Drama</div>
      <div class="indent">Sports</div>
    </div>
  </div>
  <div onclick="toggle();">
    Radio Shows
    <div>
      <div class="indent">News</div>
      <div class="indent">Soap</div>
      <div class="indent">Sports</div>
    </div>
  </div>
</div>

Requirement 3: Ensuring that Assistive Technologies can understand what state a UI component is in

If you use ARIA’s role property to create components that HTML alone can’t express, you will often need to use aria- attributes to express the properties and states of those components. For example:

• Use aria-selected to express whether a li role="tab" element is the tab that is currently active within its ul role="tablist" parent.
• Use aria-expanded to express whether a component that opens and closes is currently expanded.
• Use aria-checked to express the state of switch component you’ve built with button role="switch"

The HTML code of custom controls (e.g. sliders, tabs, accordions) should the right ARIA attributes to describe their role and status (e.g. tab, slider, selected, expanded, collapsed).

Remember: an ARIA role is just a promise. You need to implement the keyboard support yourself

The role and aria- only tell Assistive Technologies how to announce a component to screen reader users. The keyboard interactions that are implied by different ARIA roles are still for you to implement.

For example, let’s imagine that you’re building a button using div role="button", rather than using the native HTML button or input type="button" elements:

• role="button" implies that this component is a button. Buttons can be activated using the ‘Enter’ and ‘Space’ keys. You will need to implement responses to these key presses yourself.
• div role="button" doesn’t automatically place that pseudo-button in the page’s tab order, which means that users couldn’t reach it using the Tab key. You’d need to remember to add that yourself too, by adding the tabindex="0" attribute.
  
  Note: it’s much better to use button or input type="button" as they come with keyboard support built-in.

References

1. The flutter documentation has a complete list of properties of the Semantics() widget that affect accessibility check.
2. What aria role is allowed on each HTML element;
3. What each aria role value means, and what aria- attributes you should/may use with it.
4. ARIA Authoring Practices Guide 1.1 
5. First rule of ARIA
6. W3C Using ARIA document
7. “5 rules of ARIA” – Understand a bit more about ARIA before creating custom components with ARIA.
8. Accessibility Guidelines- Github.io