Web accessibility: the errors that appear in 9 audits out of 10

After several accessibility audits, a pattern emerges: the same errors come back, almost regardless of context. Projects differ - sectors, technologies, team sizes - but the non-conformities look alike. That is not a coincidence, and it is not a team competence problem. It is a process problem: these errors are only visible if you actively test for them. And the standard acceptance testing, most of the time, does not.

The classics

Five error categories concentrate the majority of non-conformities I find from one audit to the next.

Colour contrast

Insufficient contrast on secondary text, disabled states, and form placeholders is the most frequent error - and the least detected, because designers test contrast on primary text, not on all interface states. Accessibility standards require a ratio of 4.5:1 for normal text and 3:1 for large text (above 18px bold or 24px normal). Disabled buttons (opacity: 0.4 on light text) often fall below this threshold without anyone checking.

Labels and forms

A form field with no explicit label, or with a label that is visual only (placeholder used as the sole indicator), is a critical accessibility error. It is systematically found in failure on contact forms built quickly or inline search forms. The fix is simple (a label tag associated via for/id attribute, or aria-label), but it requires testing with a screen reader to detect - which rarely happens in standard acceptance testing.

Text alternatives on images

Decorative images without an empty alt attribute, informational images with absent or non-descriptive alt text, charts without a description of their content. What complicates detection: CMS platforms often leave the alt field empty by default, and content contributors do not always know they need to fill it in, or how. The fix requires both technical work (HTML rendering check) and training editorial teams.

Keyboard focus and mouse-free navigation

Invisible keyboard focus (outline: none applied globally in CSS) is a widespread error. It is often introduced by a front-end developer who finds the keyboard focus ring "ugly" and removes it globally without measuring the impact on keyboard users. This type of change affects the entire interface and makes mouse-free navigation impossible or very difficult for users who depend on it.

• Insufficient colour contrast on secondary text and disabled states
• Form fields without an explicit label or with a visual-only label
• Meaningful images without relevant text alternatives
• Invisible or inconsistent keyboard focus in navigation order
• Dynamic content (modals, notifications) not announced to screen readers

Why they persist

These are not competence errors, but priority errors: these issues are only visible if you actively test with the right tools. Standard acceptance testing does not do this.

Not a competence problem

The developers who introduce these errors often know what accessibility is. What they do not do is test their code with a screen reader, navigate their interface with the keyboard, or check contrast with a dedicated tool. It is not bad faith - it is the absence of this check from their daily workflow. Training raises awareness, but does not change behaviour if the acceptance process does not require it.

An acceptance process problem

Functional acceptance testing tests what is visible in a standard browser with a mouse. It does not test keyboard navigation, screen reader reading, or contrast outside of nominal cases. Integrating these tests into acceptance - even minimally - changes the equation completely. It is not a process overhaul, it is adding a checklist on critical components.

The least costly fix

Integrate a basic keyboard and screen reader test on critical components from the acceptance phase, rather than waiting for the audit. The cost of fixing a non-conformity discovered in acceptance is 5 to 10 times lower than the cost of fixing it after production release.

The minimal checklist to integrate in acceptance

For each critical component (forms, main navigation, modals, alert messages), verify: keyboard navigability (Tab/Shift+Tab, Enter, Escape), focus visibility, presence and relevance of text alternatives, contrast ratio on all states, correct announcement of dynamic changes by NVDA or VoiceOver. This test takes 20 to 30 minutes per component. It detects 80% of recurring accessibility errors before they reach production.

These errors are not a technical inevitability - they are a process blind spot. Closing the blind spot costs far less than fixing errors after an audit. The question is not whether your interface is accessible - it is at what point in the development cycle you choose to check.