Accessibility Basics

What accessibility is, and who it is for

Web accessibility (often shortened to a11y: a, eleven letters, y) is the practice of building websites that people with disabilities can use as fully as anyone else. That includes people who are blind or have low vision, who are deaf or hard of hearing, who cannot use a mouse, who have cognitive or learning disabilities, or who have epilepsy triggered by flashing content. The World Health Organization estimates that about one in six people worldwide lives with a significant disability.

Accessibility also helps people whose limitation is temporary or situational: a broken arm, a phone in bright sunlight, a noisy train without headphones, an older customer whose eyesight is slowly getting worse. Captions, good contrast and clear forms make a site better for everyone.

The state of the web is not good. The WebAIM Million study, which tests the home pages of the top one million websites each year, found detectable WCAG failures on 95.9% of them in 2026, with an average of 56 errors per page. The six most common problems were all things this topic covers: low-contrast text (83.9% of pages), missing alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%) and a missing document language (13.5%).

How people use the web

People with disabilities use the same browsers as everyone else, often together with assistive technology:

• A screen reader is software that reads the page aloud, or sends it to a braille display, and lets the user navigate it with the keyboard or touch gestures. Blind users rely on it. Common ones are NVDA (free) and JAWS on Windows, VoiceOver built into macOS and iOS, and TalkBack on Android.
• Keyboard only: people who cannot use a mouse move through a page with Tab, Shift+Tab, Enter, Space and the arrow keys. Switch devices and mouth sticks act like a keyboard.
• Zoom and magnifiers: people with low vision enlarge the page to 200% or more, or magnify a small part of the screen at a time.
• Voice control: users speak the visible name of a link or button ("click Save reading").

A screen reader does not look at the pixels. The browser builds an accessibility tree from the DOM: for every meaningful element it records a role (button, link, heading, checkbox), a name ("Save reading") and states (checked, expanded, disabled). The screen reader reads that tree. If your HTML says <div> where it means <button>, the tree says "text", whatever the element looks like.

WCAG: the standard

WCAG, the Web Content Accessibility Guidelines, is the W3C standard that defines what an accessible web page is, as a list of testable success criteria. The current version is WCAG 2.2, first published in October 2023 and updated in December 2024; in October 2025 it was also published as the international standard ISO/IEC 40500:2025. Its criteria are grouped under four principles, easy to remember as POUR:

• Perceivable: users can perceive the content, whatever sense they use. Text alternatives for images, captions for video, enough contrast.
• Operable: users can operate every control. Keyboard access, enough time, no flashing, visible focus, big enough targets.
• Understandable: content and behavior are predictable. Page language, clear labels and error messages, consistent navigation.
• Robust: content works with current and future browsers and assistive technology. Correct names, roles and states.

Each success criterion has a level: A (the minimum), AA (the level laws and policies require) and AAA (extra, not required for whole sites). Conforming to AA means meeting every A and AA criterion. WCAG 2.2 has 86 success criteria: the 78 of WCAG 2.1 plus nine new ones, minus 4.1.1 Parsing, which was removed as obsolete. Among the new ones are 2.4.11 Focus Not Obscured (the focused element must not be entirely hidden, for example behind a sticky header), 2.5.8 Target Size (Minimum) (click targets at least 24 × 24 CSS pixels, with exceptions) and 3.3.8 Accessible Authentication (no memory or puzzle tests to log in, unless an alternative exists).

A completely new WCAG 3 is in development, but as of 2026 it is a Working Draft that W3C expects to take several more years. The W3C advice is to meet WCAG 2.2 now.

The law

In much of the world, accessibility is a legal duty, but the laws differ in whom they cover and which technical standard they name. In the EU the central law for consumer products and services is the European Accessibility Act (EAA); the United States and the United Kingdom have their own laws. Where a law or regulation names a technical standard, it is WCAG at level AA, directly or through the European standard EN 301 549, but not always the latest version.

Semantic HTML first

Native HTML elements come with their accessibility built in. A <button> is focusable with Tab, activates with Enter and Space, and is announced as a button. A <div> styled to look like a button has none of that: it is skipped by the Tab key and announced as plain text, unless you add a role, a tabindex and keyboard handling yourself. Click into the preview below and press Tab: only the real button receives focus.

<div class="btn">Save reading (div)</div>
<button type="button" class="btn">Save reading (button)</button>

