What is web accessibility (a11y)? WCAG principles and practical techniques

Web accessibility, often shortened to a11y, means designing and building sites so that as many people as possible can use them, including people with limited vision, hearing, movement, or cognitive ability. The name is a numeronym: "a", then 11 characters, then "y". Accessibility is not a checklist you bolt on at the end — it is a design and development practice. When done well it also benefits people with situational disabilities, such as someone reading in bright sunlight or using the phone one-handed.

Why accessibility matters

The web was designed to work for all people, whatever their hardware, software, language, location, or ability. For many people with disabilities, technology is not a convenience but the only way to access information and services. Accessibility removes the barriers that would otherwise lock them out.

It is also a legal and business concern in many regions: rules such as the European Accessibility Act and the US Americans with Disabilities Act increasingly require accessible sites, and most of those rules point to the Web Content Accessibility Guidelines (WCAG) as the measuring standard.

The four WCAG principles: POUR

WCAG is organized around four principles. Every accessibility requirement falls under one of them, and the acronym is POUR:

• Perceivable — users can perceive the information. Content must be presentable in ways they can sense (not only through sight or hearing).
• Operable — users can operate the interface. Navigation and controls must work for a keyboard, a mouse, a touch screen, or a switch device.
• Understandable — users can understand the information and how the interface behaves. Content is readable and predictable.
• Robust — content works with current and future user agents, including assistive technologies such as screen readers.

Under each principle sit guidelines, and under each guideline sit testable success criteria at three conformance levels: A (basic), AA (the common legal target), and AAA (the highest). Many sites aim for WCAG AA conformance. WCAG versions are backward compatible: content that meets WCAG 2.2 also meets WCAG 2.1 and 2.0.

Start with semantic HTML

A large share of accessibility is free if you use the right HTML element for the right job. Correct semantic HTML gives screen readers and browser navigation a page's structure for free: nav, main, article, aside, header, footer, and section define landmarks; h1 through h6 define a heading hierarchy; a gives you a real link; button gives you a focusable, activatable control.

<header>
  <nav aria-label="Main">…</nav>
</header>
<main>
  <h1>Page title</h1>
  <p>Content…</p>
</main>

Problems appear when developers replace these with styled divs. A div carries no semantic meaning, so a screen reader user hears nothing useful about what it is. Prefer native elements, add a proper heading hierarchy (one h1 per page, then h2, h3 in order), and reserve ARIA for cases where there is no native equivalent.

Make everything keyboard accessible

Keyboard accessibility is part of the minimum requirements. People who cannot use a mouse — because they have a motor impairment, use speech recognition, or simply prefer the keyboard — rely on Tab, Shift+Tab, Enter, and arrow keys to move through a page. The Tab key order must follow a logical reading order, and every interactive element must be reachable and operable with the keyboard.

Checklist:

• Every link and control is focusable and can be triggered with the keyboard.
• A visible focus indicator shows where you are (do not replace it with outline: none).
• No interactive element is reachable only by hover or drag.
• Focus moves sensibly when content changes, for example after loading new results in a search box.

Write good alt text and captions

Images need text alternatives so their meaning is available to screen readers and to users with images disabled. The rule is: if the image conveys meaning, write a short alt text describing that meaning; if the image is purely decorative, use an empty alt="" so it is skipped.

<img src="architecture-diagram.png" alt="How the request flows from browser to database">
<img src="spacer.png" alt="">

For images that include text, the alt text should repeat that text. Videos need captions for deaf and hard-of-hearing users, and audio-only content needs a text transcript. Provide text for anything you cannot convey through images alone.

Ensure sufficient color contrast

Color should never be the only way information is conveyed. Links that differ from body text only by color, for example, are invisible to color-blind users — differentiate them with an underline or another cue as well.

Text also needs sufficient contrast ratio against its background. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text (18pt and larger, or 14pt bold and larger). Non-text elements such as the borders of form inputs and UI component outlines need at least 3:1 against adjacent colors.

Use ARIA only when needed

ARIA (Accessible Rich Internet Applications) adds semantics that HTML does not provide for complex widgets and dynamic content — roles such as role="dialog" or role="tablist", and properties such as aria-label or aria-live for announcing dynamic updates. But ARIA is a supplement, not a substitute. The web.dev guidance is to prefer correct HTML semantics first; use ARIA for the cases native HTML cannot express, and always test what you add, because misused ARIA can be worse than none at all.

Test, both automated and manual

Automated tools (such as axe-core, Lighthouse's accessibility audit, and W3C's validator) catch a meaningful share of issues — missing alt text, low contrast, unlabeled form fields. They do not catch everything, because much of accessibility is about meaning and behavior, which only a human can judge.

A reliable manual pass:

1. Tab through the whole page with the keyboard only — is everything reachable and understandable?
2. Run a screen reader over the main flows — does it announce headings, links, and form fields correctly?
3. Check content under a browser zoom of 200% and on a narrow mobile viewport.
4. Review contrast for the color palette.

Accessibility is continuous: every new component and every refactor is a chance to keep the site usable for everyone.

FAQ

What does a11y mean?

A11y is a numeronym for "accessibility": the letter "a", 11 letters, then "y". In web development it refers to building sites that are usable by as many people as possible, including people with vision, hearing, movement, or cognitive disabilities.

What are the four principles of WCAG?

They are perceivable, operable, understandable, and robust (POUR). Perceivable means users can sense the content; operable means they can use the controls; understandable means the content and behavior are clear; robust means content works with current and future assistive technologies.

Is WCAG AA or AAA the target?

Most organizations and laws target WCAG AA, which is a middle conformance level that addresses the most common accessibility barriers. AAA is the highest level but is not always achievable or appropriate for every piece of content.

Does correct HTML matter for accessibility?

Yes, a great deal. Semantic elements such as nav, main, h1–h6, a, and button give assistive technologies a page's structure for free, and native controls are keyboard accessible by default. Styled divs carry no such meaning, so they require extra work and ARIA to be accessible.