Why does giving a generic element an accessibility role not make it behave like that role, and what does the author still owe?

## A role describes; it does not implement Every platform lets an author declare what a generic element *is* for the purposes of assistive technology. That declaration edits one thing: the node in the accessibility tree. It has no effect on layout, on input handling, on focus, or on anything else the platform does. The element is now **announced** as a checkbox. It is not a checkbox. Everything else follows from that. A platform-supplied control arrives with its behaviour and its description already joined: it is focusable, it responds to the keys users expect, it reports its own state, and the tree stays in step automatically. Declaring a role on a plain container gives you the description half of that bundle and leaves the behaviour half unbuilt. The gap between what you announced and what you built is exactly the defect. ## The three debts a declared role creates | Debt | What a platform control does for free | What you owe once you declare a role | | --- | --- | --- | | **Reachability** | Enters the focus order and shows a focus indicator | Make it focusable and make focus visible on it | | **Operability** | Responds to the keys expected for that kind of control | Handle those keys yourself and match the conventions | | **State truth** | Reports its own state and notifies every change | Write the state annotation and update it on every change | A few things follow from the table that candidates routinely miss. - **Focus is not optional on touch-only hardware.** Switch access, alternative input devices and remote-support tooling drive interfaces through the same key semantics, so a kiosk with no attached keyboard still needs everything *2.1.1 Keyboard* (Level A) asks for. - **Operability means the expected keys, not any key.** A user who is told they have a checkbox will try the interaction a checkbox has. Handling only a pointer press satisfies nobody. - **State truth rots.** Reachability and operability are written once and stay written. The state annotation has to change every time the real state changes, so it drifts the moment someone adds a new way to change that state and forgets the annotation. ## Why wrong annotation is worse than none An unannotated block of content is announced as inert. A non-visual user passes over it, misses whatever it offered, and moves on - a real failure, but a cheap one, and one they can often route around by looking for another path to the same task. An element announced as a control makes a promise. The user stops, believes an action is available, spends the effort of activating it, and gets nothing - with no error, no explanation, and no signal that the fault is the product's rather than theirs. Worse, they now have reason to doubt every other announcement on the screen. The cost is not just the failed action; it is the loss of the model the interface was supposed to give them. This is also why automated results can be so misleading here. Machine checks are good at asking whether an annotation is **present** and **well formed**. They cannot ask whether it is **true** - whether the thing announced as expanded actually is expanded, whether the thing announced as a button can be operated. A screen densely covered in annotations can therefore report almost nothing while being unusable, and a screen built from plain platform controls can report the same near-zero score while working perfectly. ## A worked case A public transport ticketing kiosk goes through a procurement questionnaire due in nine days. The vendor runs an automated pass over the 41-screen purchase journey and reports a handful of issues. A tester then operates the same journey without the touchscreen and finds that 14 of the 41 screens contain a custom control declared as a widget role that cannot be reached at all, and that the seat-map screen announces every seat as available regardless of what the fare engine actually returned. The triage that a senior engineer is expected to produce runs in this order: 1. **Remove annotations that promise nothing real.** Any role declared on something that is not operable and never will be comes off first. It is the cheapest fix and it converts a broken promise back into honest silence. 2. **Replace what a platform control can do.** Every custom control that has a platform equivalent gets replaced. This retires all three debts at once and is the only change that stops the class of defect from recurring. 3. **Complete the ones that must stay custom.** Whatever genuinely has no platform equivalent gets focus, keys and state finished properly, and gets a test that operates it rather than merely inspecting it. 4. **Fix state truth last, but fix it.** The seat map's stale state is the subtlest defect and the one most likely to return, because it depends on the annotation being updated at every point the underlying data changes - so the fix belongs at the single place that data is written, not at each place it is displayed. Notice that the questionnaire's deadline does not change the order. Removing false promises is both the fastest work and the largest honest improvement, which is a useful thing to be able to say out loud when someone asks for the pass rate to go up by Friday.