Assistive-Technology Labeling Pass¶

Accessibility protocol — instantiates Latent Affordance Surfacing

Walks the interface with the assistive-technology stack and gives every affordance a programmatic name, role, and state — so a capability that is visible on screen stops being invisible to non-visual users.

An affordance can be perfectly obvious on screen and still be practically absent for a whole class of users, because a screen reader, switch, or voice-control tool sees only the accessibility tree, not the pixels. Assistive-Technology Labeling Pass is the protocol that traverses the interface through that tree and ensures every real control exposes an accurate name, role, and state — so the same affordance is available in a second, non-visual modality. Its distinguishing idea is that it operates on the channel sighted design ignores: a button rendered as a bare glyph is a fully-signalled affordance to a mouse user and a nameless "button" to a screen-reader user, and this pass is what closes that specific gap by supplying the redundant cue and the operable path to act on it.

Example¶

A mobile banking app renders its "Transfer money" action as an unlabeled arrows icon. Sighted users tap it without thinking; a customer using VoiceOver hears only "button," so the transfer capability is, for them, latent. An Assistive-Technology Labeling Pass drives the app with the actual screen reader and finds the gap. It assigns an accessible name and role — the control now announces "Transfer money, button" — and exposes state where it matters, so a paperless-statements toggle reads "Paperless statements, switch, off" rather than a silent box. It then repairs focus order so that swiping moves logically through the transfer flow and the confirm button is reachable without a mouse, with no keyboard trap on the amount field.

The capability was never missing; it was only unspoken. After the pass, the same transfer that a sighted user could always see is now perceivable and operable in the auditory-plus-keyboard modality — the affordance has been made real for the people the visual signifier never reached.

How it works¶

Traverse through the assistive stack, not the visual layer. Operate the interface with a real screen reader, switch scanning, or voice control and inspect the accessibility tree — the representation those tools actually consume.
Supply name, role, and state. For each affordance that renders without a programmatic label, assign an accurate accessible name, the correct role, and any dynamic state, so the tool can announce what the control is and does.
Restore the operable path. Fix focus order, hit targets, and keyboard reachability so the announced affordance can actually be completed in the non-visual modality — a labeled control you cannot reach is still absent.

The pass is distinguished by whose perception it serves: it adds a redundant channel rather than a new feature, targeting the modality the visual surface leaves empty.

Tuning parameters¶

AT coverage — screen readers only, or switch access, voice control, and magnification too. Broader coverage catches more modality gaps but multiplies the traversal work.
Label verbosity — terse names versus rich descriptions. Richer labels help first encounters but, past a point, bury the affordance in chatter that users learn to tune out.
Automated vs. manual mix — linters and scanners catch missing labels cheaply; only manual AT use catches labels that are present but wrong or meaningless. Leaning automated is fast and false-confident.
Conformance target — which standard tier you audit against (e.g. WCAG A, AA, AAA). A higher target closes more gaps and costs more per screen.
Focus-management aggressiveness — how forcefully the pass moves or traps focus to guide the flow. More control aids completion but can hijack the user's own navigation.

When it helps, and when it misleads¶

Its strength is that it converts an affordance that is legally and ethically invisible into a usable one, and the labeling discipline routinely clarifies controls for everyone — an unlabeled glyph is a hazard to sighted novices too. It is also the one surfacing move that a purely visual audit structurally cannot make.

Its failure modes cluster around proxy for real use. Automated scans grant false confidence: an interface can pass every checker and remain unusable because the labels, though present, are wrong ("button button") — meeting the letter of a name-role-value requirement while failing its intent.^[1] Over-labeling inverts the problem, drowning the affordance in redundant announcements. And the classic misuse is accessibility theater — labeling to clear an audit checkbox rather than to be operable, then never testing with an actual assistive-technology user. The discipline that guards against all three is to validate with real AT users completing real tasks, not with a linter's green tick.

How it implements the components¶

Assistive-Technology Labeling Pass realizes the redundant-modality side of the archetype — making an existing affordance perceivable and operable in a second channel:

modality_and_accessibility_redundancy — its core: the same affordance is carried in a non-visual modality (auditory, programmatic, keyboard) so it survives the loss of the visual channel.
affordance_signifier_design — the accessible name, role, and state are the signifier in the accessibility tree; the pass authors that programmatic cue.
action_path_continuity — focus order and keyboard operability keep the path unbroken so the announced affordance can actually be completed.

The gap-finding and cue-placement components — latent_capability_inventory, effective_option_set_gap, surface_placement_and_timing_rule — belong to Affordance Visibility Audit and Call-to-Action Placement Test; this pass makes affordances reachable in another modality, it does not choose which to surface or where to place the visual cue.

Instantiates: Latent Affordance Surfacing — this pass surfaces affordances for the modality the visual surface leaves empty.
Sibling mechanisms: Contextual Hint or Tooltip · Signage and Wayfinding Revision · Guided Walkthrough or Onboarding Step · Call-to-Action Placement Test

Notes¶

The redundancy this pass supplies has a direct analog in the built environment: tactile paving, audible crossing signals, and Braille floor buttons make a physical affordance perceivable in a second modality by exactly the same logic. Framing the pass as modality redundancy rather than "compliance" is what keeps it aimed at genuine operability instead of a checklist.

References¶

[1] WCAG success criterion 4.1.2, Name, Role, Value, requires that every user-interface component expose its name, role, and state to assistive technologies. The pass implements that criterion — but the criterion can be met mechanically (a name exists) while its intent is missed (the name is meaningless), which is why real-AT testing, not automated conformance alone, is the honest bar. ↩