Why Accessibility Tools Get Mistaken for Bots

Screen readers, switch access and voice control produce interaction that looks nothing like a mouse and keyboard session. Detection models trained on typical traffic classify that difference as automation, and the resulting harm is concentrated on people who have no alternative.

Navigation happens without pointer movement

A screen reader user moves through a page using keyboard commands and the accessibility tree rather than by pointing. There is no cursor path because the interaction model does not involve one.

Many behavioural systems treat the absence of pointer movement as a strong indicator, since automated clients commonly click without moving. The two cases are indistinguishable from the movement data alone.

Focus order also differs. Assistive navigation follows the document's semantic structure, which frequently does not match the visual reading order the model was calibrated against.

Input timing is generated rather than typed

Voice input and switch scanning produce text through mechanisms that have no keystroke rhythm at all. Characters arrive in blocks or at intervals determined by a scanning cycle rather than by finger movement.

Typing cadence models see either no cadence or an unnaturally regular one, both of which score as suspicious under rules designed to catch scripted input.

Assistive software also injects events programmatically at the platform level, so where a browser exposes any distinction between injected and hardware-originated input, assistive tools land on the wrong side of it.

Pacing is systematically slower and steadier

Working through a page with a screen reader takes considerably longer than scanning it visually, so session durations and dwell times sit well outside the usual distribution.

The pacing is also more uniform, because progress is governed by the tool's rate rather than by visual attention. Uniformity is one of the properties detection treats as machine-like.

Sessions that are simultaneously long and regular therefore trip both the timing checks and the anomaly detectors, compounding rather than cancelling out.

The affected population is small enough to be invisible

Assistive technology users are a modest fraction of traffic, so misclassifying most of them barely moves an aggregate false-positive rate.

Aggregate metrics therefore look healthy while a specific group is being consistently excluded, and nothing in a standard dashboard surfaces the pattern.

Finding it requires measuring error rates by segment rather than overall, which means deliberately identifying assistive sessions for evaluation purposes and being careful about how that data is handled.

Design choices that reduce the harm

Treating missing behavioural evidence as neutral rather than negative removes a large share of the problem, since absence of pointer data is not evidence of automation.

Recoverable actions matter more here than anywhere else. A challenge that can be completed without vision or precise pointing gives an affected user a path forward, whereas a silent block gives none.

In most jurisdictions this is also a legal requirement rather than a courtesy, since inaccessible verification is a barrier to service in the same way an inaccessible page is.