What Are ARIA Allowed Attributes? Complete Guide (2026)

Why ARIA Allowed Attributes Matter

ARIA is the layer that tells assistive technology what each control IS, what STATE it's in, and what RELATIONSHIPS it has. When that layer disagrees with the role of the element, screen readers either ignore the attribute or — worse — announce a state that doesn't match what the user sees.

• Screen-reader regressions: A <button> with aria-checked="true"may be announced as either "button" or "checked" depending on the screen reader. Users get inconsistent behavior across NVDA, JAWS, VoiceOver, and TalkBack.
• Silent failure on typos: aria-lable and aria-pressed-state are not in the spec. Browsers do not warn — the attribute is simply dropped. The visible UI looks fine; the screen-reader experience is broken.
• WCAG 4.1.2 violations: Name, Role, Value is a Level A criterion. ARIA misuse is one of the most-cited ways to fail it.
• Legal exposure: US ADA and EU EAA (European Accessibility Act, in force June 2025) lawsuits routinely cite invalid ARIA in technical evidence.
• AI search visibility: AI answer engines lean on semantic HTML and ARIA to understand structure. Pages with broken ARIA produce noisier accessibility trees and weaker structured signals.

The Three Audits That Catch Bad ARIA

Most automated checkers (axe-core, the open-source rules engine behind many tools, plus the rules baked into Chrome DevTools' Issues panel) split ARIA validation into three separate checks. Knowing which one fired tells you what to fix.

How to Check Your Pages

• Greadme deep scan — runs the full ARIA validity rule set, lists every offending element with the role, attribute, and reason, and offers a one-click GitHub PR fix where applicable.
• Greadme crawler scan — checks ARIA validity across every indexable page so you can find templates (modals, tab strips, custom selects) that repeat the same mistake site-wide.
• Greadme AI visibility analyzer — surfaces how clean accessibility markup affects how AI answer engines understand and cite your pages.
• Chrome DevTools → Issues panel — flags many invalid ARIA attributes inline as you load a page, with a link to the offending element.
• axe-core (the open-source rules engine) — integrates into Jest, Playwright, Cypress, and Storybook for build-time validation.
• Manual screen-reader test — load the page in NVDA (Windows), VoiceOver (macOS/iOS), or TalkBack (Android) and tab through. If a control is announced wrong, the ARIA is wrong.

Bad vs Good: Real Examples

Three of the most common ARIA validity failures, side by side:

<!-- BAD: aria-checked is not allowed on role="button" -->
<button aria-checked="true">Subscribe</button>

<!-- BAD: aria-lable is a typo; browsers silently drop it -->
<button aria-lable="Close dialog">×</button>

<!-- BAD: "yes" is not a valid value for aria-pressed -->
<button aria-pressed="yes">Bold</button>


<!-- GOOD: use role="switch" (or <input type="checkbox">) -->
<button role="switch" aria-checked="true">Subscribe</button>

<!-- GOOD: correct attribute name -->
<button aria-label="Close dialog">×</button>

<!-- GOOD: tokens must be true | false | mixed -->
<button aria-pressed="true">Bold</button>

In every case, the simplest fix is a more honest description of what the element actually is. If it's a toggle, mark it as a switchor use a checkbox. If it's a button, drop the state attributes that don't apply.

10 Rules to Avoid ARIA Validity Errors

role="button"     -> aria-pressed, aria-expanded, aria-disabled (no aria-checked)
role="checkbox"   -> aria-checked, aria-required, aria-readonly
role="switch"     -> aria-checked
role="tab"        -> aria-selected, aria-controls
role="slider"     -> aria-valuenow, aria-valuemin, aria-valuemax, aria-valuetext

function Disclosure({ children, label }) {
  const [open, setOpen] = useState(false);
  const id = useId();
  return (
    <>
      <button aria-expanded={open} aria-controls={id} onClick={() => setOpen(o => !o)}>
        {label}
      </button>
      <div id={id} hidden={!open}>{children}</div>
    </>
  );
}

Common ARIA Validity Issues and Fixes

aria-allowed-attr vs aria-valid-attr vs aria-valid-attr-value

All three audits sound similar but catch different bugs. Knowing which fired tells you whether to fix the role, the attribute name, or the value token.

FAQ

What does the aria-allowed-attr audit check?

It verifies that every ARIA state and property on an element is permitted for that element's role. The WAI-ARIA spec defines a fixed list of supported states and properties for each role, and anything outside that list fails the audit.

Is invalid ARIA a WCAG failure?

Yes. Invalid ARIA almost always maps to WCAG 2.2 Success Criterion 4.1.2 Name, Role, Value (Level A), because the role/state/value triple becomes unreliable. Some misuses also touch SC 1.3.1 Info and Relationships.

Why does WebAIM's data show ARIA correlates with MORE accessibility errors?

Because most ARIA in the wild is misused. WebAIM's 2025 Million homepage analysis found pages using ARIA averaged more detected errors than pages without it — the ARIA was being applied incorrectly. The W3C's First Rule of ARIA exists for exactly this reason: native HTML first, ARIA only when there's no native equivalent.

What's the difference between aria-pressed and aria-checked?

aria-pressed belongs on toggle buttons (Bold, Italic, Mute). aria-checked belongs on roles that represent a selection state — checkbox, radio, switch, menuitemcheckbox, menuitemradio, option, treeitem. Putting aria-checked on a button is the canonical aria-allowed-attr failure.

Will browsers warn me about typos in ARIA attribute names?

No. Unknown attributes (aria-lable, aria-pressed-state) are silently ignored by the HTML parser. The page renders normally and the screen-reader output is wrong. The only reliable way to catch typos is automated linting (eslint-plugin-jsx-a11y), an automated accessibility checker like axe-core, or Chrome DevTools' Issues panel.

Does invalid ARIA affect AI search engines like ChatGPT and Perplexity?

Indirectly. AI answer engines use the accessibility tree and semantic HTML to understand page structure. Broken ARIA produces a noisier accessibility tree, weaker structured signals, and worse rankings in traditional Google search — and AI answer engines preferentially cite pages that already rank well. Clean ARIA helps both audiences.

How do I fix aria-checked="true" on a button?

Pick the right semantics for what the control actually does. If it's a settings toggle, use role="switch" — that role accepts aria-checked. If it's a press-toggle (Bold, Mute), swap to aria-pressed. If it's a real checkbox, use <input type="checkbox"> and skip ARIA entirely.