ARIA Checker: Find and Fix Broken ARIA Before It Breaks Accessibility

What ARIA Actually Is (and Is Not)

ARIA stands for Accessible Rich Internet Applications. It is a set of HTML attributes that describe the role, state, and properties of an element to assistive technology such as screen readers. A role says what an element is (for example role="tab" or role="dialog"). A state describes its current condition (for example aria-expanded="false" or aria-checked="true"). A property adds supplemental meaning that native HTML cannot express on its own (for example aria-describedby pointing to a hint, or aria-haspopup on a menu trigger).

Here is the part most teams miss. ARIA changes only what is announced to assistive technology. It does not add behavior. Putting role="button" on a div does not make it focusable, does not make it respond to the Enter or Space keys, and does not give it a click handler. ARIA relabels the accessibility tree. Your JavaScript, your focus management, and your keyboard handlers still have to do the actual work.

Because ARIA is a promise to the screen reader rather than a behavior, incorrect ARIA is worse than no ARIA. It tells users something is true when it is not. That is why an ARIA checker is not a nice-to-have. Data from the WebAIM Million analysis has repeatedly shown that home pages using ARIA average more detectable accessibility errors than pages without it, largely because of misuse rather than the technology itself.

The First Rule of ARIA: Do Not Use It If Native HTML Can

The W3C states the first rule of ARIA plainly. If you can use a native HTML element or attribute that already has the semantics and behavior you need, use it instead of repurposing a generic element and bolting on an ARIA role. Native elements come with keyboard support, focus behavior, and correct semantics built in and maintained by the browser. You get all of that for free, and it keeps working as browsers and assistive technology evolve.

A concrete example. A team builds a custom control as <div role="button" onclick="...">Submit</div>. To make that even close to correct they now have to add tabindex="0", a keydown handler for both Enter and Space, a disabled state that also blocks the handler, and correct focus styling. Every one of those is a chance to introduce a bug. A plain <button type="button">Submit</button> does all of it natively, in every browser, with zero JavaScript. The same logic applies to <a> for navigation, <input type="checkbox"> instead of role="checkbox", <nav> instead of role="navigation", and <ul>/<li> for lists.

ARIA earns its place when native HTML genuinely cannot express what you are building: tab panels, tree views, comboboxes, live regions that announce dynamic updates, and complex custom widgets. For those, follow the ARIA Authoring Practices Guide (APG) pattern exactly, because those patterns define the full contract of roles, states, and keyboard behavior. AccessGuard's fix guidance points you to the right native element first and only recommends an ARIA pattern when there is no native equivalent.

Common ARIA Misuse AccessGuard Flags

Most ARIA problems fall into a handful of repeatable patterns. AccessGuard is tuned to detect them and explain why each one hurts real users.

Redundant roles restate what an element already is, such as <button role="button"> or <nav role="navigation">. These add clutter and occasionally suppress the native role. Interactive elements hidden from assistive technology are more serious: aria-hidden="true" placed on a focusable link, button, or form field removes it from the screen reader while leaving it visible and clickable, stranding screen reader users who can still tab into invisible-to-them content. Overriding meaningful text is another frequent one, where aria-label replaces good visible link or button text with something vaguer, breaking the match between what a voice-control user says and what they see.

Other high-frequency issues include role="button" on a link (screen readers then tell users to press Space, but links only activate on Enter), abstract roles used directly (roles like widget or composite that are for the spec, not for authors), and invalid attribute values such as aria-expanded="yes" instead of true or false. AccessGuard reports each finding against the relevant WCAG success criterion, usually 4.1.2 Name, Role, Value, so you can prioritize by conformance impact rather than guesswork.

Required ARIA Attributes and How the Checker Verifies Them

Many ARIA roles are incomplete on their own. They have required states and properties that must be present, and required owned elements that must exist inside them, or the role does not function. A role="checkbox" requires aria-checked. A role="combobox" requires aria-expanded. A role="slider" requires aria-valuenow, and usually aria-valuemin and aria-valuemax. A role="tab" must live inside a role="tablist" and reference its panel. Ship the role without its required attributes and the screen reader announces a control whose state it cannot report.

These requirements also shift between ARIA versions. As one example, aria-controls was required for the combobox role in ARIA 1.2 and then dropped from the required set in ARIA 1.3. A useful ARIA checker has to track the current specification rather than a snapshot from a few years ago, which is exactly the kind of drift that hand-written checklists miss.

AccessGuard validates the full contract for each role it finds: required states and properties are present and hold valid values, referenced IDs in attributes like aria-labelledby, aria-describedby, and aria-controls actually resolve to elements on the page, and the required parent and child structure exists. When something is missing, the report names the exact attribute, the element, and the corrected markup so a developer can apply the fix without hunting through the spec.

How AccessGuard Reports and How You Fix It

Run any URL through the free AccessGuard scanner and you get a prioritized list of ARIA and broader WCAG findings. Each item includes the specific element and selector, a plain-language explanation of who it affects and why, the WCAG success criterion it maps to, and concrete fix guidance with corrected code. The goal is not to hand you a wall of raw violations but to make the next action obvious, whether that is deleting a redundant role, swapping a div for a native button, or adding a missing aria-checked.

For teams that ship continuously, AccessGuard also offers a WordPress plugin, exportable PDF reports for stakeholders and audits, and a dashboard to track issues over time and confirm regressions do not creep back in. Automated scanning catches the large, consistent set of machine-detectable problems, which is the majority of common ARIA misuse. Pair it with manual keyboard and screen reader testing for the judgment-based checks that no scanner can fully automate.

A note on scope. AccessGuard provides accessibility scanning, WCAG issue detection, EAA readiness signals, and developer fix guidance. It is not legal advice and does not guarantee legal compliance or conformance. Use it to find and fix real barriers quickly and to build a defensible, documented process, and consult qualified professionals for formal compliance decisions.

• Prefer native HTML elements before reaching for any ARIA role
• Never place aria-hidden on focusable or interactive elements
• Delete redundant roles that restate the element's native role
• Provide every required state and property for each role you use
• Make sure aria-labelledby, aria-describedby, and aria-controls point to real IDs
• Follow the ARIA Authoring Practices Guide pattern for custom widgets

Frequently asked questions

More accessibility checkers