WCAG 2.2 AA, a pragmatic checklist for documents

Why read this

WCAG 2.2 AA has 55 success criteria. You do not need to memorise them. The vast majority of real-world failures we see in documents come down to seven groups, and once you can spot them you have 80 percent of what regulators and assistive-tech users actually care about. This guide gives you the failure pattern, the success criteria it maps to, the fix, and whether DocAccessible automates it.

WCAG 2.2 is backward-compatible with 2.1 and is the current W3C recommendation. If you meet 2.2 AA you automatically meet 2.1 AA (the technical standard named in the DOJ's Title II rule). New in 2.2: stronger focus visibility, a minimum target size, and accessible authentication. W3C is now working on the WCAG 3 first public draft; 2.2 remains the conformance target for the foreseeable future.

1. Images without alt text

Success criteria: 1.1.1 Non-text Content.

Every image that conveys information needs a text alternative. Purely decorative images get an empty alt attribute so screen readers skip them. "Figure", "Image of", or "Picture" are not descriptions.

DocAccessible: generates draft alt text for every image on upload, surfaces a dedicated editor row per image, and flags images that are missing alt, marked decorative incorrectly, or using generic boilerplate.

2. Missing document title or language

Success criteria: 2.4.2 Page Titled, 3.1.1 Language of Page.

Every document needs a meaningful title and a declared language. Screen readers use both to announce the page. A missing title typically means the document tab reads the filename aloud.

DocAccessible: sets the title and lang from detected metadata. Both are editable in the app and the WCAG score updates on save.

3. Flat or skipped heading structure

Success criteria: 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, 2.4.10 Section Headings.

Assistive tech users navigate by headings. A document that uses visual styling but no semantic heading levels is effectively a single paragraph. Jumping from h1 to h3 also confuses navigation.

DocAccessible: detects heading candidates from font size and style, normalises them into a clean h1/h2/h3 hierarchy, and flags skipped levels.

4. Tables without headers or captions

Success criteria: 1.3.1 Info and Relationships.

Data tables need <th> cells with scope="col" or scope="row", and a <caption> that says what the table is for. Simple tables with a header row satisfy the minimum; complex tables need row and column groups.

DocAccessible: detects the header row heuristically, lets the user toggle header column and caption per table, and re-renders the table with the correct semantic markup on save.

5. Wrong reading order

Success criteria: 1.3.2 Meaningful Sequence.

A visually correct page can read out loud in the wrong order if the underlying tags are out of sequence. Multi-column layouts are a frequent culprit.

DocAccessible: extracts blocks in visual reading order and allows drag-to-reorder in the editor. Every save re-renders HTML in the new order.

6. Content that cannot be reached or operated by keyboard

Success criteria: 2.1.1 Keyboard, 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured (new in 2.2), 2.4.13 Focus Appearance (new in 2.2).

Every interactive element must be reachable with Tab and operable with Enter or Space. Focus rings must be visible AND not hidden by sticky headers or dialogs. Hosted HTML content is keyboard-ready by default; the same is not true of most untagged PDFs.

DocAccessible: the hosted /d/slug page is built from semantic HTML with a skip-to-content link, native focus outlines, and a header that never covers focused content. There is nothing to configure.

New in WCAG 2.2 at AA

WCAG 2.2 added six Level AA success criteria on top of 2.1. Four of them matter for document and web-app experiences:

• 2.4.11 Focus Not Obscured (Minimum). The focused element must not be completely hidden by author-created content. We keep focus rings visible even when sticky headers are in play.
• 2.5.7 Dragging Movements. Any drag action must have a non-drag alternative. Our reorder controls work with arrow-up/arrow-down buttons in addition to drag.
• 2.5.8 Target Size (Minimum). Touch targets must be at least 24x24px unless inline or sized by the browser. All interactive controls in the editor, dashboard, and hosted page meet this.
• 3.3.8 Accessible Authentication (Minimum). No cognitive-function test (typing a code correctly, solving a puzzle) without an alternative. Better-Auth email+password and SSO are compliant; CAPTCHAs, when needed, offer an audio or object-based alternative.

Two further AA additions (3.2.6 Consistent Help, 3.3.7 Redundant Entry) apply mostly to multi-step forms and are satisfied by our current flows.

7. Low-contrast text or colour-only indicators

Success criteria: 1.4.3 Contrast, 1.4.1 Use of Colour.

Body text needs a 4.5:1 contrast ratio against its background, 3:1 for larger text. Do not convey information with colour alone - add an icon, a label, or a pattern.

DocAccessible: the remediated HTML uses a WCAG-tested palette and adds text labels to status chips that were previously colour-only. The scorer flags text pairings that need review, since automated contrast checks on background images are not reliable.

How the score is computed

Our 0 to 100 score is a weighted rollup of the issues detected. Critical issues (missing alt text, no title, keyboard traps) subtract 25 points each. Serious issues subtract 12, moderate 6, minor 2, and review items 1. A document with no issues returns 100. This keeps the number tied to something a regulator or internal reviewer would care about, not to a marketing figure.

What is automated versus human-in-the-loop

• Fully automated: structure extraction, heading detection, landmark insertion, skip link, language declaration, keyboard operability, table header markup, initial alt text draft.
• Assisted: alt text quality and reading order. The first pass is automated, and the editor lets a reviewer make targeted edits in seconds.
• Manual: complex data tables with spans, contrast review over image backgrounds, and highly custom form controls. These show up in the issue list with guidance.