.btn {
  display: inline-block;
  font: 1rem system-ui, sans-serif;
  padding: 0.5rem 1rem;
  border: 2px solid #1d4ed8;
  background: #1d4ed8;
  color: #fff;
  cursor: pointer;
}
.btn:focus-visible {
  outline: 3px solid #1a1a1a;
  outline-offset: 2px;
}

The same goes for the rest of the semantic elements: headings in order (<h1>, then <h2> and so on, without skipping levels for their size), real lists, real tables with header cells, and labels on form fields. Screen reader users rely heavily on headings: jumping from heading to heading is a common first way to scan an unfamiliar page. Also set the page language with <html lang="en"> (WCAG 3.1.1), so the screen reader uses the right pronunciation; see the lang attribute.

Landmarks

A landmark is a region of the page with a role that assistive technology lists and lets users jump to, such as the navigation or the main content. You get landmarks for free from the semantic elements:

Accessible names and text alternatives

The accessible name of an element is the short text that assistive technology uses to identify it: what a screen reader says for a link or button, and what a voice control user speaks to activate it. The browser computes it from, in order of priority: aria-labelledby (text of other elements), aria-label, then the native source: the <label> of a form field, the alt of an image, the <caption> of a table, or the text content of a link or button.

The "empty links" and "empty buttons" in the WebAIM figures are elements whose name came out empty, nearly always icon-only controls. Two ways to fix them:

<button type="button" class="icon">
  <svg aria-hidden="true" width="20" height="20" viewBox="0 0 20 20">
    <path d="M3 10h14M10 3v14" stroke="currentColor" stroke-width="2"></path>
  </svg>
  <span class="visually-hidden">Add a meter</span>
</button>
<button type="button" class="icon" aria-label="Close message">×</button>

.icon {
  min-width: 44px;
  min-height: 44px;
  font-size: 1.25rem;
}
/* Hidden on screen, still read by screen readers */
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

The first button has hidden text inside it, so its name is "Add a meter"; the icon is hidden from the accessibility tree with aria-hidden="true" because it adds nothing. The second button gets its name from aria-label; without it, a screen reader would announce "times" or "multiplication sign". The buttons are 44 pixels square, comfortably above the 24-pixel minimum of WCAG 2.5.8.

Images need a text alternative too (WCAG 1.1.1): an alt that says what the image conveys, or alt="" for a purely decorative image so that screen readers skip it. How to write good alt text is explained under images. Video needs captions, and audio a transcript.

Keyboard access and focus

Keyboard focus is the state of the one element on the page that currently receives keyboard input. Tab moves focus to the next focusable element (links, buttons, form fields), Shift+Tab to the previous one, and Enter or Space activates it. WCAG requires that everything works this way (2.1.1 Keyboard, level A) and that the focused element is visibly marked (2.4.7 Focus Visible, level AA).

• Tab order follows the HTML order. If CSS places things in a different visual order, focus jumps around. Fix the source order instead of fighting it.
• tabindex="0" makes a non-focusable element focusable in source order (needed for, say, a scrollable region). tabindex="-1" makes it focusable from script only. Never use positive values like tabindex="3": they override the natural order and almost always make it worse.
• Never remove the focus outline without putting something at least as visible in its place. outline: none on :focus leaves keyboard users lost on the page. The :focus-visible pseudo-class (supported in all major browsers since 2022) shows a focus style when the user navigates by keyboard, and not after every mouse click.
• A skip link as the first element lets keyboard users jump past a long menu straight to the main content.

<a class="skip" href="#content">Skip to main content</a>
<header>
  <nav aria-label="Main">
    <a href="#">Outage map</a>
    <a href="#">Meter readings</a>
    <a href="#">My account</a>
  </nav>
</header>
<main id="content">
  <h1>Report an outage</h1>
  <p>Tell us where the power is out.</p>
</main>

body {
  font-family: system-ui, sans-serif;
}
nav a {
  margin-right: 1rem;
  color: #1d4ed8;
}
a:focus-visible {
  outline: 3px solid #1a1a1a;
  outline-offset: 3px;
}
.skip {
  position: absolute;
  left: -9999px;
}
.skip:focus {
  left: 1rem;
  top: 1rem;
  padding: 0.5rem 1rem;
  background: #fff;
  color: #1a1a1a;
}

Click into the frame (on the empty area) and press Tab: the skip link appears first, then focus moves through the menu with a thick dark outline. A sticky header or cookie banner that completely covers the focused element breaks WCAG 2.4.11; leave room with scroll-padding-top or keep overlays out of the way.

