Name, Role, and Value

When a control is built with native HTML, the browser usually gives assistive technology a lot for free.

A real button has a role. A labeled input has a name. A checkbox can expose whether it is checked. A disabled control can expose that it is unavailable.

Custom components often lose that built-in information unless the team deliberately puts it back.

Name, role, and value is the practical question behind many component accessibility issues:

• What is this control called?
• What kind of thing is it?
• What is its current state or value?
• Can people change it with the keyboard or assistive technology?

The common project moment

A team builds a custom control because the design does not look like a default browser control.

It might be a clickable card, a styled dropdown, an icon-only toggle, a custom tab strip, a fake checkbox, an expandable panel, or a framework component that renders mostly div and span elements.

Visually, the component seems clear enough.

But a screen reader says only “group,” “clickable,” or nothing useful. Keyboard focus lands somewhere unexpected. The selected or expanded state is visible on screen but not announced. QA can click it with a mouse, but cannot tell what the control is from assistive technology output.

That is usually a name, role, or value problem.

What name, role, and value means

A control needs enough information for people and assistive technology to understand and operate it.

The name is what the control is called.

Examples:

• Search
• Save changes
• Show password
• Shipping address
• Sort by date
• Notifications, on

The role is what kind of control it is.

Examples:

• button
• link
• checkbox
• radio button
• tab
• switch
• textbox
• combobox

The value or state is the current condition of the control when that matters.

Examples:

• checked or not checked
• expanded or collapsed
• selected or not selected
• pressed or not pressed
• current value in a field
• invalid or required
• disabled or unavailable

People should not have to infer all of that from color, position, shape, or visual styling alone.

Start with native controls when possible

The easiest way to get name, role, and value right is often to use the element that already has the right behavior.

For example:

• Use a real <button> for actions.
• Use a real <a href="..."> for navigation.
• Use a real <input type="checkbox"> for checkboxes.
• Use a real <select> or another well-supported pattern for selection when it fits.
• Use a real form label for form fields.
• Use real headings, lists, and tables when they describe the structure.

Native HTML does not remove all accessibility work. Labels, instructions, errors, focus order, and visual design still matter.

But native controls start with a working contract. Custom controls start with debt the team has to repay.

Check the name

A control name should tell people what the control does or what information it collects.

Useful checks:

• Does the visible text give the control a clear name?
• If the control is icon-only, is there an accessible name that matches the visual purpose?
• If the same label repeats, does surrounding context or the accessible name make each instance specific enough?
• Does the accessible name include the visible label when there is visible text?
• Is hidden text helping, or is it replacing better visible wording?

Names should be specific enough to use outside the visual layout.

A table with five “Edit” buttons may be clear visually, but a list of buttons that all say “Edit” is not enough unless each one has useful context.

Check the role

The role should match what the control actually is and how it behaves.

Useful checks:

• Is a navigation control exposed as a link?
• Is an action exposed as a button?
• Is a checkbox, radio group, tab, switch, or combobox exposed as that kind of control only when it behaves like that control?
• Is a generic container being made clickable without a meaningful role?
• Is ARIA being used to announce a role that the component does not actually support?

Role is a promise.

If something is announced as a button, people expect button behavior. If something is announced as a tab, people expect tab behavior. If something is announced as a combobox, people expect a much more specific keyboard and state model.

Do not choose an ARIA role because it sounds close. Choose it only when the component behaves like that role.

Check the value or state

Some controls need to expose more than a name and role.

They also need to tell people what is happening now.

Useful checks:

• Does an expand/collapse control expose whether content is expanded?
• Does a toggle expose whether it is pressed, checked, or on?
• Does a tab expose which tab is selected?
• Does a field expose its current value?
• Does a required or invalid field expose that status in a useful way?
• Does a disabled control expose that it is unavailable?
• Does a loading, saved, failed, or completed state have a visible and programmatic cue when people need it?

