WCAG 2.2 Checklist: Common Problems and Practical Solutions

What WCAG actually is

WCAG is a set of testable success criteria published by the W3C. Version 2.2 adds nine new criteria to 2.1, all focused on cognitive and motor accessibility. It does not replace 2.1 — it is a superset.

The four principles

WCAG organises everything under POUR:

• Perceivable — users can perceive the content (contrast, text alternatives, captions).
• Operable — users can operate the interface (keyboard, timing, motion).
• Understandable — content and behaviour are predictable (language, labels, error handling).
• Robust — assistive tech can parse the page reliably (valid markup, ARIA correctness).

Levels A, AA, AAA

Each criterion has a level. Legal frameworks (ADA in the US, EN 301 549 in the EU, GIGW in India) typically require Level AA. AAA is aspirational and often not achievable for entire pages.

What changed in 2.2

The nine new criteria are:

1. 2.4.11 Focus Not Obscured (Minimum) — the focus indicator must not be entirely hidden by other content.
2. 2.4.12 Focus Not Obscured (Enhanced) — AAA version: no part is obscured.
3. 2.4.13 Focus Appearance — AAA: focus indicators must meet a defined minimum area and contrast.
4. 2.5.7 Dragging Movements — provide a single-pointer alternative to drag.
5. 2.5.8 Target Size (Minimum) — 24×24 CSS pixels minimum for pointer targets (with exceptions).
6. 3.2.6 Consistent Help — help mechanisms appear in the same relative order across pages.
7. 3.3.7 Redundant Entry — don't ask users to re-enter data in the same session.
8. 3.3.8 Accessible Authentication (Minimum) — no cognitive test unless there's an alternative.
9. 3.3.9 Accessible Authentication (Enhanced) — AAA version, stricter.

Where to start

Most teams begin with contrast, keyboard access, focus visibility, form labels, landmarks, and ARIA correctness. That is still the right order, but the short version leaves out what actually goes wrong on real products. The sections below make the guide more practical.

Principle 1 in real product work

The Perceivable principle is where teams most often discover that visual polish and accessible communication are not the same thing.

Text alternatives with intent

Alt text should describe purpose, not just appearance.

Realistic example:

• On an ecommerce card, a product image of a laptop bag should not use alt text like bag. A better version would be Black waterproof laptop bag with shoulder strap and front organizer pocket.
• A decorative wave shape in a hero banner should usually be ignored by assistive tech.
• An icon-only delete control still needs an accessible name such as Delete attachment.

Media alternatives that match the task

Captions, transcripts, and audio description solve different gaps.

Realistic example:

• A webinar replay needs captions.
• A podcast page should include a transcript.
• A video tutorial that silently demonstrates drag-and-drop needs either spoken explanation or accompanying text so blind users understand what changed.

Structure that survives adaptation

When users zoom heavily, use screen readers, or rely on mobile reflow, content structure matters more than styling.

Realistic example:

• A pricing page with three plan cards should still read in a sensible order when viewed at 400 percent zoom.
• A support form should not use bold paragraphs as fake headings when proper headings and field groups are needed.

Distinguishable content beyond color contrast

Contrast is essential, but it is not the whole story.

Realistic example:

• An error state should not only turn the border red. It should also include text such as Enter a valid email address.
• A focus ring should be visible against both the component and the surrounding page background.
• A tooltip revealed on hover should stay available when a keyboard user focuses the trigger.

Principle 2 in real product work

The Operable principle is where many modern web apps fail, especially when custom components replace native HTML.

Keyboard support is table stakes

If something can be clicked, it usually also needs to be tabbable, focusable, and activatable from the keyboard.

Realistic example:

• A custom combobox needs a full interaction model: Tab to reach it, Enter or Down Arrow to open it, Arrow keys to move, Enter to select, and Escape to close it.
• A modal should move focus into itself on open, trap focus while open, and return focus to the trigger when closed.
• A date picker still allows typed entry or keyboard navigation.

Timing and moving content

Users need enough time to read and complete tasks.

Realistic example:

• An insurance application warns before session expiry and lets the user extend it.
• An auto-rotating testimonial slider should have pause controls and should not steal focus as slides change.

Navigation and focus visibility

The page should help users know where they are and move confidently.

Realistic example:

• A skip link should appear as the first keyboard stop.
• A sticky header should never cover the focused button or link.
• Link labels like Read more are weak unless surrounding context makes them unique and obvious.

Input methods beyond a mouse

WCAG also protects users who rely on touch, voice input, switch devices, or alternate pointers.

Realistic example:

• A drag-and-drop backlog planner should also provide Move up and Move down controls.
• Small close icons in filter chips often need extra padding to meet the target-size expectation.
• Voice users benefit when accessible names match visible labels, for example a visible Search button should also expose the name Search.

Principle 3 in real product work

The Understandable principle is where accessibility overlaps directly with UX writing, product logic, and trust.

Language and clarity

People need to know what language the page is in and what actions are expected of them.

Realistic example:

• A checkout page should declare the correct page language.
• If an article contains a phrase in another language, that phrase should be marked correctly where practical.
• Error messages should say what happened and what to do next, not just Invalid value.

Predictable behavior

Unexpected changes of context are exhausting for many users.

