Define the purpose, name, role, and value of UI components in markup

Example of good semantic markup of an accordion
Image description: A code editor displaying good semantic markup of an accordion. The code in the editor is displayed below.

<button aria-expanded="false" class="Accordion-trigger" aria-controls="sect2" id="accordion2id"> <span class="Accordion-title"> Inclusive Design <span class="Accordion-icon"></span> </span> </button>

This page is in progress -

If you would like to contribute or make a case to prioritize this page, please fill out the form below.

Why This is Important

Keyboard and screen reader users need to understand the purpose, name, role, and values of UI elements so that they can interact with them.

Blind and visually impaired people use screen readers to interact with websites and apps. A screen reader is a type of assistive tech that converts things on screen to audio and/or braille. It's important that things are understandable and interactive to screen readers.

Keyboard accessibility is essential for people who do not use a computer mouse (which might be because they have unpredictable or very specific movement due to a motor disability). Many Blind and visually impaired people also use keyboard interactions in order to use their screen reader.

Error support is accessible to people with a diversity of disabilities. A cognitive disability might affect how a person perceives and understands things. A physical disability might lead to unpredictable movement. Other factors such as environment, stress, and multi-tasking may also lead to errors.

In order to be accessible, gestures and interactions must account for people with physical and motor disabilities, who might have unpredictable or very specific movement.

In general, assistive technology uses name, role, and values to parse controls and structure properly. For example, is a menu open, is a checkbox checked, is a toggle on or off. All this information needs to be available to assistive technology users in order to be accessible.

This references WCAG criteria 4.1.2 Name, Role, and Value (Level A) and 1.3.6 Identify Purpose (Level AAA).

Level AAA compliance is considered more difficult to meet because it requires more resources to fulfill. It also might encompass conflicting access needs (meaning what is accessible to some might be inaccessible to others). Use your best judgment of your target audience and your team's capabilities to determine if this is a pragmatic goal to reach.

How to Implement This

Name, Role, and Value

According to WCAG, the name and role of all interactive elements should be available to screen readers and assistive tech. People should also be able to set the value of interactive elements using assistive tech (for example, selecting an option in a dropdown menu using a screen reader).

Digital A11y recommends in their blog to use native HTML elements whenever possible because they have the name, role, and value built in. This doesn't require any additional coding in order to be accessible.

When building custom components (such as a custom navigation component) it's recommended to use ARIA (Accessible Rich Internet Applications). ARIA is a type of markup used to enhance HTML to make it accessible to assistive tech.

Here are some helpful resources about ARIA:

Identify Purpose

Identifying the purpose of elements on the page is similar to name, role, and value because the end goal of both criteria is to ensure that assistive tech users can use the website/app.

It's recommended to use the WAI-ARIA landmark role in order to identify the purpose of elements, icons, and regions. This allows people to easily find what they're looking for. They can use the landmark role to customize the display, for example only display the "main" section and not the "nav" or "footer."

Note on "Programmatically Determined"

WCAG often uses the phrase "programmatically determined" to mean that an element is defined in markup (HTML) and therefore available for assistive tech to access. I use the term "defined in markup" instead because I find it more simple and understandable. Just keep this in mind when reading WCAG source material.

How to Test This

Manual Test
Semi-Automated Test
Automated Test

Use an automated testing tool such as Deque Axe or IBM Accessibility Checker to test for accessible markup.


No credits yet. But this could be you!

Code snippets written by Michellanne Li.

Contribute and Give Feedback

If you would like to provide feedback or contribute content on this resource, please fill out the form below.

Thank you, your submission has been received!
Oops! Something went wrong while submitting the form. Please check your internet connection and try again.

If you continue to encounter issues, please reach out to alexyingchen(at)