Accessibility is usually framed as a design problem. Colour contrast. Keyboard navigation. Screen reader support. All true. All incomplete.
The patterns that actually cause accessibility failures in production are code patterns. <img> without alt text. <input> without a label. outline: none without a focus replacement. Buttons made from <div> elements because "they looked better". These are choices developers make in a code editor, and they are detectable by the same tools that detect security patterns.
The patterns that account for most failures
WCAG is long. The patterns that actually fail on real sites cluster around a short list.
Images without alt text. The single most common violation across the web. Screen readers announce "image" and move on. Users who cannot see the image learn nothing.
Fix: every <img> has an alt attribute. If the image is decorative, alt="" is correct. If it conveys meaning, the alt text says what. Detection: grep for <img without alt=.
Form inputs without labels. An <input type="text"> with no <label> attached is unlabelled. Screen readers announce "edit text" with no context. Users do not know what to type.
Fix: every interactive input has either a visible <label for="..."> or an aria-label or an aria-labelledby. Detection: similar regex.
Focus outlines removed without replacement. *:focus { outline: none } is a common line in stylesheets, added by designers who thought the default browser outline was ugly. The result: keyboard users cannot see where focus is. They cannot navigate.
Fix: if you remove the default outline, replace it with something visible. :focus-visible helps: it only fires for keyboard focus, leaving mouse clicks clean.
Click handlers on non-interactive elements. <div onclick={...}> creates a button that looks like a button but does not announce as a button. Screen readers skip it. Keyboard users cannot activate it.
Fix: use <button>. If you genuinely cannot (rare), add role="button", tabindex="0", and keyboard handlers for Enter and Space. Most of the time, <button> is the answer.
Heading structure broken. Skipping heading levels (<h1> to <h3> with no <h2>). Multiple <h1> on the same page. No <h1> at all.
Fix: heading hierarchy is how screen readers give users a page outline. Treat it with care. Detection: a linter can flag skipped levels.
Colour as the only signal. Red for errors, green for success, nothing else to distinguish them. Fails for colour-blind users.
Fix: pair colour with an icon, a label, or a pattern. The colour reinforces, but is not the sole carrier of meaning.
Why these patterns survive into production
Nothing fails catastrophically when accessibility is broken. The page renders. Mouse users can still interact. Automated tests pass. Nobody screams. The bug exists only for users who already struggle to report it.
This is why accessibility needs to be mechanical, not aspirational. Good intentions do not catch <img> without alt. Tooling does.
What catches these patterns
Static analysis of templates and components. Tools like axe, eslint-plugin-jsx-a11y, svelte-check, or the accessibility scanners built into modern CI pipelines flag the common violations automatically. They are cheap to run and produce deterministic results.
Focus outline detection in CSS. Grep for outline: none without a corresponding :focus-visible replacement. Flag it.
Keyboard navigation tests in integration testing. Can a user navigate your app entirely with the keyboard? If not, the keyboard experience is broken.
Screen reader testing, at least periodically. NVDA on Windows and VoiceOver on macOS are free. Spend an afternoon every quarter using your app with a screen reader. You will find real issues automated tools miss.
Accessibility is broader than the frontend
The patterns above are HTML and CSS. But accessibility thinking extends further.
API responses that return errors as codes without human-readable messages. A client application cannot tell the user what went wrong if the API only says ERR_4031.
PDFs without tags. If your system generates documents, tagging them properly is the same as providing structure to a webpage. Most PDF libraries have a tagging mode. Few teams use it.
Emails without text alternatives. HTML-only emails look great and fail for users with plain-text clients. Include both versions.
Videos without captions. A video without a caption track is inaccessible. Caption generation is cheap now. There is no excuse.
Accessibility as a code quality signal covers all of these. The common thread is asking "can a user with X constraint still get the value of this?" for any X.
What to put in CI
- A11y linter on templates and components.
- Focus outline check in stylesheets.
- Alt text check on all images (both templates and generated content).
- Keyboard navigation test as part of integration tests.
- Occasional manual screen reader review.
Not expensive. Not experimental. Standard practice in 2026.
The common misconception
Accessibility is not a niche. Roughly one in five users has a disability that affects how they use software. That is not a rounding error.
Beyond that: accessible code benefits every user. Keyboard shortcuts help power users. Clear labels help everyone, including users on mobile. Proper heading structure helps search engines. Alt text helps users on slow connections where images fail to load.
The pattern across all of these: accessible code is better code. Static analysis can catch most of the mechanical issues. Doing that is the floor. Above the floor, design and human testing fill the gap. But without the floor, nothing above it matters.
