The ARIA Implementation Errors That Quietly Break Accessibility

image by = barrierbreak

ARIA Implementation Errors to Avoid: A Developer’s Field Guide

ARIA — Accessible Rich Internet Applications — is how developers make dynamic interfaces like menus, tabs, carousels, and live-updating content understandable to assistive technology. Used well, it fills the gaps that plain HTML can’t. Used carelessly, it actively misleads the people who depend on it. That’s why ARIA implementation errors are among the most damaging accessibility problems: they don’t just fail silently, they announce the wrong thing confidently.

The uncomfortable truth is that a lot of ARIA in the wild is broken. It looks fine on screen, passes a casual glance, and then tells a screen reader user that a heading is a button, or that a collapsed menu is expanded. There’s a well-worn maxim in the accessibility world that sums it up: “No ARIA is better than bad ARIA.” Here are the errors that prove it, and how to steer clear.

The First Rule: Prefer Native HTML

Before any specific mistake, the single most important principle: if a native HTML element does the job, use it. A real <button> comes with keyboard operability, focus behavior, and the correct role built in. Rebuilding that from a <div> plus ARIA is more work and far more error-prone.

ARIA doesn’t add behavior — it only changes how assistive technology describes an element. It’s a labeling layer, not a functionality layer. Keep that distinction in mind and most ARIA errors become obvious.

Common ARIA Implementation Errors (and How to Fix Them)

1. Misusing roles, states, and properties

This is the broadest and most frequent category. Typical examples from real audits:

• role="button" slapped onto a heading that has no action, which strips its heading semantics and invites users to activate something that does nothing.
• aria-haspopup on ordinary navigation links that don't open a menu.
• aria-pressed="false" left unchanged on a toggle button that's actually in the pressed state.

The fix: only apply a role, state, or property that genuinely matches the element’s purpose and behavior — and make sure states update on interaction. A mute button that flips visually but never updates aria-pressed leaves screen reader users unsure whether their click did anything.

2. Missing expand/collapse state

Accordions, disclosure widgets, hamburger menus, FAQ toggles — anything that shows and hides content — needs to communicate its state programmatically. Sighted users see the content appear; screen reader users get nothing unless you tell them.

The fix: use aria-expanded. Set it to "false" when collapsed and "true" when expanded, and — critically — update the value on every interaction. The attribute is worthless if it's static.

3. Roles not defined at all

When a button is built from a <span> or <div>, or custom tabs, radios, and checkboxes ship without roles, assistive technology has no idea what the element is. Role information is what tells a user how to interact — press Space to check a box, use arrow keys to move between tabs.

The fix: define an explicit role for every custom component. The difference is stark: without a role, a screen reader announces “Add to cart”; with role="button", it announces "Add to cart, button" — and the user knows how to operate it. (Better still, use a native <button> and skip the problem.)

4. Missing ARIA attributes that carry meaning

Some attributes aren’t strictly required but dramatically improve the experience, and their absence is a common finding:

• **aria-label on navigation landmarks** — with multiple <nav> regions, names like "Primary" or "Footer" tell screen reader users where they are.
• **aria-current="page"** — marks the current item in pagination or navigation, which is often only shown visually.
• **aria-hidden="true"** — hides purely decorative icons so they aren't announced as noise.
• **aria-describedby** — associates an inline form error with its input so the message is actually read out.

The fix: treat these as part of finishing a component, not optional polish. They’re the difference between a smooth experience and a frustrating one.

5. Broken carousels

Carousels attract ARIA errors like nothing else. The usual failures: the carousel isn’t identified as one, slide changes aren’t announced, and the active slide-picker control’s state isn’t exposed.

The fix: wrap the carousel in a container with role="region" (or "group") and give it an accessible name like "Products carousel." Use an aria-live region so slide changes are announced — "polite" for user-triggered changes, and "off" for auto-rotating carousels so they don't overwhelm the user with constant chatter. Communicate the selected slide with aria-selected="true" (for tab-style pickers) or equivalent hidden text.

For a deeper, example-by-example walkthrough of each of these — written from real audit experience — BarrierBreak’s breakdown of the top ARIA implementation errors is a useful companion to keep bookmarked.

Best Practices for Getting ARIA Right

• Reach for native HTML first. ARIA is a fallback for when semantics don’t exist, not a default.
• Follow the ARIA Authoring Practices Guide (APG). It provides tested patterns for accordions, tabs, carousels, and more — don’t invent your own.
• Keep states in sync with reality. Any attribute that reflects state (aria-expanded, aria-pressed, aria-selected) must update on interaction.
• Test with real assistive technology. Screen reader and keyboard testing catch ARIA errors that automated tools and visual inspection miss entirely.
• Include people with disabilities in testing where you can — some of these errors only surface through genuine use.

Common Mistakes to Avoid

• Adding ARIA to “be safe.” Redundant or incorrect ARIA can override correct native semantics and make things worse.
• Setting a state once and forgetting it. Static aria-expanded or aria-pressed values are a leading cause of confusion.
• Assuming visual correctness equals programmatic correctness. A component can look perfect and still tell assistive technology the wrong thing.
• Skipping accessible names on landmarks, regions, and custom controls.

Conclusion

Avoiding ARIA implementation errors comes down to a few disciplined habits: prefer native HTML, apply only the roles and attributes that truly match an element, keep states updated as users interact, and verify everything with real assistive technology. ARIA is a precise tool — powerful when it’s right, actively harmful when it’s wrong. Get it right, and dynamic interfaces become genuinely usable for everyone; get it wrong, and you’ve built confident-sounding barriers. When in doubt, remember the rule that never fails: no ARIA is better than bad ARIA.

For teams that want expert help auditing and fixing these issues at scale, BarrierBreak provides accessibility testing and remediation grounded in exactly this kind of real-world experience.

FAQ

What is ARIA and when should I use it? ARIA (Accessible Rich Internet Applications) is a set of roles, states, and properties that make dynamic content understandable to assistive technology. Use it only when native HTML can’t convey the needed semantics — native elements are always the safer first choice.

Why is bad ARIA worse than no ARIA? Because incorrect ARIA overrides what assistive technology would otherwise infer, actively communicating wrong information — like labeling a heading as a button. Missing ARIA is a gap; wrong ARIA is misinformation.

What’s the most common ARIA mistake? Misusing roles, states, and properties — applying a role that doesn’t match an element’s purpose, or setting a state (like aria-pressed or aria-expanded) that never updates when the user interacts.

How do I fix an accordion that doesn’t announce its state? Add aria-expanded to the control: "false" when collapsed, "true" when expanded, and update the value on every toggle so assistive technology reflects the real state.

Can automated tools catch all ARIA errors? No. Automated tools catch some, but many ARIA problems — especially states that don’t update or roles that mislead — only surface through manual screen reader and keyboard testing.

Where can I find reliable ARIA patterns? The W3C’s ARIA Authoring Practices Guide (APG) provides tested implementation patterns for common components like tabs, accordions, and carousels.