WCAG 2.2 in Practice: The Pre-Launch Accessibility Checklist I Use in 2026

Accessibility
Accessibility audit checklist interface showing WCAG 2.2 criteria being verified on a static website

WCAG 2.2 became a W3C Recommendation in October 2023, and in 2026 it is the accessibility standard that auditors, legal teams, and automated testing tools measure against. The specification contains 86 success criteria across three conformance levels—A, AA, and AAA. Most websites aim for AA conformance, which covers 55 criteria. Reading through all of them before launching a five-page brochure site is impractical, and most of the criteria address situations that do not arise on simple static sites: time-based media, live captions, complex web applications.

This checklist strips WCAG 2.2 AA down to what actually matters when you are building and launching a static website. Not a web application. Not a media platform. A site with pages, text, images, navigation, maybe a contact form, and no server-side logic. These are the criteria I check before every launch, in the order I check them.

The New Criteria in WCAG 2.2 That Affect Static Sites

WCAG 2.2 added nine new success criteria beyond 2.1. Most target complex interactions in web applications, but four are relevant to static sites:

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a keyboard user tabs to an interactive element, at least part of that element must be visible. Sticky headers and fixed navigation bars are the main culprits: a user tabs to a link near the top of the content area, and the fixed header covers it completely. The user has focus on an element they cannot see.

What to check: Tab through every page with your fixed header visible. If focus moves behind the header, you need scroll-padding-top on the <html> element set to at least the header’s height:

html {
  scroll-padding-top: 80px; /* match your header height */
}

This ensures the browser scrolls enough to keep the focused element visible below the header.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

The stricter version requires the focused element to be fully visible, not just partially. While AAA is not typically required, it is easy to achieve with the same scroll-padding-top fix. Set it a few pixels larger than strictly necessary.

2.5.7 Dragging Movements — Level AA

Any functionality that uses dragging must have a single-pointer alternative. On a static site, this typically means image carousels with drag-to-scroll behaviour or sortable lists. If your site uses a drag-based component, ensure it also works with click or tap: next/previous buttons for carousels, up/down buttons for sortable items.

Most static sites do not have drag interactions. If yours does not, this criterion is automatically met.

2.5.8 Target Size (Minimum) — Level AA

Interactive targets (links, buttons, form controls) must be at least 24 × 24 CSS pixels, or the spacing between adjacent targets must compensate. This one catches navigation menus with tightly packed links, footer link lists, and small icon buttons.

What to check: Inspect your navigation links, footer links, and any icon-only buttons. Ensure either the target itself is 24px in both dimensions, or there is at least 24px of space between adjacent targets measured from the edge of one to the edge of the next.

nav a {
  display: inline-block;
  min-height: 44px;    /* generous — exceeds minimum */
  padding: 0.5rem 1rem;
}

The Pre-Launch Checklist

1. Page Structure and Semantics

Heading hierarchy. Every page needs exactly one <h1>. Subsequent headings must not skip levels—do not jump from <h1> to <h3>. Screen readers use heading hierarchy to build a page outline that users navigate.

Landmark regions. Use <header>, <nav>, <main>, and <footer> elements. Screen readers let users jump directly to these regions. If you have a sidebar, use <aside>. If you have multiple <nav> elements, give each an aria-label to distinguish them:

<nav aria-label="Main navigation">...</nav>
<nav aria-label="Footer links">...</nav>

Language attribute. The <html> element must have a lang attribute matching the page content:

<html lang="en">

Screen readers use this to select the correct pronunciation engine. A French page with lang="en" sounds wrong to everyone.

2. Keyboard Navigation

Tab order. Tab through the entire page. Every interactive element—links, buttons, form fields—must receive focus in a logical order that matches the visual layout. If the tab order jumps around, your HTML source order does not match your visual layout. Fix the HTML, not the tab order.

Focus visibility. Every focused element must have a visible indicator. Browser defaults work, but they are often subtle. A custom focus style is better:

:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 2px;
}

The :focus-visible pseudo-class applies only to keyboard-initiated focus, not mouse clicks. This gives keyboard users a clear indicator without adding outlines to every clicked button.

No keyboard traps. A user must be able to navigate into and out of every component using the keyboard. Modal dialogs are the classic trap: if focus enters a modal and the Escape key does not close it, the user is stuck. Similarly, dropdown menus must close on Escape and return focus to the trigger.

