Structural problems cannot be patched later

What it is

A whole page painted on a canvas, a task that can only be finished by dragging, content virtualised so assistive technology never sees nodes outside the fold — these are not two missing attributes. Structural inaccessibility means that if name, role, focus order, and the timing model never entered the architecture, overlay widgets and style patches cannot rebuild a real accessibility tree. It looks “added.” The tree is still empty. This is not the same sentence as “it is expensive”: some surface issues can be patched later; a structural issue patched later is a semblance.

Why it happens

Assistive technology consumes a contract of structure and behaviour, not pixels. When the contract is missing, a runtime patch can only change the visible layer: a high-contrast overlay, auto-generated alternative text, a box drawn around focus. The second layer is that fake repair blocks real repair — scanners start reporting passes, management believes the structure has been repaid, and a genuine keyboard model and semantic headings never re-enter the schedule. If a virtualised list never puts off-screen nodes into the accessible tree, no number of live regions will invent a heading outline you can jump. If dragging is the only way to sort, and there is no equivalent button or input, a patch cannot invent an operation that was never designed.

Studying it

Split failures into surface (contrast, copy, visible focus style) and structure (no role, no focus order, no keyboard model, a time limit baked into the engine). On pages that claim an “accessibility overlay” or a late ARIA spray, compare the accessibility tree and a keyboard walk before and after, and see whether names and roles actually appeared.

Independent variables: repair tactic (style / attribute spray / overlay / structural rewrite). Dependent variables: whether the tree gained the right roles and names; whether the keyboard can finish the task; whether the overlay fights native controls.

Use failed patches themselves as evidence. Do not substitute a cost figure for a structural judgement.

Where it stops holding

Label association, contrast, captions, and visible focus style belong to a layer that can be added later; do not inflate them into “nothing can be patched.” Sometimes the “patch” is rewriting that slice — the claim is not a ban on change, it is that a small patch is not enough. Games and authoring canvases can put structure in the tool layer (menus, property panels) rather than in the pixels, provided that layer really has a tree. Switching from server rendering to client virtualisation can destroy structure that already held; that is structural inaccessibility introduced late.

Applying it

• Architecture review keeps an unpatchable list: canvas-only content, drag as the only path, information structure with no headings, an unpausable timed engine. A hit means the interaction model must change, or a real structural channel must be added. Overlays alone are not allowed.
• Virtualised lists must keep nodes the user is interacting with, and nodes about to enter the viewport, in the accessible tree. Semantics cannot wait until a pixel is on screen.
• An overlay must not be the definition of done for a structural fix.
• How to check: open the accessibility tree on a page claimed as patched, and finish the main task from the keyboard. No matching role and name, or a step that can only be dragged, means it is not patched. Turn the overlay off and retest; if behaviour collapses, the structure never entered the product.

Related

• Same group: J1.09.1 Retrofitting costs far more than building accessibility in · J1.09.3 Accessibility belongs in requirements, not in the acceptance checklist
• Nearby: J5.02 Accessibility Tree and Roles · J3.05 Single Pointer Alternatives
• Search terms: structural inaccessibility · accessibility overlay · accessibility tree