ARIA validity checker

Role names against the specification. An unknown role is not partially applied; it is ignored, and the element falls back to its native semantics.

Whether the role is permitted on that element, since some combinations are explicitly invalid and produce inconsistent results across assistive technologies.

Whether the states and properties used are defined for the role in question — a property valid on one role and meaningless on another is a common copy-and-paste outcome.

Whether required properties are present, because several roles are incomplete without them and announce nothing useful in that state.

Reference attributes: every identifier they point at must exist in the document.

A label reference pointing at an identifier that does not exist produces a control with no accessible name. A screen reader announces its role and nothing else.

Nothing about the page looks wrong. The visual label is rendered exactly as intended; only the connection is missing.

The usual causes are mechanical: a component library generating identifiers per instance while the reference is hard-coded, a server-rendered identifier that changes on hydration, or a label removed at some point while its reference stayed.

The same applies to a description reference, which silently drops the help text under a form field.

These are exact failures with exact fixes, which is why they belong in an automated check rather than in a manual review.

Marking an element hidden from assistive technology removes it and its entire subtree from the accessibility tree.

When that subtree contains something focusable, the result is a control a keyboard user can reach and a screen reader cannot describe — focus lands somewhere that announces nothing.

This happens most often on a container: an off-screen menu or a closed dialog hidden from assistive technology while its buttons remain in the tab order.

The correct pairing is to remove such elements from the tab order at the same time, or to hide them by a means that removes them from both.

Frames are checked alongside: an embedded frame without a title is announced as an unlabelled region, which for a page containing several is genuinely disorienting.

Native elements carry their semantics already. A button element is a button to every assistive technology without a single attribute.

ARIA overrides those semantics, which means a wrong attribute actively replaces something correct with something that is not.

So no ARIA is better than wrong ARIA, and the first question on any finding here is whether the attribute is needed at all.

A large amount of ARIA on a page is itself worth looking at: it frequently means custom controls were built where native elements would have done the work.

`accessibility.aria_validity` validates roles, states and properties against the specification. `accessibility.aria_references` verifies that reference attributes point at identifiers that exist.

`accessibility.aria_hidden` detects interactive elements hidden from assistive technology while remaining reachable.

`accessibility.iframe_title` reports embedded frames without a title. `accessibility.semantic_landmarks` reports the landmark structure the roles above sit inside.

ARIA applied by script after the page renders is not in the served markup and is outside this check.

A valid attribute is not necessarily a correct one. A control correctly marked with a role it should not have passes every validation here and is still wrong.

What a specific screen reader announces varies between implementations. What is validated is conformance to the specification, not behaviour in any one product.

Passing this check does not mean the page is usable with a screen reader. It means the markup contains no attribute that is invalid on its face.