Understanding WCAG SC 4.1.2 Name, Role, Value
Version and Level: 2.0/2.1/2.2 (Level A)

This success criterion ensures that user interface components(such as form controls,buttons,links,and custom-controls) convey their accessible name, role, state, and properties to assistive technologies. This is crucial for enabling users with disabilities to interact effectively with these elements. Native HTML elements generally meet these requirements by default, but custom components often require additional coding using WAI-ARIA attributes.

Benefits:

  1. Improved Accessibility: Ensures that assistive technologies can accurately convey the function and state of UI elements to users.
  2. Enhanced User Experience: Helps users with disabilities understand and interact with custom widgets and controls.

Main Objective:

To ensure all user interface components have their accessible attributes—name, role, value, state, and properties—correctly defined and programmatically available to assistive technologies, facilitating interaction for users with disabilities, it is crucial to use semantic HTML. By default, semantic HTML provides components with predefined name, role, value, and state attributes.

However, when web authors create complex web content, such as interactive widgets or applets (e.g., tab panels, trees, nested navigation bars), essential attributes like name, role, value, state, or keyboard functionality might be overlooked. Integrating WAI-ARIA ensures that these interactive components possess all necessary attributes.

Testing these components with a screen reader confirms the presence of correct WAI-ARIA attributes. For example, a fancy slider created without semantic HTML may lack essential attributes. To rectify this, attributes like aria-label or aria-labelledby for the accessible name, role="slider" for role, aria-valuemax , aria-valuemin , and aria-valuenow for properties and states, tabindex="0" for enabling keyboard focus, and JavaScript for functionality should be included.

Prioritizing semantic HTML not only saves time but also reduces testing efforts and potential accessibility failures.

Best Practices:

  • Use Native HTML Elements: Prefer native HTML elements as they inherently possess the required accessibility features.

  • Ensure Keyboard Operability: Ensure that custom elements such as tab panels receive focus and can be triggered via keyboard interactions. This can be achieved by including the tabindex attribute and JavaScript keydown or keyup event handlers.

  • Apply WAI-ARIA Attributes: On custom or emulated elements use WAI-ARIA attributes to define the name, role, state, and properties.

  • Label Placement: Ensure labels are programmatically associated with controls using the "for" and "id" attributes. Without these attributes, the accessible name for controls may be missing.

Examples & Explanation:

Example: A Close Button (X) in a Pop-up Box

What Should Be Avoided

A custom close button for a pop-up box is created using a div or span element without proper accessible attributes.

HTML/CSS

              <div id="box">
                This is a pop-up box.
                <div class="close-button" onclick="document.getElementById('box').style.display='none';">X</div>
              </div>

Explanation:This implementation lacks accessible attributes. Assistive technologies and keyboard users cannot interact effectively with the button because it lacks the correct accessibility name (currently just "X"), role, and tabindex attributes.

What Should Be Done

HTML/CSS

              <div id="box">
                This is a pop-up box.
                <button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>
              </div>

Explanation:In the corrected example, the <button> element is used instead of a <div>, and the aria-label attribute provides an accessible name. Since the correct HTML tag name is used, the role attribute is not needed. Additionally, because the button does not represent any state changes, state-related WAI-ARIA attributes are not necessary. This setup ensures that assistive technologies can convey the button's purpose to users, and the button is operable via the keyboard.

Next Up

Enhance your understanding with SC 4.1.3 - Status Messages. Learn to make status messages accessible for all users.

Go to SC 4.1.3