Skip link. The first focusable element on every page should be a “Skip to main content” link that jumps past the navigation to the <main> element:

<a href="#main-content" class="skip-link">Skip to main content</a>
<!-- header and navigation here -->
<main id="main-content">

.skip-link {
  position: absolute;
  left: -10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

.skip-link:focus {
  position: static;
  width: auto;
  height: auto;
  padding: 0.5rem 1rem;
  background: #1a1a2e;
  color: #fff;
}

The link is visually hidden until a keyboard user tabs to it. Then it appears, and pressing Enter skips past the entire navigation.

3. Images and Media

Alt text for every informational image. If an image conveys information, it needs descriptive alt text:

<img src="/images/chart.png" alt="Bar chart showing 40% increase in page speed after image optimisation">

Empty alt for decorative images. If an image is purely visual (a decorative border, a background pattern), use an empty alt attribute so screen readers skip it:

<img src="/images/divider.svg" alt="">

Omitting alt entirely is different from alt=""—an omitted alt causes screen readers to announce the file name, which is worse than nothing.

Complex images. Charts, infographics, and diagrams need either detailed alt text or a separate text description. If the alt text would exceed a sentence, use aria-describedby to link to a longer description:

<figure>
  <img src="/images/architecture.svg" alt="System architecture diagram" aria-describedby="arch-desc">
  <figcaption id="arch-desc">
    The system consists of three layers: a static HTML frontend served from a CDN,
    a serverless function layer handling form submissions, and an email delivery service.
  </figcaption>
</figure>

4. Colour and Contrast

Text contrast. Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18px bold or 24px regular and above) needs 3:1. Do not eyeball this—use a tool.

Non-text contrast. UI components (form field borders, button outlines, icon-only controls) need 3:1 contrast against their background. A light grey input border on a white background often fails.

Colour alone. Do not use colour as the only way to convey information. A form that marks required fields with red text but no other indicator fails. Add an asterisk, the word “required,” or both.

5. Forms

If your site has a contact form, every field needs these:

Visible labels. Every input must have a <label> element associated via the for attribute:

<label for="name">Full Name</label>
<input type="text" id="name" name="name" required>

Placeholder text is not a label. It disappears when the user starts typing and has insufficient contrast in most browsers.

Error identification. When a form submission fails validation, errors must be described in text—not just a red border. Identify which field failed and what the user needs to fix:

<label for="email">Email Address</label>
<input type="email" id="email" name="email" required aria-describedby="email-error" aria-invalid="true">
<span id="email-error" class="error-message">Please enter a valid email address.</span>

The aria-invalid="true" attribute tells screen readers the field contains an error. The aria-describedby links to the error message so the user hears it when the field receives focus.

Autocomplete attributes. For common fields (name, email, phone, address), add the appropriate autocomplete attribute. This helps browsers and password managers fill fields correctly, which is both a usability and accessibility benefit:

<input type="email" id="email" name="email" autocomplete="email">
<input type="tel" id="phone" name="phone" autocomplete="tel">

Descriptive link text. “Click here” and “read more” are meaningless out of context. Screen reader users often navigate by listing all links on a page—each link must make sense on its own:

<!-- Bad -->
<a href="/pricing/">Click here</a>

<!-- Good -->
<a href="/pricing/">View pricing plans</a>

Consistent navigation. The same navigation elements must appear in the same order on every page. If your header nav lists “Home, Features, Templates, Contact” on the homepage, it must appear in that order on every other page.

Link purpose in context. If multiple links lead to different places but have similar text, the surrounding context must distinguish them. In a list of blog posts, “Read more” links are acceptable if each is within a <article> or heading that provides context.

7. Content and Readability

Resize to 200%. Zoom the browser to 200%. All content must remain readable without horizontal scrolling on a 1280-pixel-wide viewport. This tests both your responsive layout and your text sizing. If content overflows or overlaps at 200%, your layout has a reflow problem.

Text spacing override. WCAG 2.1 added a requirement (1.4.12) that content must remain readable when users override text spacing: line height to 1.5×, paragraph spacing to 2×, letter spacing to 0.12em, word spacing to 0.16em. Do not set line-height, letter-spacing, or word-spacing with !important in your CSS—this prevents user overrides.

Motion and animation. If your site has animations, respect prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Users who enable reduced motion in their OS settings need this respected. It is a simple media query with enormous impact for people with vestibular disorders.

How DFM2HTML Supports Accessibility