Realistic example:

• Selecting a country from a dropdown should not instantly submit and refresh the page without warning.
• Global help mechanisms such as support chat, contact, or FAQ links should stay in a consistent order across templates.

Input assistance and recovery

Forms should help users succeed instead of punishing them for mistakes.

Realistic example:

• A shipping form should preserve values when validation fails.
• If billing equals shipping, the system should not force users to retype the address.
• Password fields should allow paste so password managers and copied credentials still work.

Principle 4 in real product work

The Robust principle looks technical, but the human impact is simple: broken semantics make assistive technology unreliable.

Native HTML first

The safest accessible component is usually the one the browser already understands.

Realistic example:

• Use a real <button> instead of a clickable <div>.
• Use a real checkbox when you want a checkbox.
• Only use ARIA when native elements cannot provide the needed pattern.

Names, roles, states, and relationships

Assistive technology depends on clean, truthful semantics.

Realistic example:

• A disclosure button should expose whether it is expanded or collapsed.
• A field with help text or an error should correctly reference that text programmatically.
• Duplicate IDs can quietly break relationships even when the UI still looks fine.

The major guideline families in daily work

A practical way to think about WCAG is by who tends to create the issue.

Content issues

These usually involve:

• weak alt text
• poor heading hierarchy
• vague link text
• missing transcripts
• complex or jargon-heavy instructions

Design issues

These usually involve:

• low contrast
• tiny hit areas
• weak focus styles
• motion without a reduced-motion path
• layouts that break under zoom or reflow

Engineering issues

These usually involve:

• missing keyboard support
• custom widget behavior
• broken focus management
• unlabeled controls
• incorrect ARIA usage

QA issues

These usually involve:

• not testing with keyboard only
• not checking zoom and reflow
• relying too heavily on automation
• missing regressions in dialogs, menus, and forms

The WCAG 2.2 additions, translated

The new 2.2 criteria push teams to take cognitive and motor accessibility more seriously.

Focus Not Obscured

If a user tabs to something, they need to actually see it.

Realistic example:

• A sticky cookie banner cannot cover the focused pagination controls at the bottom of a results page.

Focus Appearance

A focus indicator must be visible enough to be useful, not just technically present.

Realistic example:

• A subtle one-pixel glow on a busy background may technically exist but still fail real users.

Dragging Movements

Drag-only interactions need a simpler alternative.

Realistic example:

• Reordering a task card should also be possible with buttons or menus.

Target Size

Tiny controls increase effort and error rate, especially on touch devices.

Realistic example:

• Small close icons, favorite toggles, and pagination dots are common failures unless padding is increased.

Consistent Help

Help should not move around unpredictably.

Realistic example:

• If support chat lives after the search field in the site header, keep it there across comparable templates.

Redundant Entry

Do not ask users to keep retyping information the system already has.

Realistic example:

• A benefits application should carry forward previously entered household details between steps where appropriate.

Accessible Authentication

Authentication should not depend on memory, puzzle solving, or complicated cognitive tests when safer alternatives exist.

Realistic example:

• Passkeys, password managers, magic links, and pasted one-time codes are usually better than challenge flows that force memorization or transcription.

A realistic review order for one page

If you are reviewing a single page, a high-value order is:

1. Tab through everything without a mouse.
2. Check whether focus is always visible and never hidden.
3. Review forms, labels, instructions, and errors.
4. Zoom to 200 percent and test a narrow viewport.
5. Review headings, landmarks, title, and reading order.
6. Check images, icons, media, and alt text quality.
7. Review contrast, target size, and reduced-motion behavior.
8. Inspect custom components and ARIA patterns.

Common myths that waste time

Myth: an automated scan proves accessibility

It does not. Automated tools are useful, but they cannot fully judge focus order, error clarity, heading meaning, drag alternatives, or the quality of alt text.

Myth: WCAG is only for blind users

WCAG also supports users with low vision, deafness, mobility impairments, cognitive disabilities, vestibular conditions, temporary injuries, and age-related changes.

Myth: ARIA is the shortcut

Usually it is the opposite. Native HTML is often the faster, safer, and more robust option.

Where most teams should begin

For most teams, the best order is:

1. fix contrast and non-text contrast
2. ensure full keyboard access
3. make focus obvious and unobscured
4. repair labels, names, and form errors
5. clean up headings, landmarks, and page structure
6. replace fragile custom widgets or finish them properly
7. test zoom, reflow, target size, and reduced-motion behavior
8. review authentication and multi-step flows against the new 2.2 criteria

Related reading

Pair this guide with our color contrast guide, keyboard navigation checklist, and accessible forms guide. For the normative source, use the W3C WCAG overview and the official WCAG 2.2 recommendation.

Final takeaway

WCAG 2.2 is not only a list of criteria. It is a practical way to ask whether real people can perceive, operate, understand, and reliably use what we build.

The strongest teams do not stop at Did we pass? They also ask Would this still work if I could not use a mouse, could not hear the audio, needed heavy zoom, used voice control, or depended on a password manager?

That question is where accessibility stops feeling like compliance paperwork and starts becoming product quality.

For most teams the right sequence is: contrast → keyboard operability → focus visibility → form labels → landmarks → ARIA correctness. Our tools follow this order.