If you build websites, there is a good chance the sites you ship are harder to use than you think, and not for the reasons you would expect. Not slow, not ugly, but unusable for a real slice of your audience. People who navigate with a keyboard instead of a mouse, rely on a screen reader, zoom the page to 200 percent, or cannot distinguish low-contrast text all hit walls that never show up in a normal QA pass. Web accessibility is the practice of building sites that people can actually use. This guide explains accessibility in practical terms, introduces WCAG 2.1 AA, and walks you through how to test a page yourself, starting today, with tools you already have.
Why Web Accessibility is Important?
Start with the audience size. The WHO estimates that about 1.3 billion people, roughly 16 percent of the world’s population, live with a significant disability. In the United States, the CDC puts the figure at up to 1 in 4 adults. That includes permanent conditions like blindness or motor impairments, but also temporary and situational ones: a broken wrist, bright sunlight on a phone screen, a noisy room where captions matter. Then look at how the web actually performs. The WebAIM Million, an annual automated analysis of the top one million home pages, has found detectable WCAG failures on more than 95 percent of pages every year it has run, including its 2024 edition, with an average of roughly 50 errors per page.
The most common problems are not exotic. Year after year, they are low-contrast text, missing alternative text on images, empty links and buttons, and form fields with no labels. These are ordinary mistakes, and they are all fixable. There is a legal dimension too. In the United States, courts and the Department of Justice have repeatedly treated the Web Content Accessibility Guidelines as the practical benchmark for whether a site meets obligations under the Americans with Disabilities Act. Accessibility lawsuits against websites have become common, and most turn on the failures listed above.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C), provide the international framework for web accessibility. WCAG 2.1 is the version most organizations follow today, and WCAG 2.2 is the latest release, adding a handful of newer criteria worth adopting as best practice. WCAG is organized around 4 principles, often remembered by the acronym POUR:
- Perceivable: Content must be perceivable by users. If information relies only on images, color, or sound, some users may miss it.
- Operable: The interface must be operable. Everything that works with a mouse must also work with a keyboard, and nothing should trap the user or move too fast to use.
- Understandable: Content and controls must be predictable and clear. Labels, instructions, and error messages should make sense.
- Robust: The markup must be clean enough for assistive technologies, like screen readers, to interpret reliably.
Each guideline has testable success criteria sorted into three levels: A, AA, and AAA. Level AA is the target most people use. Most policies and legal settlements reference it, and you can achieve it without redesigning your product. When someone says a site should be “WCAG 2.1 AA compliant,” they mean this.
The Failures Developers Cause Most Often
Most accessibility issues come from markup and styling, so developers can prevent many of them.
Here are the ones that show up again and again:
- Images without alternative text: A screen reader cannot describe a picture it has no text for. Every meaningful image needs a concise alt attribute, and purely decorative images need an empty alt=”” so they are skipped.
- Low color contrast: Although light gray text on white can appear stylish, WCAG 2.1 AA sets minimum contrast ratios of 4.5:1 for regular text and 3:1 for large text.
- Controls that only work with a mouse: Custom dropdowns, sliders, and modal dialogs built without keyboard support lock out anyone who does not use a pointer.
- Form fields without labels: A visually placed placeholder is not a label. Every input needs a programmatically associated <label> so assistive tech can announce its purpose.
- Broken heading structure: Headings should follow the page hierarchy (one H1, followed by H2 and H3) rather than being chosen based on text size.
- No visible focus indicator: Keyboard users need to see where they are on the page. Removing the focus outline in CSS without replacing it is a common and serious mistake.
- Motion with no off switch: Carousels and animations that autoplay without a pause control can cause real problems for people with vestibular conditions, and they fail WCAG’s pause, stop, hide criterion.
How to Test a Page Yourself?
You do not need a lab or a budget to start. A meaningful first pass combines three layers: a keyboard test you do by hand, an automated scan, and a screen reader check.
1. The Keyboard Test
Put your mouse away and navigate the page using only the keyboard. Use Tab and Shift + Tab to move between interactive elements, Enter and Space to activate them, and the arrow keys inside menus and sliders.
As you go, ask:
- Can I reach every link, button, and form field?
- Is the focus indicator always visible, so I know where I am?
- Does the focus order follow the page’s visual order?
- Can I exit every menu and dialog, or does focus get trapped?
- Is there a skip link that lets me jump past the navigation to the main content?
This single test surfaces a large share of real-world problems, and it costs nothing.
2. The Automated Scan
Automated tools are the fastest way to catch the mechanical failures: missing alt text, contrast issues, unlabeled inputs, and invalid ARIA. Browser-based checkers like the WAVE extension, axe DevTools, and the accessibility audit built into Chrome’s Lighthouse are all good starting points, and you can run an automated accessibility scan of any page to surface issues like these in seconds.
One honest caveat: automated testing is necessary but not sufficient. Research consistently shows that automated tools catch only around 30 to 40 percent of WCAG issues, because many criteria require human judgment. A tool can tell you an image has no alt text, but it cannot tell you whether the alt text you wrote is actually meaningful. Treat the scan as your first pass, not your last word.
3. The Screen Reader Check
Turn on a screen reader and close your eyes for a minute. NVDA on Windows and VoiceOver on Mac are both free and built for this. Listen to how the page is announced. Do the headings describe the structure? Are links and buttons named clearly, or does the reader just say “link, link, link”? Are images described? You will hear problems that no visual test would reveal.
4. Quick Extra Checks
After keyboard, automated, and screen reader testing, perform a few quick checks.
- Zoom to 200 percent in the browser and confirm the layout still works and nothing is cut off.
- Check color alone. If the only way to tell a required field or an error is that it turned red, users who cannot perceive that color will miss it. Add text or an icon.
A Starter WCAG 2.1 AA Checklist
Use this as a first pass on any page:
- Every meaningful image has descriptive alt text; decorative images have empty alt text
- Text contrast meets at least a 4.5:1 ratio, or 3:1 for large text.
- The entire page is operable by keyboard, with no traps
- The focus indicator is always visible
- Every form field has an associated label, and errors are described in text
- Headings are structured in logical order
- The page has a valid language attribute (<html lang=”en”>)
- Moving or autoplaying content can be paused
- Information is never conveyed by color alone
Where to Go From Here?
Accessibility is not a one-time fix. It is a habit, built into how you write markup, choose colors, and review pull requests. The good news is that the same practices that make a site accessible also make it more usable for everyone, cleaner in structure, better for SEO, and more resilient across devices. Start with the keyboard test on your own most important page today.
Run an automated scan to catch the mechanical issues, then sit with a screen reader for five minutes to hear what your users hear. You will find issues; almost everyone does. Fixing each one makes your site more accessible to people who may have previously struggled to use it. WCAG 2.1 AA is the practical baseline, and WCAG 2.2 is where to aim next. Neither is as hard as it sounds once you start testing.
Recommended Articles
We hope this beginner-friendly guide to WCAG 2.1 AA helps you build and test more accessible websites. Check out these recommended articles for more insights and practical strategies to improve web accessibility and create better digital experiences.
