2. Functional Accessibility

The definition

An interface is functionally accessible to a particular user, in a particular context, if at least one combination of communication medium and protocol exists through which that user can complete the interaction the interface is for. The definition is deliberately weak: it does not require the user to have the same experience as anyone else, only that some path through exists.

Three things in that sentence carry weight.

First, negotiation. Functional accessibility is not a property the interface has on its own; it is the outcome of an interaction between user and provider. The same interface can be functionally accessible to one user and not to another. The same user can have functional access through one combination of medium and protocol and not through a different combination. The accessibility status is relational, not intrinsic.

Second, at least one. The condition is existential, not universal. If a single medium-and-protocol path succeeds, the interface meets the definition for that user-and-context. The other paths can fail; the alternative mediums can be unusable; only one needs to work.

Third, at that time and place. Functional accessibility is dated. A tool that worked on yesterday’s assistive-technology stack may not work on today’s. A tool that works in a quiet room may not work on a factory floor. The definition is bound to its conditions; it does not promise anything about portability across contexts.

Multi-medium robustness

The “at least one” condition is what makes the definition non-trivially testable. Most interfaces admit several possible medium-and-protocol paths: a web form can be filled in by sighted typing, by screen-reader navigation with keyboard, by voice control invoking text input, by switch-access scanning with auto-complete, by a screen magnifier with mouse, by a refreshable braille display with chord input. Each path is a candidate for the “at least one.” The interface is functionally accessible if any of them complete the task; it fails the definition only if all of them do.

That is a strong test in two directions and a weak test in one. It is strong against the failure mode where a single path is assumed and the others are not considered — the “works in Chrome with a mouse” baseline that pretends no other path exists. It is strong against the failure mode where accessibility is treated as a single accommodation for a single user category — the “we added a screen-reader mode” line that ignores switch users, low-vision users, motor-impaired users, and any combination thereof. The definition forces the question which paths actually work, and for whom?

The weak direction is that the definition is indifferent to which path succeeded. A user who can complete the task only via an assistive technology that costs them more time, more attention, and a more degraded experience than other users still counts as functionally accessible under the definition. Equivalent experience is a different question and is treated on page 4; the definition here gives a floor, not a target.

The capacity-requirement match

The formal core of the definition is a match between two structures. The user, in their context, has a capacity— what they can actually do in this body, on this device, at this moment, with these inputs and outputs. The interface, for each medium-and-protocol path it offers, has a requirement— what the user would need to bring to the interaction for that path to succeed. A path is available to the user when the user’s capacity meets or exceeds the path’s requirement; the interface is functionally accessible when at least one of its paths is available.

Both sides of the match are runtime properties. Capacity changes — with fatigue, with the time of day, with the device the user picks up, with whether their other hand is occupied, with how much battery the hearing aid has left. Requirement changes too — with which features of the interface the user has reached, with what content is loaded, with what external services are reachable. The match is evaluated against a snapshot, not a static specification. The same user with the same interface can pass the test in the morning and fail it in the evening; the definition admits that and does not try to wave it away.

The capacity-and-requirement structures are formalised in detail on page 3, where the same machinery generalises across user-populations rather than just naming a single user. On the functional side, the structure has one fixed user and one fixed context; on the intrinsic side, it quantifies over all of them.

Where bolt-on assistive technology lives

Most assistive technology achieves functional accessibility, narrowly scoped, at high cost.

The PacMate is the canonical illustration. Freedom Scientific’s PDA, sold to blind users in the early 2000s, replaced the original device’s keyboard with a braille input keyboard and forced its output through text-to-speech. To its target users it was functionally accessible — the capacity-and-requirement match succeeded; the tasks could be completed. But the interface was no longer the original device. Sighted colleagues couldn’t pick it up to help. The braille input kept the user inside a parallel workflow. Software updates from the original platform didn’t apply. The price of functional accessibility was that the device was specialist; the user’s relationship to the wider ecosystem was mediated through hardware nobody else used.

That is the structural shape of bolt-on assistive technology in general. A specific user-population is named; a specialist medium-and-protocol path is built for them; the path satisfies the “at least one” condition; the cost is paid in narrowing, specialisation, and the loss of the ordinary user experience the rest of the population takes for granted. Functional accessibility holds; the deeper question of whether the underlying interface is the right shape goes unaddressed.

That deeper question is the territory of intrinsic accessibility. The two definitions are not in conflict; intrinsic accessibility is what you ask for when functional accessibility is no longer enough.

Legal scoping, and its limits

The legal vocabulary of accessibility maps onto functional accessibility almost exactly. The ADA, the AODA, the European Accessibility Act, the Accessible Canada Act — all of them, in different jurisdictions, name accessibility as a property a service owes to a class of disabled users, and evaluate compliance against the question can the user complete the task? If yes, compliant. If no, not compliant. That is the functional condition.

The legal scoping is useful for what it is. It gives users a remedy when functional accessibility fails. It gives providers a baseline to clear. It gives procurement officers a checklist that can be enforced contractually. The threshold-style framing — accessible / not accessible — matches what regulation can do.

But the legal vocabulary cannot ask the deeper question. A web service that meets every WCAG criterion and complies with every applicable accessibility law can still ship interfaces that are functionally accessible only via heroically specialist paths — assistive layers grafted on, the underlying design unchanged, the cost of the accommodation paid by the user. Compliance is satisfied; the structural question is not. The legal floor is a floor, not a ceiling.

The rest of this collection is about what the ceiling looks like.

Continue

← Previous: 1. The Question · Next: 3. Intrinsic Accessibility →