WCAG (Level A) SC 4.1.2 Name, Role, Value

WCAG (Level A) SC 4.1.2 Name, Role, Value (w3.org)

Issue description

WCAG 4.1.2, “Name, Role, Value” is a crucial accessibility guideline that ensures all user interface components have proper names and roles that can be programmatically determined. This is essential for people who rely on assistive technologies, such as screen readers, to interact with web content.

Many websites have user interface components that lack proper names and roles, making it difficult for assistive technologies to:

• Identify the component: Determine what type of element it is (e.g., button, link, checkbox).
• Understand its purpose: Convey the component’s function to the user (e.g., “Submit button,” “Navigation menu”).
• Convey its state: Indicate the current state of the component (e.g., “checked,” “disabled”).

WCAG requirements

This guideline requires that for all user interface components (including form elements, links, and components generated by scripts), the name and role can be programmatically determined; states and properties that can be can be programmatically set by the user; and notification of changes to these items is available to user agents, including assistive technologies. This means:  

• Using semantic HTML: Use appropriate HTML elements for their intended purpose (e.g., <button> for buttons, <a> for links).
• ARIA attributes: Use ARIA attributes (e.g., aria-label, role) to provide names, roles, and states for custom components or when semantic HTML is not sufficient.

Benefits

• Improved accessibility: Assistive technologies can accurately convey the purpose and state of components to users.
• Enhanced usability: Clear names and roles make the website more predictable and easier to understand for everyone.
• Better user experience: It creates a more inclusive experience for users with disabilities.

Essentially, WCAG (Level A) SC 4.1.2 Name, Role, Value ensures that all user interface components have the necessary programmatic information to be understood and interacted with by assistive technologies, making the website more accessible to everyone.

Related requirements

The following WCAG source criteria are often related to this as well. They can provide additional insights into specific challenges you may be encountering.

• WCAG (Level A) SC 2.5.3 Label in Name
• WCAG (Level A) SC 3.3.1 Error Identification
• WCAG (Level A) SC 3.3.2 Labels or Instructions
• WCAG (Level AA) SC 3.3.3 Error Suggestion
• WCAG (Level AA) SC 4.1.3 Status Messages

Who this issue impacts

Follow the links for additional information on user impairments:

• Vision impairment
• Cognitive impairment
• General user experience

Suggestions for remediation

Remediating WCAG 4.1.2, “Name, Role, Value” involves ensuring all user interface components have programmatically determinable names and roles. This allows assistive technologies to accurately convey the purpose and functionality of the components to users. Here’s how:

Use Semantic HTML

• Choose the right elements: Utilize native HTML elements like <button>, <a>, <input>, <select>, etc., for their intended purposes. These elements have built-in semantic meaning and roles that assistive technologies understand.
• Structure content with headings: Use heading tags (<h1> to <h6>) to structure content hierarchically, making it easier for assistive technologies to navigate and understand the page structure.
• Use labels for form elements: Associate <label> elements with form controls (<input>, <textarea>, <select>) to provide descriptive labels. This helps assistive technologies identify the purpose of each form field.

Utilize ARIA attributes when necessary

• ARIA labels: When semantic HTML isn’t sufficient or for custom elements, use aria-label to provide a concise and descriptive label. For example, an icon button with a magnifying glass could have aria-label="Search".
• ARIA roles: Use role attributes to define the purpose of custom components or elements that don’t have a native semantic equivalent. For instance, a custom dropdown menu could use role="listbox".
• ARIA states and properties: Use ARIA attributes like aria-expanded, aria-checked, and aria-disabled to convey the current state of interactive elements, ensuring assistive technologies can accurately reflect these states to users.

Ensure keyboard accessibility

• Keyboard operable: Make sure all interactive elements can be accessed and operated using the keyboard alone (e.g., using Tab, Enter, Space).
• Focus indicators: Provide clear visual indicators for keyboard focus, so users know which element is currently active.

Example

Let’s say you have a custom close button that’s just an “X” icon. To make it accessible:

HTML
<button aria-label="Close">
  <svg aria-hidden="true" focusable="false" ... > 
    </svg>
</button>

This code:

• Uses a <button> element for built-in keyboard accessibility.
• Provides an aria-label to convey the button’s purpose to assistive technologies.
• Hides the SVG icon from assistive technologies (aria-hidden="true") as it’s purely decorative and the aria-label already provides the necessary information.

By following these practices, you can ensure that all users, including those with disabilities, can understand and interact with your website effectively.

Links for more info

• Understanding WCAG SC 4.1.2 Name, Role, Value (digitala11y.com)
• Name Role Value (4.1.2 – Level A) (wuhcag.com)