DFM2HTML generates HTML with proper semantic structure by default—headings, lists, landmark elements, and associated form labels. The editor’s output does not rely on <div> soup or presentational markup that screen readers cannot parse. The features page details the semantic output patterns.

When you build a site with DFM2HTML and download it for publishing, the generated HTML includes:

  • Proper <header>, <nav>, <main>, and <footer> landmarks
  • Associated <label> elements for form fields
  • alt attributes on images (which you fill in during editing)
  • Logical heading hierarchy

This baseline gets you past the structural accessibility requirements. The checklist items above—colour contrast, keyboard testing, skip links, error messages, aria attributes on interactive components—are additions you make on top of that foundation.

Testing Tools

Automated tools catch roughly 30-40% of accessibility issues. The rest require manual testing. Use both.

Automated: axe DevTools

The axe browser extension (available for Chrome, Edge, and Firefox) scans the current page and reports WCAG violations with specific element references and fix suggestions. It catches missing alt text, insufficient contrast, missing form labels, duplicate IDs, and landmark issues. Run it on every page before launch.

Automated: Lighthouse Accessibility Audit

Built into Chrome DevTools (Lighthouse tab), the accessibility audit uses axe-core under the hood and integrates with your Core Web Vitals testing. Run it alongside your performance audit. A score of 100 does not mean your site is accessible—it means the automated checks pass.

Automated: WAVE

The WAVE extension (wave.webaim.org) provides a visual overlay showing accessibility issues in context on the page. It is particularly good at revealing structural problems—missing headings, orphaned form fields, contrast issues—because it shows them where they occur rather than in a separate panel.

Manual: Keyboard Testing

Unplug your mouse (or disable your trackpad) and navigate your entire site with the keyboard. Tab through every page. Open and close every interactive element. Submit every form. If anything is unreachable, unfocusable, or traps your keyboard, fix it. No automated tool catches all keyboard issues—this manual pass is non-negotiable.

Manual: Screen Reader Testing

If you have never used a screen reader, start with NVDA (free, Windows) or VoiceOver (built into macOS and iOS). Navigate your site with the screen reader active. Listen to how it announces your headings, links, images, and forms. You will immediately hear problems that no visual inspection reveals: unlabelled buttons, images with file names instead of descriptions, form fields that do not announce their purpose.

You do not need to become a screen reader expert. Navigate the homepage, a content page, and the contact form. If the experience is comprehensible—if you can understand the page structure and complete the form—the major issues are handled.

The Condensed Checklist

Print this, check each item, fix what fails:

Structure:

  • One <h1> per page, no skipped heading levels
  • <header>, <nav>, <main>, <footer> landmarks present
  • lang attribute on <html>

Keyboard:

  • All interactive elements focusable via Tab
  • Logical tab order matching visual layout
  • Visible focus indicator on every focusable element
  • No keyboard traps
  • Skip link present and functional
  • Focus not obscured by fixed headers (WCAG 2.2)

Images:

  • Descriptive alt text on informational images
  • Empty alt="" on decorative images
  • Complex images have extended descriptions

Colour:

  • 4.5:1 contrast for normal text
  • 3:1 contrast for large text and UI components
  • Colour is not the sole information carrier

Forms:

  • Every input has an associated <label>
  • Error messages are text-based and linked via aria-describedby
  • autocomplete attributes on common fields
  • Targets are at least 24 × 24px (WCAG 2.2)

Navigation:

  • Link text is descriptive out of context
  • Navigation order is consistent across pages

Content:

  • Readable at 200% zoom without horizontal scroll
  • prefers-reduced-motion respected
  • No !important on text spacing properties

Testing:

  • axe DevTools or WAVE scan with zero critical issues
  • Full keyboard navigation test completed
  • Screen reader test on key pages completed

Accessibility Is Not a Feature

Accessibility is not something you add to a finished site. It is a quality of the HTML you write from the beginning. The semantic structure, the heading hierarchy, the form labels, the alt text—these are part of building the site, not a checklist you run at the end.

That said, every site benefits from a pre-launch audit. This checklist catches the things that slip through: the image you forgot to describe, the form field with a placeholder but no label, the sticky header that obscures focused elements. Run it before every launch. Fix what it finds. The tutorials index covers the individual patterns—accessible menus, modal dialogs, focus management—in the depth each topic deserves.

← Back to Tutorials Download DFM2HTML