Cognitive distortions that hide accessibility problems

Perceivio·16 April 2026

Where the phrase comes from

Cognitive behavioural therapy (CBT) uses the term for patterns of thinking that feel like facts: the one bad review that stands for the whole year, the assumption that silence means agreement.

We borrow the frame for engineering decisions and nothing more. It is an analogy, not a diagnosis, and nobody in a product meeting needs a diagnosis. It is useful because the failures are recognisable the moment they are named out loud.

Six that we hear often

• Nobody has complained. Absence of evidence read as evidence of absence. People who cannot complete a purchase rarely email to say so; they leave, and the analytics record a drop off with no reason attached.
• The scanner says we pass. An automated tool confirms what is visible in the code. It cannot judge whether a name makes sense, whether the order of a flow survives without a mouse, or how a screen reader announces a custom control.
• We support screen readers. Which one, at which version, on which browser, on which device? A support claim without a list is a claim about intention rather than a claim about behaviour.
• It is only the one page. True in isolation and misleading in a sequence. Ten small barriers across one task are worse than one large barrier, because no single ticket looks worth scheduling.
• We will do it after launch. Retrofitting a component that was designed without a focus state costs more than designing it with one, and the launch date is the reason the decision was deferred, not the thing that resolves it.
• We commissioned an audit, so we are done. A report is evidence. Until each finding has an owner, a change and a retest, the audit has bought you knowledge and nothing else.

What breaks each one

The counter to every item above is a practice that produces an observable fact, not a better feeling.

• Search the support inbox for cannot, stuck, confusing and gave up. Complaints arrive in the language of a support ticket, not the language of accessibility.
• Run one real task end to end with a screen reader, on the browser your users have. It takes twenty minutes and it settles the argument about the scanner.
• Write down the browser, assistive technology and device combinations you claim to support. That list is the scope of every test you run afterwards.
• Count the steps a task takes, and count how many of them can fail. A task with eleven steps and no way to recover at step nine is a different problem from a broken link.
• Put the accessibility criteria for a component into its own definition of done, beside its tests. The cheapest place to fix a focus state is the component, once.
• Give every finding a severity, an owner and a retest date, which is the format of our sample report and the reason we run regression testing.

How this shapes our own work

We order findings by severity, not by how easy they are to fix, because a report sorted by convenience teaches the reader to work through it in the wrong order.

We retest every fix and put the result in writing, including the fixes that did not hold. And we do not call a product accessible, because the honest version of that sentence takes a scope, a date and a list of criteria.

The wider subject is in cognitive accessibility in a digital product, and the memory side of it is in what cognitive psychology says about interface memory load.