4.1.2 Name, Role, Value (A)

Definition for WCAG 2.0 success criterion 4.1.2

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.

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.

The intent of this Success Criterion is to ensure that Assistive Technologies (AT) can gather information about, activate (or set) and keep up to date on the status of user interface controls in the content.

When standard controls from accessible technologies (such as HTML) are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.

If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies. In the case of website / applications, this is particularly the case in situations where a page requires user interface components that are not available as part of the standard HTML set of structures. For instance, HTML does not currently offer native standardized elements for tabbed navigation panels, dropdown menus, modal dialogs, accordion-type disclosure widgets. These are generally built using HTML/JavaScript, and will require specific additional markup (usually WAI-ARIA roles and attributes) in order to convey their functionality and current state. For this reason, a large part of testing for this success criterion involves checking that custom interface components are correctly implemented.

Testing this particular success criterion can be quite time-consuming and complex, as it requires checking a wide range of interactive and non-interactive page elements.

A partial list of page components to which this test script applies:

  • Native HTML form controls with a visual label.
  • Native HTML form controls without a visual label.
  • Non-native form controls and widgets that are implemented with a combination of JavaScript, CSS and HTML (e.g., anchor tags with the function and visual appearance of a button control, calendar widget, expand/collapse controls, etc.).
  • Instructional text associated with native HTML form controls or non-native components.

With reference to determining the correct name/label for an interface component, browsers and assistive technologies follow a standardized algorithm. If you are in doubt about whether or not a particular method of providing an accessible name/label is valid, or if you are getting inconsistent results when testing with different tools/user agents/screen readers, refer to the HTML Accessibility API Mappings 1.0 - 5. Accessible Name and Description Computation.

For reference, the order of preference (when multiple potential sources for an accessible name/label have been used in HTML) in JAWS is:

  • Use aria-labelledby.
  • Otherwise use aria-label.
  • Otherwise use the associated <label> element, if present.
  • Otherwise use the placeholder attribute (on appropriate form controls).
  • Otherwise use the title attribute.

If none of the above yields a usable text string, there is no accessible name. JAWS will attempt to error-correct, which usually leads to incorrect results (e.g. using any preceding/adjacent text and announcing it as the current control's accessible name).

Useful resources

Testing success criterion 4.1.2

Input into spreadsheet

Fail
Relevant information (role, state, description, value) is missing or inaccurate.
Pass
All interactive content and components (both native and custom) expose all relevant information (role, state, description, value) - meaning that all are properly labelled, inform the user if a particular form input is required, whether a checkbox or radio button is currently selected, and so on.

How to test

This test involves using both aViewer and manual inspection of the page's markup/DOM to verify that all interactive (and structural) components of the page expose their correct name, role, state, value and any other properties.

To get an initial idea of which elements in the page currently have any WAI ARIA attributes/properties:

Use Information > Display ARIA Roles to check for arbitrary elements using WAI ARIA.
Use Structure > ARIA Landmark Roles and Structure > Show Elements with ARIA Attributes to check for arbitrary elements using WAI ARIA, as well as any ARIA-specific structural associations (such as aria-describedby).

Set aViewer to Watch Focus mode. In the browser, navigate to each interactive piece of content and component (such as text input fields, buttons, tabbed interface elements, dropdown menus, modal overlays) with the keyboard (generally using TAB / SHIFT+TAB or component-specific keyboard shortcut).

For each native HTML control (<input>, <textarea>, <button>, <select>, etc.) and each custom control widget (such as the controls for a tabbed interface, treeview, etc.) check:

  • The name/label (MSAA > accName / IAccessible2 > Name).
  • The role - such as "editable text", "button", "menu", "dialog" (MSAA > accRole / IAccessible2 > Role).
  • The state (where applicable) - such as "read-only", "required", "checked" (MSAA > accState / IAccessible2 > States).
  • The description, if present - usually includes additional instructions/information for the user (MSAA > accDescription / IAccessible2 > Description).
  • For sliders, color selectors, datetime fields, the currently exposed value (MSAA > accValue / IAccessible2 > Value).
  • For expand/collapse widgets or menus, ensure that the correct state (expanded or collapsed) is exposed (MSAA > accState / IAccessible2 > States).

For related sets of form fields (such as groups of checkboxes/radio buttons, with an overarching label):

  • Ensure that the overarching label for the set is associated with the form fields that make up the set (generally, through <fieldset>/<legend> structure or explicitly via aria-describedby or similar) (MSAA > accParent).

The following screenshot shows the role, state, and other accessibility properties for a disclosure button using aViewer, along with the markup for the element.

aViewer
Accessibility information for currently selected element

Input into spreadsheet

Fail
Screen reader does not correctly announce the type, name/label, operation and state of all elements.
Pass
Screen reader correctly announces the type, name/label, operation and state of all elements.

How to test

This test focuses on testing with a screen reader. This will involve navigating the entire page using the screen reader, both in "reading" mode (virtual cursor) and "forms" mode (generally, automatically activated when entering a form). If the page contains dynamic elements such as modal dialogs, overlays, menus, these all need to be interacted with to determine how they are being announced/exposed to assistive technology users.

Verify using the screen reader that sufficient information about a user interface element, including the identity, operation and state of the element, are read. Read the entire content navigating element by element, then start at the beginning and use TAB / SHIFT+TAB to each user interface element on the page and verify that following information is provided:

Example: for a checkbox with a text label of "enable", JAWS should announce: "enable" (label), "checkbox" (role), "checked" (state), "to clear check mark press spacebar" (action) when the checkbox receives focus.

  • Navigate the page solely by pressing the up and down arrows. This should read everything.
  • Return to the top of the page and navigate only using the TAB / SHIFT+TAB keys. This should only read focusable items, such as links, form-fields, and buttons.
  • Navigate the page solely by pressing control + option + right and left arrows. This should read everything.
  • Return to the top of the page and navigate only using the TAB / SHIFT+TAB keys. This should only read focusable items, such as links, form-fields, and buttons.