J5.03.2ARIA misusedesignresearch

Wrong ARIA is worse than none

Aliases: bad ARIA · false semantics · ARIA lie

What it is

If the control is missing from the tree, the user treats it as absent and looks for another path. If the tree says “checkbox” and the thing is a link, the user runs the checkbox script and nothing happens. Wrong ARIA is a lie; absence is a hole. Assistive technology trusts the tree. A lie hurts more than a hole: holes can be walked around, lies lead into dead operations.

Why it happens

With no node, the user’s model is “there is no control here”; the next move is to hunt another entry, and the cost is a miss. With a wrong role or state, the model is “this is a checkbox that toggles”; the next move is the toggle command — issued under the contract, answered by a different logic. Expectation breaks. Once trust breaks, later correct announcements are treated as unreliable too.

A hole is silence; a lie is active misdirection. Reader users have no pixels to check whether it “looks like a checkbox”; the tree is the whole evidence. A wrong supplement forges the only evidence source, which is why it is worse than leaving the hole.

Studying it

Same visual widget, three trees: no ARIA, correct ARIA, deliberately wrong role or state. Compare task success, first command, and whether users still trust later announcements after a failure.

Independent variables: missing / correct / wrong attributes. Dependent variables: completion rate, count of wrong commands, rate of switching to vision or another channel after failure (when residual vision exists).

Use experienced users. Novices cannot tell “not announced” from “announced wrongly,” and will collapse both failures into “the reader is bad.”

Where it stops holding

An attribute the engine ignores (an unimplemented role) behaves closer to absence than to a lie; harm sits between the two. An error that happens to match real behavior will not show in a short test and will blow up on a different operation. For magnifier users who never take the tree, the claim barely holds. Automation catches some illegal values; it does not catch “legal but untrue” — and a legal lie is the expensive kind.

Applying it

  • If unsure, do not write ARIA. Let the object stand as a native control or as plain text rather than wear a role that contradicts its behavior.
  • When name and behavior disagree, delete the wrong attribute first, then decide whether to add a right one. Leaving the wrong one in place blocks more than leaving a hole.
  • How to check: listen to the type the reader announces and operate by that type’s convention. If it is announced as a widget it cannot behave as, remove the attribute and retest — “cannot find it” after removal is already cheaper than “finds the wrong method.”

Related

  • Same group: J5.03.1 ARIA is for when native semantics fall short · J5.03.3 Prefer native semantic elements
  • Nearby: J5.02 Accessibility Tree and Roles · J5.11 Correct Use of ARIA
  • Search terms: ARIA misuse · first rule of ARIA · false semantics

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J5.03.2