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.

Description

Every user interface component on the page should have a name and role. For few components that are developed using scripting language a state, property or value should be set programmatically. The name, role, value and state of HTML controls will be available by default for user agents when they are developed as per the HTML specification. This check point specifically explains about the components that are generated by scripts but not the user interface components that are generated with HTML controls. Few such elements are menus, trees, data grids, accordions, tabs, modals, and dialogs.

Name

As per WCAG glossary, a name is a text by which software can identify a component within Web content to the user. A name may be hidden and is available only for assistive technology users unlike label which is always visible. Note that a name for a component is not same as the HTML name attribute. A name to a user interface component can be programmatically set using aria-label, aria-labelledby or the title attribute.

Role

A role is defined as a text or number by which software can identify the function of a component within Web content. Eg: An image that serves as a checkbox on a web page should be exposed as a checkbox to the user than an image. The role of the image in this case is a checkbox and is considered as a custom component. When the component is provided using HTML specification the accessibility API can identify the role and expose the same to assistive technologies.

State

A state determines the current position of a user interface component which has a boolean value. As per the definition of WAI ARIA “A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities.” Check/ unchecked state of a checkbox, pressed/ unpressed state of a toggle button etc can be considered in this context. To explain in detail, an accordion on a web page will have the expand and collapse functionality. Expand or collapse is a state of the element. It’s the responsibility of the web author to inform the current state of the accordion element to the user agents including assistive technologies.

Property

Attributes that are essential to the nature of a given object, or that represent a data value associated with the object. A change of a property may significantly impact the meaning or presentation of an object. Element that can have a property of opening a context menu should be informed to the assistive technology users. Allowing the component to drag from one place to another have grabbable property, and this property should be informed to assistive technology users.

Value

Value is provided to HTML links and form controls to represent different functions for an element depending upon their usage. Eg: href represents a value for an anchor tag. Value attribute represents the action associated with an input type button, value attribute on a input type text represent some helpful information to fill in the field.

Points to Remember

Keep in mind the following points while dealing with 4.1.2 check point for custom controls.

  • Provide a name for every user interface component. A label can help all users identify the element but providing a name is also fine.
  • The role of each focusable element should be determined by assistive technologies. The role should represent the functionality of the element.
  • If the custom component have a state available, the current state should be informed to the user when it is focused by the user.
  • The change in the state of a component should be exposed to the assistive technologies immediately when it is updated if the element supports it.
  • If the component have any specific property available that property should be set to the component and should be exposed to the assistive technologies.
  • A value should be provided for each user interface components specified in the HTML specification wherever it is mandatory.
  • Take care that the custom components have the standard properties such as keyboard focus, focus indicator etc available.

Who benefits

  • People who use screen reader benefits with accurate name, role and value.
  • People with low vision benefit with the consistent identification of the elements.

WCAG 2.0 Techniques

Comments are closed.

2 Trackbacks to "4.1.2 Name, Role, Value"

  1. on December 31, 2015 at 7:14 am
  2. on December 31, 2015 at 7:15 am