Roughly one in six people worldwide lives with a significant disability. On the web, that translates to visitors using screen readers, navigating with only a keyboard, zooming to 400 percent, or struggling with low-contrast text. Accessibility, often shortened to a11y, is the practice of building sites all of them can use.
The good news: most accessibility failures come from a small set of common mistakes, and none of the fixes require special talent. This guide covers the principles behind the WCAG standard, the failures that show up on nearly every site, and a testing routine you can run without any budget.
Why Accessibility Is Worth Your Time
Beyond the ethical case, which is real, there are three practical arguments:
- It is a legal requirement in much of the world. The Americans with Disabilities Act in the US, the European Accessibility Act, and similar laws elsewhere increasingly apply to websites. Accessibility lawsuits are common and settlements are expensive.
- It overlaps heavily with SEO. Screen readers and search crawlers consume the same structure: headings, alt text, semantic HTML, link text. Fixing one improves the other.
- It helps everyone. Captions serve people in loud cafes. High contrast serves phones in sunlight. Keyboard support serves power users. Clear language serves tired people, which is all of us.
Understanding WCAG in Five Minutes
The Web Content Accessibility Guidelines (WCAG) is the international standard, currently at version 2.2. It organizes requirements under four principles, abbreviated POUR:
- Perceivable: users must be able to sense the content. Images need text alternatives, videos need captions, text needs sufficient contrast.
- Operable: users must be able to work the interface. Everything must function with a keyboard, targets must be reachable, nothing may trap focus.
- Understandable: content and controls must make sense. Clear labels, predictable navigation, helpful error messages.
- Robust: content must work with assistive technologies, which mostly means valid, semantic HTML.
Each requirement has a conformance level: A (minimum), AA (the standard target, referenced by most laws), and AAA (aspirational). Aim for AA. You do not need to memorize the document; the failures below cover the large majority of what audits find.
The Eight Most Common Failures and Their Fixes
1. Insufficient color contrast
The single most common failure on the web. Light gray text on white backgrounds fails constantly. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold and up).
You do not need to do the math: paste your foreground and background colors into our Color Contrast Checker and it reports the ratio and pass/fail per level. Check your body text, your muted "secondary" text (the usual offender), link colors, and button text.
2. Missing or useless alt text
Every meaningful image needs an alt attribute describing its content or function: alt="Bar chart showing sales doubling from 2024 to 2026", not alt="chart" or alt="image123.png". Purely decorative images should have an explicitly empty alt="" so screen readers skip them. An image inside a link takes the link's purpose as its alt: alt="Back to home" rather than describing the logo's appearance.
3. Broken heading structure
Screen reader users navigate by headings the way sighted users scan visually; a jumbled hierarchy is like a scrambled table of contents. The rules: exactly one <h1> per page describing the page, levels never skip downward (an <h2> section can contain <h3>s, not jump to <h4>), and headings are chosen by structure, never because a level "looks the right size". Style with CSS, structure with heading levels.
4. Divs and spans doing a button's job
<div onclick="..."> is invisible to keyboards and screen readers. A real <button> is focusable, announces itself as a button, and activates with Enter and Space, all for free. The same goes for links (<a href> for navigation), form controls, and landmarks (<nav>, <main>, <header>, <footer>). The first rule of ARIA is to prefer native HTML elements over ARIA attributes; the second is that wrong ARIA is worse than none.
5. Keyboard traps and missing focus styles
Try using your site with only Tab, Shift+Tab, Enter, Space, and arrow keys. Two failures show up immediately on most sites. First, invisible focus: someone removed the "ugly" focus outline with outline: none and now keyboard users are navigating blind. Replace it with a styled :focus-visible outline instead of deleting it. Second, focus traps and skips: modals that Tab escapes from (focus should stay inside until dismissed), or custom dropdowns that keyboard focus passes straight through.
6. Form fields without labels
Placeholder text is not a label: it vanishes on input, has low contrast, and is inconsistently announced. Every input needs a real <label for="field-id">. Error messages must be associated with their field programmatically (via aria-describedby), not just displayed in red nearby, and never communicate by color alone: "Fix the fields marked in red" excludes colorblind and screen reader users. Say which fields, and what is wrong.
7. Link text with no meaning out of context
Screen reader users often pull up a list of all links on a page. A list reading "click here, click here, read more, read more" is useless. Link text should describe the destination: "Read the full accessibility report" instead of "Click here". This is also, not coincidentally, better for SEO.
8. Motion, autoplay, and flashing
Autoplaying video with sound, carousels that rotate while being read, and parallax animations can range from annoying to physically harmful (vestibular disorders, seizure triggers). Respect the prefers-reduced-motion media query, give carousels pause controls, and never flash content more than three times per second.
A Testing Routine That Costs Nothing
No single tool catches everything, but this four-step routine catches most issues:
Step 1: Automated scan (5 minutes)
Run Lighthouse (in Chrome DevTools, Accessibility category) or the axe DevTools extension on your key templates. Automated tools catch roughly a third of issues, including contrast failures, missing alt attributes, missing labels, and ARIA misuse. Fix everything they report; they have almost no false positives.
Step 2: Keyboard-only pass (10 minutes)
Unplug your mouse, metaphorically. Tab through each key page. Can you see where focus is at all times? Can you reach every interactive element? Operate every menu, modal, and form? Escape everything you can enter? Note every failure; each is a real blocker for someone.
Step 3: Screen reader spot-check (15 minutes)
Windows has Narrator built in and NVDA is free; macOS has VoiceOver (Cmd+F5). Turn one on, close your eyes if you can, and try to complete your site's main task, whether that is reading an article or submitting a form. The first time is humbling and more educational than any article, including this one.
Step 4: Zoom and reflow (5 minutes)
Zoom the browser to 200 percent and then 400 percent. Content must reflow without horizontal scrolling and nothing should overlap or disappear. This doubles as a responsive design check.
Run the routine on new templates before launch, and quarterly on the pages that matter. If you write readable content as well, our Readability Score tool helps with the "understandable" principle; complex text is itself an accessibility barrier, and WCAG AAA includes reading-level guidance.
Building It into Your Process
Retrofitting accessibility is expensive; building it in is nearly free. Three habits make it stick:
- Design with contrast and states from the start. Check palette contrast at design time (a palette that fails is cheaper to change before implementation), and design focus/hover/error states explicitly.
- Use semantic HTML by default. A codebase that reaches for
<button>,<nav>, and<label>naturally starts 80 percent of the way to AA. - Add automated checks to CI. Tools like axe-core or pa11y run against pull requests and stop regressions before merge.
The Takeaway
Accessibility is not an endless specialist discipline you can never finish; for most sites it is eight common failures, a free testing routine, and a set of defaults. Fix contrast, alt text, headings, semantics, keyboard support, labels, link text, and motion, and you will be more accessible than the majority of the web. Your visitors with disabilities will notice, and so will your search rankings, your legal exposure, and every user who ever tried to use your site one-handed on a bright day.