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 the outcomes that document owners and assistive-technology users need. 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 24x24 CSS pixels unless an exception applies. Test compact controls at each supported viewport instead of assuming a design token proves the outcome.
• 3.3.8 Accessible Authentication (Minimum). No cognitive-function test without an allowed alternative or assistance mechanism. Authentication needs manual task testing; the presence of a standard sign-in form does not prove this criterion passes.

Two further AA additions (3.2.6 Consistent Help and 3.3.7 Redundant Entry) often affect multi-step forms. Review them across the complete workflow, including errors and repeated data entry.

7. Low-contrast text or color-only indicators

Success criteria: 1.4.3 Contrast, 1.4.1 Use of Color.

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

DocAccessible: the public interface is covered by automated contrast checks on representative pages. For uploaded documents, color contrast remains a human-review item because a PDF can place text over images, patterns, or transparency that structural inspection cannot evaluate reliably.

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 the detected issue severities, not to a certification or marketing claim.

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 directly in context.
• Manual: complex data tables with spans, contrast review over image backgrounds, highly custom form controls, and remediating an original PDF whose visual layout and pagination must stay unchanged. Exact-layout PDF work is a separately scoped human service.

Primary sources

• W3C: Web Content Accessibility Guidelines 2.2
• W3C: What is new in WCAG 2.2
• W3C: WCAG2ICT guidance for non-web documents and software