If the state only changes visually, some users may never know it changed.

Be careful when ARIA changes the contract

ARIA can add useful information. It can also make a broken component sound more official than it really is.

A few examples:

• role="button" does not automatically add button keyboard behavior.
• aria-expanded="true" does not automatically move focus or reveal content correctly.
• aria-selected="true" does not automatically create a working tab pattern.
• aria-disabled="true" does not automatically prevent activation.
• aria-label can hide a mismatch between visible text and the announced name.

ARIA should describe behavior the component actually has.

If the component does not support the behavior, fix the component before adding a more advanced role or state.

Questions teams can ask

During design and content

• What should this control be called when someone cannot see the surrounding layout?
• Is the visible label clear enough, or are we relying on icon shape, color, or position?
• Does the component need to expose selected, expanded, checked, pressed, invalid, required, or disabled state?
• Are we designing a common native control in a custom-looking way, or a genuinely custom interaction?
• Would simpler visible text reduce the amount of hidden naming we need?

During development

• Can this be built with a native element first?
• If a custom element is necessary, what role does it expose?
• Does keyboard behavior match the exposed role?
• Does the component expose the right name and current state?
• Are ARIA attributes updated when the component changes?
• Are we using ARIA to describe real behavior instead of patching over missing behavior?

During QA

• Can the control be reached and operated with the keyboard?
• Does a screen reader announce a useful name?
• Does the announced role match what the control does?
• Is the current state announced when state matters?
• After activation, does focus move or stay in a predictable place?
• Can someone complete the same task without relying on visual styling alone?

Common trail hazards

• Using div or span elements as controls without restoring name, role, keyboard behavior, focus, and state.
• Adding role="button" but forgetting Enter and Space behavior.
• Giving a component a complex ARIA role without following the expected keyboard pattern.
• Hiding a poor visible label behind a better aria-label instead of improving the visible label.
• Communicating selected, expanded, active, disabled, or invalid state only with color or styling.
• Updating the visual state but not the programmatic state.
• Treating ARIA as a shortcut around simpler HTML.

Small habit

When reviewing a custom control, ask three questions in order:

1. What is it called?
2. What kind of control is it?
3. What state or value does it have right now?

If the team cannot answer those three questions clearly, the component is not ready for accessibility review.

Related WCAG trail markers

• WCAG 1.3.1 Info and Relationships
• WCAG 2.1.1 Keyboard
• WCAG 2.4.3 Focus Order
• WCAG 2.5.3 Label in Name
• WCAG 4.1.2 Name, Role, Value
• WCAG 4.1.3 Status Messages

Related resources

• Native HTML First — for choosing elements with built-in semantics and behavior.
• Button vs Link — for matching clickable controls to navigation or action behavior.
• Accessible Names — for checking what controls are called.
• Link Text and Button Labels — for writing visible labels that make actions and destinations clear.
• ARIA Is Not Duct Tape — for checking whether ARIA describes behavior the component actually supports.
• Accordions — for checking expandable sections, button headers, keyboard behavior, and expanded or collapsed state.
• Combobox — for a deeper example where name, role, expanded state, active option, selected value, keyboard behavior, and status messages all need to agree.
• Tabs — for a deeper example where label, role, selected state, tab-panel relationship, keyboard behavior, and hidden panel content need to agree.
• Keyboard-Only Navigation — for checking whether controls work without a mouse.
• Focus Visible and Focus Order — for checking where focus goes before and after interaction.
• Status Messages and Alerts — for changes that need feedback after activation.

Related field notes

• Accessibility Glossary — for plain-language definitions of common accessibility terms used across this guide.

What to do next

If you are reviewing a custom control, test one example with a keyboard and screen reader. Then check ARIA Is Not Duct Tape to make sure any ARIA matches the behavior the component actually supports.

Write down its name, role, and current state exactly as they are exposed. Then compare that to what the visual design appears to promise.