An audit of a product built largely from `<div>` elements annotated with ARIA roles reports almost no automated violations, yet screen-reader users describe the interface as unusable. Why can incorrect ARIA be worse than no ARIA, and how would you prioritise the fixes?

## Why ARIA is dangerous when wrong ARIA declarations are not hints. When you set a role, the browser stops exposing the element's own semantics and exposes yours instead; assistive technology has no way to detect that the declaration is false. That asymmetry is the whole answer: - **Silence is explorable.** An un-annotated div announces its text. A screen-reader user reads it, notices it looks like a control, tries clicking it with a pointer gesture or a virtual-cursor activation, and often gets somewhere. - **A false promise is a dead end.** `role="tab"` tells the user that arrow keys move between tabs, `aria-expanded` tells them a control opens something, `aria-checked` tells them a state can be toggled. When the behaviour is not implemented, the user does the right thing and gets nothing — and now they distrust every announcement on the page. Wrong ARIA also *destroys* information that was already correct. `<button role="link">` throws away a working button's semantics. `role="presentation"` on a table strips the header relationships the browser had computed for free. Every override is a bet that your hand-written model is better than the platform's. ## Why the automated score is clean Rule engines such as axe-core test properties that are decidable from the DOM: is the role a real role, are required owned elements present, does every `aria-labelledby` ID resolve, is there a name on a control, is contrast sufficient. These are genuinely useful — and they are all *syntactic*. No static rule can answer the questions that matter here: does this `role="tablist"` actually implement roving-tabindex arrow navigation? Does `aria-expanded` flip when the panel opens? Does `aria-checked` match the visual state after the user acts? Does the accessible name still describe the control after the label was reworded? Truthfulness is a runtime, behavioural property. Treating a clean automated score as a pass is the specific management error that produces this codebase — the metric was optimised, the users were not. ## How to triage Work by *what stops a user completing a task*, not by rule count. **1. Operability.** Find controls nobody can reach or activate: interactive elements not in the tab order, custom widgets with no keyboard implementation, focus that is lost after an action. A control that cannot be operated is a hard blocker regardless of how it is announced. **2. Role truth.** Find declarations that promise behaviour the code does not implement — composite widget roles being the worst offenders, because each one implies a whole keyboard contract. The fix is usually to delete the role, not to implement it. **3. State accuracy.** Find states that are set once and never updated. A stale state is worse than an absent one because the user acts on it. **4. Names and descriptions.** Wrong or missing accessible names are real defects but rarely block a task outright once the control is operable and honestly typed. ## The cheapest fix is deletion For each finding, ask first whether a native element covers it. Replacing a div-plus-ARIA control with `<button>`, `<a href>`, `<input>`, or a real table removes several findings at once and removes the code that could drift back out of sync. It is a *subtraction* change: fewer attributes, fewer handlers, less to test. Reserve hand-built widget patterns for the shapes HTML genuinely lacks, and treat each one as an owned component with tests rather than markup someone typed inline. ## How you verify Behavioural checks, because the automated ones already pass: - **Keyboard-only pass.** Unplug the mouse and complete the product's top tasks. Every interactive element must be reachable, operable, and visibly focused. - **Screen-reader pass on the critical flows.** Listen for the mismatch between what is announced and what happens. - **Regression tests at the accessibility-tree level** — assert the computed role, name and state of key controls rather than asserting that an attribute string is present, so a refactor that changes the element is caught. ## Framing for the interview The sentence to land: ARIA is a promise to the user, and an unkept promise costs more than silence. Then show the triage order and the bias toward deleting ARIA rather than completing it. If you can add the organisational half — automated scores are a floor, not a definition of done — you are answering at the level the question is aimed at.