Web Accessibility Basics

Web Accessibility Isn't a Checklist, It's a Decision System

One in four adults in the United States lives with some form of disability, according to the CDC, and the World Health Organization estimates that roughly 1.3 billion people worldwide experience significant disability. Yet when we measured the top one million home pages with automated tools like WAVE and axe, the median site still fails dozens of WCAG checkpoints. The gap is not a technology problem. The HTML, CSS, and JavaScript needed to build accessible interfaces have existed for years. The gap is a process problem: most teams treat accessibility as a late-stage audit instead of a requirement that shapes every decision from the first wireframe to the final code review.

This article is a practical on-ramp for developers, designers, and product people who want to stop bolting on accessibility and start baking it in. You will learn which standards matter, what the audit tools actually measure and miss, how much accessible work really costs, and the specific habits that keep a site from regressing. If you are building modern apps, the same foundations apply whether you start from scratch or work inside a web framework, and the performance discipline that keeps pages fast overlaps heavily with the work of shipping accessible experiences.

What WCAG Compliance Actually Requires

The Web Content Accessibility Guidelines (WCAG) are organized into four principles: Perceivable, Operable, Understandable, and Robust. Within those sit three conformance levels — A, AA, and AAA — and for most organizations AA is the realistic and legally relevant target. Laws like the Americans with Disabilities Act and the European Accessibility Act tend to map to WCAG 2.1 or 2.2 AA, so that is the bar your compliance team will quote back to you. The quick mental model is elegant: if a user cannot perceive the content because it is only conveyed by color, if they cannot operate the interface because it requires a mouse, if they cannot understand the page because error text is vague, or if assistive tools cannot parse the markup robustly, you have an accessibility failure compounded across principles.

Do not memorize every checkpoint. Memorize the patterns that cause the most failures in real audits: missing alt text, insufficient color contrast, keyboard traps, missing labels, and headings that do not describe page structure. Fixing those five accounts for the majority of automated errors your first scan will report. Every successive redesign should re-run the same five checks before it ships.

Where Automated Tools Fall Short

Tools like axe, WAVE, Lighthouse, and Siteimprove are indispensable, and they are also only a partial picture. They catch deterministic failures — an image without alt text, a form field without a label, a contrast ratio below 4.5:1. They cannot judge whether a focus order actually makes sense to a screen reader user, whether a carousel is understandable, or whether alt text you wrote is good rather than merely present. That is why the industry distinguishes between automated testing and human-assisted testing, and why the WebAIM Million reports that automated scans alone always underestimate the real accessibility debt.

Build a testing pyramid: run axe-core in your CI on every pull request, spot-check with a free screen reader like NVDA on Windows or VoiceOver on Mac once per sprint, and run a moderated session with real users at least once a quarter. The automated layer catches regressions cheaply and constantly. The human layer catches the judgment calls that a robot will never make. Skipping the human layer because automated scans pass is how teams ship technically valid but practically unusable experiences.

What Accessible Redesigns Really Cost

There is a persistent myth that accessibility is expensive. The truth depends almost entirely on when you start. Retrofitting an existing site is expensive because you are paying to undo decisions. Building accessibly from the start is cheap because you are paying once for choices that cost little more at build time. The clearest framing comes from the UK's Business Disability Forum, which long ago quantified that fixing an accessibility issue during design costs a fraction of fixing the same issue after launch. When accessibility is a requirement, a button can be keyboard navigable for the same effort as a mouse-only button; an image can have alt text for the same effort as an image without it.

Here is a realistic cost model for a small-to-medium marketing site. Automated axe integration costs engineering time measured in hours, not days. A WAVE manual pass on ten core templates takes a few hours per sprint. One moderated user session per quarter runs a few hundred dollars through a service like UserTesting or can be done in-house. Compare that to a retroactive legal remediation, which for a mid-size company routinely runs into six figures and months of churn. The economics are not close; accessibility is the cheaper option by a large margin, and it is also the option that keeps you out of court.

The Keyboard-Only Audit You Can Run Today

You do not need special software to find the most common accessibility failures. A keyboard-only pass catches more real problems than many automated scans. Here is the exact script to run on any page you have authored. Unplug the mouse, place focus at the top, and press Tab repeatedly. Watch three things: can you reach every interactive element, does the focus ring stay visible, and does the order match the visual layout. Then use Enter and the arrow keys on a select and a checkbox to confirm full keyboard support. Finally, click into the footer using a screen reader or the browser's accessibility tree to confirm the reading order makes sense.

Most teams run this once and find at least one modal that cannot be escaped, a dropdown that needs a hover to open, or a focus ring that was removed with outline: none. Those are exactly the issues that generate user complaints and legal letters. Schedule a keyboard-only pass on every pull request that touches navigation, forms, or modals, and you will eliminate the vast majority of your addressable failures before they ever ship. It is the highest-return accessibility habit you can adopt.

Keeping Accessibility Working Design and Performance Together

Accessibility cannot live in a silo if you want it to survive contact with shipping. Tie it to the same systems that keep your site fast and maintainable. Semantic HTML helps accessibility and performance simultaneously because native elements have built-in keyboard behavior, focus management, and roles that you otherwise rebuild by hand. The lang attribute, logical heading order, and proper form labels are free wins that also make your markup easier for the rest of your team to maintain. This is why accessibility pairs naturally with the discipline you pick up in a web development course and why it should be a standing agenda item in the same reviews where you discuss web performance optimization.

Build a lightweight "accessibility done" definition that every pull request must meet: automated checks green, a keyboard pass completed, alt text present and meaningful, and contrast verified on any new color. Make that definition of done public to the team so reviewers enforce it without being the accessibility police. Within a few sprints the checks become automatic, regressions drop, and the tooling costs almost nothing because it is part of how you already build. Accessibility stops being a scary project and becomes simply the standard way you ship web work — the same mindset you build when you from a deliberate foundation.

For more, check out: .

For more, check out: and mlops basics.

Frequently Asked Questions

Do I need to comply with WCAG 2.2 AA or is WCAG 2.1 enough?

Target WCAG 2.2 AA because it is the current recommended standard and the WCAG 2.2 additions (like target size and focus appearance) are increasingly cited by regulators. Most automated tools now check 2.2 by default. If you have legacy pages, prioritizing the 2.2 focus-appearance and target-size guidelines is a low-effort way to reach the new bar.

What is the fastest way to find accessibility bugs on my own site?

Run the axe DevTools extension on your most important pages, then do a keyboard-only pass Tab through every element. The extension catches deterministic errors and the keyboard pass catches interaction problems that no tool detects. Together they take a few hours and surface the majority of your real issues.

Can I fix accessibility with just CSS and JavaScript overlays?

No. Automated overlay widgets that claim instant WCAG compliance typically address symptoms and can even interfere with assistive technology by injecting duplicate UI. Fixing the underlying HTML, contrast, and focus behavior is the durable approach, and it is the same discipline you reinforce in any web development workflow. Overlays also carry legal risk because they promise compliance while rarely delivering it.

Is accessibility only about blind users and screen readers?

No. It covers low vision, color blindness, motor impairments, hearing loss, cognitive differences, and temporary situations like a broken arm or bright sunlight. Designing for robustness helps everyone — captions help in noisy rooms, larger targets help under gloves or on touchscreens. Accessibility is really good UX for a wider range of humans.