Name, role, value for designers

This is part three of my series explaining more dev-heavy WCAG requirements for my fellow designer friends. In this post, I’ll dive into success criteria 4.1.2 Name, Role, Value.

4.1.2 Name, role, value overview

In order for UI controls to be accessible to assistive technologies, HTML markup is needed to allow assistive tech to understand the status of the controls. This success criteria makes it possible for these tools to reliably convey information about these components to their users. Using real HTML elements automatically pass on name, role, and value information. However, when custom controls are created, additional measures are needed to ensure the controls provide enough information and allow themselves to be controlled by assistive technologies. This is usually where accessibility problems arise.

So, friendly reminder:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Name

A name is used to provide an accessible name or label for an element that does not have an inherent label or needs a more describe label than its content provides. I went into a bit more detail in my last post if you're interested. An example of a name is a label for a form control or button, the text of the link, or the name of the tab.

Role

A role provides meaning to content, which allows assistive technology to present and support interactions with that UI element in a way that is consistent with user's expectations. Roles can be used to describe elements that don't already have native HTML roles or exist but don't have full browser support yet. Examples of a role include a button, link, text field, radio button, checkbox, tab, dialog, or slider.

There are six different types of roles:

1. Document structure - provide a structural description for a section of content (example: tooltip)
2. Widget - define common interactive patterns (example: searchbox)
3. Landmark - identify the organization and structure of a web page (example: form)
4. Live region - define elements with content that will be dynamically changed (example: alert)
5. Window - define sub-windows to the main document window, within the same window (example: dialog)
6. Abstract - only intended for use by browsers to help organize and streamline a document... No accessibility benefit

Value

Values, sometimes also referred to as properties or states, express characteristics of a UI component that may be static (properties) or change in response to a user's action or an automated process (states). Examples of a value include expanded/collapsed, selected, current, disabled, or a slider's value.

Requirements

Standard controls

All UI components should reliably convey their name and role to an assistive technology, like a screen reader, via HTML or ARIA techniques. If the component has more than one value, its current and changed values should also be identifiable and usable by an assistive technology.

Custom controls

Complex components must meet code specifications appropriate for the platform and facilitate accessibility support with assistive technologies. These components must also be fully usable by assistive technologies.