Loading...
Loading content...
Loading content...
Use proper ARIA attributes and semantic HTML so assistive technologies understand component purpose.
Why it matters: Screen readers need to know what each element is and how to interact with it.
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
What This Means: This success criterion requires that all user interface components have programmatically determinable information about their name (what they're called), role (what they are - button, link, checkbox, etc.), state (checked, expanded, disabled, etc.), and value (current selection, input value, etc.). Additionally, changes to these properties must be communicated to assistive technologies.
Why It's Important: Screen readers and other assistive technologies need to know what each UI component is, what it's called, its current state, and how to interact with it. Without this programmatic information, users with disabilities cannot understand or use the interface effectively. For example, a screen reader user needs to know that a div is actually a button, what the button does, and whether it's currently pressed or disabled.
Use semantic HTML elements (like <button>, <input>, <select>) which provide this information automatically. For custom components, use ARIA attributes (role, aria-label, aria-labelledby, aria-describedby, aria-expanded, aria-checked, etc.) to provide the necessary information. Ensure that state changes are communicated through proper ARIA attributes or semantic HTML updates.
This criterion ensures that screen reader users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that keyboard users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that voice control users can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
A div styled as a button has no role or accessible name, so screen readers don't know it's a button.
<div onclick="submit()" class="button">Submit</div>A button element with proper role and accessible name.
<button onclick="submit()">Submit</button>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 4.1.2 Name, Role, Value are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If it looks like a button, assistive technologies will know it's a button.
Assistive technologies rely on programmatic information (role, name), not visual appearance. A div that looks like a button needs role='button' and proper keyboard handling.
I can use any ARIA role I want for custom components.
ARIA roles must match the component's actual behavior. Don't use role='button' for something that behaves like a link, or role='checkbox' for something that behaves differently.
Screen readers automatically know what custom components do.
Screen readers only know what you tell them through semantic HTML or ARIA attributes. Custom components require explicit role, name, and state information.
Custom components without role attributes.
Add appropriate role attributes to custom components. Use role='button', role='checkbox', role='tab', etc., based on the component's function.
Components without accessible names (missing labels or aria-label).
Provide accessible names using <label>, aria-label, aria-labelledby, or visible text. Icon-only buttons need aria-label.
Component states not communicated (e.g., expanded/collapsed, checked/unchecked).
Use appropriate ARIA attributes: aria-expanded for expandable content, aria-checked for checkboxes, aria-selected for options, etc.
Dynamic changes not announced to screen readers.
Use aria-live regions or role='alert' to announce important changes. Ensure state changes are programmatically updated.
Using wrong ARIA roles that don't match component behavior.
Ensure ARIA roles accurately reflect component behavior. Don't use role='button' for links, or role='checkbox' for radio buttons.
Note: These are official W3C resources for 4.1.2. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 4.1.2 Name, Role, Value correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Robust PrincipleGuideline
4.1 Compatible