Color and contrast

The contrast ratio is a number from 1:1 (no difference, such as white on white) to 21:1 (black on white) that expresses how much the relative luminance (brightness) of two colors differs. WCAG sets minimums at level AA:

• 4.5:1 for normal text (1.4.3 Contrast (Minimum)).
• 3:1 for large text: at least 24 CSS pixels, or about 18.66 pixels in bold.
• 3:1 for the parts of controls and graphics you need to see, such as the border of a text field, a focus indicator or a line in a chart (1.4.11 Non-text Contrast).

<p class="fails">#aaaaaa on white: 2.3:1, fails for all text</p>
<p class="aa">#767676 on white: 4.5:1, passes AA for normal text</p>
<p class="aaa">#595959 on white: 7:1, passes AAA as well</p>

body {
  font-family: system-ui, sans-serif;
  background: #fff;
}
.fails { color: #aaaaaa; }
.aa    { color: #767676; }
.aaa   { color: #595959; }

The first line is shown on purpose as a failure: light gray text like this is the single most common accessibility error on the web. You do not compute ratios by hand. The browser's developer tools show the ratio when you inspect a text color, and online contrast checkers do the same.

Contrast is half the story. WCAG 1.4.1 (Use of Color, level A) says color must not be the only way information is conveyed: about one in twelve men has some form of color vision deficiency. Underline links in running text, mark errors with a text message and not only a red border, and give chart lines different patterns or direct labels.

ARIA: when HTML is not enough

ARIA (WAI-ARIA, Accessible Rich Internet Applications) is a W3C set of HTML attributes that add or change what the accessibility tree says about an element:

• roles: what the element is, role="tab", role="dialog", role="alert";
• properties: names and relations, aria-label, aria-labelledby, aria-describedby, aria-controls;
• states: what it is doing now, aria-expanded="true", aria-checked, aria-current="page".

ARIA changes only what assistive technology is told. It adds no behavior: role="button" on a <div> makes a screen reader say "button", but the div still does not react to the keyboard. That is why the W3C's guidance on using ARIA starts with what it calls the first rule of ARIA:

"If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

For example, a question that expands to show its answer needs no ARIA and no JavaScript at all: <details> and <summary> are keyboard-operable and announce their expanded or collapsed state by themselves.

<details>
  <summary>Why is my bill higher this month?</summary>
  <p>Your monthly advance payment changed on 1 September,
     after your annual statement.</p>
</details>

body {
  font-family: system-ui, sans-serif;
}
summary {
  cursor: pointer;
  padding: 0.25rem 0;
}

ARIA is the right tool where HTML has no element for the job: naming an icon button or a second <nav>, linking a hint to a field with aria-describedby, reporting the state of a custom tab interface, or announcing a status message such as "Reading saved" with a live region (role="status"). The WAI-ARIA Authoring Practices Guide has tested patterns for such widgets. Its warning, often quoted as "no ARIA is better than bad ARIA", is borne out by the data: in the WebAIM Million 2026, home pages that used ARIA had more detected errors on average (59.1) than pages without it (42). ARIA does not cause errors by itself, but it is often added to complex pages by people who are not sure what it does.

Testing and further study

Accessibility testing is a mix of tools and people:

1. Automated checkers such as Lighthouse (built into Chrome's developer tools), axe DevTools and WebAIM's WAVE find missing alt text, missing labels, low contrast and invalid ARIA in seconds. They catch only part of the problems: no tool can judge whether alt text is meaningful or a focus order makes sense.
2. The keyboard test: put the mouse away and use the page with Tab, Shift+Tab, Enter, Space and the arrow keys. Can you reach and operate everything? Can you always see where you are?
3. The zoom test: zoom to 200% and 400%. Text must stay readable at 200% (WCAG 1.4.4) and the content must reflow into one column without horizontal scrolling at a width of 320 CSS pixels (1.4.10 Reflow).
4. A screen reader: try NVDA or VoiceOver on your own pages. Listen to the headings list and the links list.
5. Real users: testing with people with disabilities finds what checklists miss.

For further study after this page: the W3C Web Accessibility Initiative (WAI) publishes free tutorials and the "How to Meet WCAG" quick reference. For a professional qualification, the International Association of Accessibility Professionals (IAAP) offers the CPACC (Certified Professional in Accessibility Core Competencies) and the more technical WAS (Web Accessibility Specialist).