Over time, a pattern became difficult to ignore.
The accessibility issues that caused the most friction for users were rarely the ones that failed automated tools or basic checks.
They were smaller.
Quieter.
Often technically acceptable.
Many didn’t look like defects at all.
Custom UI that looks interactive but doesn’t behave like it. Page structures that make visual sense but collapse for assistive technologies. Focus states that exist briefly or subtly enough to be missed.
Content with text that technically satisfies requirements, but doesn’t communicate intent or meaning.
In most cases, tasks could still be completed. Sometimes slowly. Sometimes with repeated attempts.
That’s precisely why these issues survive.
They don’t block progress. They don’t cause obvious failure. They don’t always trigger defects with a clear severity.
Instead, they introduce extra work.
Extra remembering. Extra guessing. Extra effort that the system quietly hands off to the person using it.
When testing is framed around pass/fail outcomes, anything that still “works” tends to disappear from view.
These issues fall into the gaps between tooling, criteria, and delivery pressure. Not because they are rare, but because they succeed just enough to avoid being named.
Accessibility testing changed what I pay attention to after checks pass.
I now look for problems that don’t announce themselves as faults — only as accumulated effort.
They are rarely loud.
But they are consistent.
And they shape the experience far more than their invisibility suggests.