WCAG 2.2 success criterion 4.1.2, Name, Role, Value, is a Level A requirement. In practice: controls expose an accessible name and their state; ARIA roles are valid; hidden content is not focusable; frames have an accessible name; and ARIA attributes, ids and nesting are valid. It’s among the most common failures on the web: WebAIM found detectable WCAG failures on 95.9% of the top million home pages, and this criterion covers one of the six failure types they found most often (WebAIM Million, 2026 (opens in a new tab)).
Read the criterion in the W3C Recommendation, WCAG 2.2 (opens in a new tab).
How BearScan checks it
Controls expose an accessible name and their state
Checked automatically: reads the HTML. Severity: high. A button with no name is announced as just "button", which conveys nothing about what it does; a toggle that shows its selected option only by colour leaves a screen-reader user unable to tell which option is on.
An approximation: Names are computed from the rendered markup by the accname algorithm: aria-labelledby, aria-label, the element's content (text, an image's alt, an SVG's title, skipping anything aria-hidden), then title. Links and buttons hidden from assistive technology by aria-hidden or hidden are not counted. A name supplied only by CSS-generated content, or an element hidden only by a stylesheet, is not visible in markup and may be reported as unnamed. State is checked on groups of two to ten sibling buttons, tabs or role=link elements of one role that are not all drawn alike, compared by computed colours, borders, weight, decoration, shadow, outline and pseudo-element indicators with the pointer away and nothing focused. In up to eight such groups per page a control drawn like another (in a pair, either) is pressed by the pointer, with every write and navigation stopped and the page let settle. The group is a toggle only if the selected look moves onto the pressed control: every property that changed on exactly one other control swapped with the pressed one's, or, where several can be on, the pressed control alone took on another control's look. It is then put back as found. A toggle passes when Chromium reports the pressed control as pressed, selected or checked, it carries aria-current, or an accessible name in the swap changed; it fails when no control in the group had any such state before or after, or when the group has such states but the control that now looks selected does not carry one. A press that goes to another page, opens a window, dialog or menu, or changes the group any other way is not a toggle. A press that could not be read (covered, a write stopped, a page still changing, a group redrawn) leaves the rule incomplete. Native links, radio buttons and checkboxes are not pressed, and a group whose selected option is marked only by a separate element (a pill that slides behind the buttons) looks alike in every computed style and is not seen.
How to fix it. Give every link, button, and control visible text, an aria-label, or an aria-labelledby reference. Icon-only controls need an explicit label. A group of buttons where one option is chosen needs that choice exposed: aria-pressed on each button, or radios (role=radio with aria-checked in a radiogroup), or tabs with aria-selected.
ARIA roles are valid
Checked automatically: reads the HTML. Severity: medium. An unrecognised role is ignored by assistive technology, so the intended semantics are lost.
How to fix it. Correct the role value to one defined in the ARIA specification, or remove it and rely on native HTML semantics.
Hidden content is not focusable
Checked automatically: reads the HTML. Severity: high. aria-hidden hides content from assistive technology while leaving it in the tab order, so a keyboard user lands on something that is announced as nothing.
How to fix it. Remove aria-hidden from focusable elements, or make them genuinely unfocusable with the disabled attribute or by removing them from the tab order.
Frames have an accessible name
Checked automatically: reads the HTML. Severity: medium. An unnamed frame is announced only as "frame", leaving the user unable to tell what is inside it.
How to fix it. Add a title attribute to every iframe that describes its contents.
ARIA attributes, ids and nesting are valid
Checked automatically: loads the page in a browser. Severity: high. An invalid or prohibited ARIA attribute is ignored or misreported by assistive technology, and an interactive element nested inside another is often unreachable, so the control's state or the control itself is lost.
An approximation: Takes every axe-core rule tagged for 4.1.2 that the naming, role, hidden-focus and frame rules do not already claim, so an axe rule added for this criterion lands here by default.
How to fix it. Use only ARIA attributes the element's role allows, with valid values, include every attribute the role requires, keep ids referenced by ARIA unique, and do not nest interactive elements.
All WCAG 2.2 criteria · Next: 4.1.3 Status Messages
Questions
Is WCAG 4.1.2 required by the ADA?
The ADA doesn't name a technical standard for businesses, but the Justice Department's 2022 guidance points businesses to WCAG, and its 2024 rule for state and local governments adopted WCAG 2.1 Level AA, which includes 4.1.2.
Can an automated tool check WCAG 4.1.2?
Mostly. BearScan checks it automatically (reads the HTML, loads the page in a browser). A clean result still isn't proof every page passes, only the pages scanned.
How do I fix a WCAG 4.1.2 failure?
Give every link, button, and control visible text, an aria-label, or an aria-labelledby reference. Icon-only controls need an explicit label. A group of buttons where one option is chosen needs that choice exposed: aria-pressed on each button, or radios (role=radio with aria-checked in a radiogroup), or tabs with aria-selected.