Dardo
ENESPT
ENESPT

Free tools

WCAG 2.2 checklist: a free accessibility self-check for ADA and WCAG 2.2 AA, criterion by criterion

This checklist turns every WCAG 2.2 Level A and AA success criterion, 55 in all, into a question a site owner can answer, with how to test it and the usual fix, written from the W3C's own WCAG 2.2 and Understanding documents. Answer as you test: the plan orders what to fix first, and you can download the report for your team. Your answers stay in your browser.

By Dardo editorial team5 min read
Get a proposal
Level
Show

0 of 55 criteria answered · 0 pass

  1. 1.1.1Non-text ContentA

    Does every meaningful image, icon and control have a text alternative that says what it is or does, and are decorative images hidden from screen readers?

    How to test it and fix it

    Test: Run WAVE or axe DevTools to list images with no text alternative, then check by hand that each alt text says what the image shows or does; no tool can judge that. Listen to the page with a screen reader such as NVDA (Windows) or VoiceOver (Mac, iPhone): icon buttons, linked logos, charts and CAPTCHAs must announce a useful name, and decorative images must stay silent.

    Usual fix: Write alt text that serves the same purpose as the image (for a linked image, where the link goes), use an empty alt (alt="") for decoration, and give icon-only buttons an accessible name. Describe complex charts in nearby text, and give any CAPTCHA a text label plus an alternative that uses a different sense.

    Usually fixed by whoever writes or uploads content.

  2. 1.2.1Audio-only and Video-only (Prerecorded)A

    Do recorded audio-only files (such as podcasts) have a transcript, and do recorded videos without sound have a text description or an audio track that gives the same information?

    How to test it and fix it

    Test: List every pre-recorded audio file and every video without sound, such as silent animations or product demos. Check that each audio file has a transcript with all speech and meaningful sounds, and that each silent video has a text description or a narrated track. This is a manual check: no tool can tell whether a transcript is complete.

    Usual fix: Publish a transcript next to each audio file and a text description (or a narrated version) of each silent video. Media that is clearly labeled as an alternative to text already on the page is exempt.

    Usually fixed by whoever writes or uploads content.

  3. 1.2.2Captions (Prerecorded)A

    Do your recorded videos with sound have accurate, synchronized captions that include who is speaking and important sounds?

    How to test it and fix it

    Test: Play each video with the sound off and captions on. Captions must cover all dialogue and meaningful sounds, identify speakers when it isn't obvious, and stay in sync. Auto-generated captions usually contain errors, so read them against the audio.

    Usual fix: Edit and publish captions for every pre-recorded video with audio, for example a WebVTT file or the captions editor in YouTube or Vimeo. Review automatic captions by hand before publishing.

    Usually fixed by whoever writes or uploads content.

  4. 1.2.3Audio Description or Media Alternative (Prerecorded)A

    In your recorded videos, is important visual information (on-screen text, actions, scene changes) available to someone who can't see it, through audio description or a full text alternative?

    How to test it and fix it

    Test: Listen to each video without looking at the screen. If you miss information that is only shown, such as on-screen text, charts or actions, the video needs audio description or a full text alternative (a transcript that also describes the visuals). If the narration already conveys everything shown, nothing more is needed.

    Usual fix: Have the narrator describe the key visuals in the script itself, add an audio-described version, or publish a descriptive transcript next to the video.

    Usually fixed by whoever writes or uploads content.

  5. 1.2.4Captions (Live)AA

    Do live videos you broadcast on your site, such as webinars and live streams, have real-time captions?

    How to test it and fix it

    Test: During a live broadcast or a test stream, turn captions on and check that they appear in real time and keep up with the speech. This applies to broadcasts you publish, not to two-way calls between people. Answer 'not applicable' if you don't stream live.

    Usual fix: Turn on live captions in your streaming platform, and for important events book a human real-time captioner (CART), since automatic live captions often get words and names wrong.

    Usually fixed by whoever writes or uploads content.

  6. 1.2.5Audio Description (Prerecorded)AA

    Do your recorded videos include audio description of important visual information, so a blind person can follow them?

    How to test it and fix it

    Test: Listen to each video without watching. If key information appears only on screen and isn't spoken, the video needs an audio-described version: at Level AA a text alternative alone is not enough. Videos whose narration already describes everything important pass.

    Usual fix: Write scripts so the narrator describes what matters on screen, or produce an audio-described version and offer it with a visible link or player control.

    Usually fixed by whoever writes or uploads content.

  7. 1.3.1Info and RelationshipsA

    Is the structure people see (headings, lists, tables, form labels, groups of fields) also built into the code, so screen readers can convey it?

    How to test it and fix it

    Test: Use WAVE or the HeadingsMap extension to see the page's structure: text that looks like a heading must be a real heading, and lists must be real lists. In data tables check that header cells are marked as headers, and in forms click each label to see whether its field gets focus. Listening with NVDA or VoiceOver confirms what tools can't.

    Usual fix: Use semantic HTML: h1 to h6 for headings, ul or ol for lists, th with scope for table headers, label for fields, and fieldset with legend for groups of radio buttons or checkboxes. Don't rely on bold text or font size alone to show structure.

    Usually fixed in the code.

  8. 1.3.2Meaningful SequenceA

    When the page is read in code order, as a screen reader does, does the content still make sense?

    How to test it and fix it

    Test: Turn off CSS (for example with the Web Developer extension) or listen with a screen reader, and check that the order matches the visual order wherever it affects meaning: steps, columns, prices next to products, labels next to fields. Layouts reordered with CSS order, grid or absolute positioning are the usual problem.

    Usual fix: Put content in the HTML in its logical order and use CSS for layout without changing that order where meaning depends on it.

    Usually fixed in the code.

  9. 1.3.3Sensory CharacteristicsA

    Can every instruction be understood without relying only on shape, color, size, position or sound (not just 'click the round button on the right')?

    How to test it and fix it

    Test: Read your instructions, help text and error messages and look for any that rely only on shape, color, size, location, orientation or sound, such as 'the green button', 'the box on the right' or 'when you hear the beep'. Each one must also name the element, for example by its visible text.

    Usual fix: Add the element's name to the instruction, for example 'Select Continue (the green button at the bottom)'.

    Usually fixed by whoever writes or uploads content.

  10. 1.3.4OrientationAA

    Does your site work in both portrait and landscape on phones and tablets, without asking people to rotate the device?

    How to test it and fix it

    Test: Open the site on a phone or tablet, or in your browser's device mode, and rotate between portrait and landscape. Content must not be locked to one orientation or show a 'please rotate your device' message, unless an orientation is essential (for example a piano app).

    Usual fix: Remove code that locks the orientation or hides content in one orientation, and make the layout responsive in both.

    Usually fixed in the code.

  11. 1.3.5Identify Input PurposeAA

    Do form fields that ask for the visitor's own details (name, email, phone, address) let the browser recognize and autofill them?

    How to test it and fix it

    Test: In each field that collects the user's own information, inspect the code with your browser's developer tools and look for a correct autocomplete attribute, such as autocomplete="email" or autocomplete="given-name". Then try filling the form with your browser's autofill. axe DevTools flags invalid values, but not missing ones, so check each field by hand.

    Usual fix: Add the matching autocomplete value from WCAG's list of input purposes (name, email, tel, street-address, postal-code and others) to each field that collects the user's own data.

    Usually fixed in the code.

  12. 1.4.1Use of ColorA

    Is color never the only way you show information, for example links inside text, required fields, errors or chart lines?

    How to test it and fix it

    Test: Look for places where color alone carries meaning: links in paragraphs that are only a different color, errors shown only in red, charts told apart only by color. View the page in grayscale (your operating system's grayscale filter or Chrome DevTools' vision deficiency emulation) and check you can still tell them apart. This needs a manual review.

    Usual fix: Add a second cue: underline links in text (or give them 3:1 contrast with the surrounding text plus another cue on hover and focus), add an icon or text to errors and statuses, and use labels or patterns in charts.

    Usually fixed in design.

  13. 1.4.2Audio ControlA

    If any sound plays automatically for more than 3 seconds, can visitors pause or stop it, or turn its volume down separately from the system volume?

    How to test it and fix it

    Test: Load each page and listen. Any audio or video that starts by itself and plays for more than 3 seconds needs a pause or stop button, or a volume control separate from the computer's, ideally near the top of the page so screen reader users can reach it quickly.

    Usual fix: Don't autoplay sound: start it only when the user presses play. If you must autoplay, keep it under 3 seconds or put a keyboard-operable pause button at the start of the page.

    Usually fixed in the code.

  14. 1.4.3Contrast (Minimum)AA

    Does all text have enough contrast with its background: at least 4.5:1, or 3:1 for large text?

    How to test it and fix it

    Test: Run WAVE or axe DevTools to find low-contrast text, then measure what tools miss with a contrast checker such as WebAIM's or the Colour Contrast Analyser: text over images or gradients, placeholder text, hover and focus states. Large text is at least 18 point (24 CSS px), or 14 point (about 18.7 CSS px) if bold. Logos and disabled controls are exempt.

    Usual fix: Adjust your palette so every text and background pair meets 4.5:1 (3:1 for large text), and put a solid or darkened layer behind text on photos.

    Usually fixed in design.

  15. 1.4.4Resize TextAA

    Can people zoom the page to 200% and still read everything and use every function, with nothing cut off or overlapping?

    How to test it and fix it

    Test: Zoom the browser to 200% (Ctrl or Cmd and +) on each template and check that no text or control is cut off, overlapping or missing, and that menus, forms and dialogs still work. On mobile, check the page doesn't block pinch-zoom (no user-scalable=no or maximum-scale=1 in the viewport meta tag).

    Usual fix: Use relative units (rem, em, %) and containers that grow with their content instead of fixed heights, and remove zoom restrictions from the viewport meta tag.

    Usually fixed in the code.

  16. 1.4.5Images of TextAA

    Is text shown as real text rather than as part of an image, except for logos?

    How to test it and fix it

    Test: Look for banners, buttons, quotes, menus or infographics whose words are part of an image: try selecting the text with the mouse, or zoom in and see whether it blurs. Logos, and cases where a particular look is essential, are exempt.

    Usual fix: Recreate the text in HTML and style it with CSS (web fonts, backgrounds, effects), keeping images for the visuals only.

    Usually fixed in design.

  17. 1.4.10ReflowAA

    At a narrow width (like a phone, or a desktop browser zoomed to 400%), does content fit the screen without sideways scrolling and without losing information or functions?

    How to test it and fix it

    Test: In a desktop browser window 1280 px wide, zoom to 400%, or set the viewport to 320 px wide in developer tools. Go through each template: you should only need to scroll up and down, and no content or function should disappear. Data tables, maps, diagrams, video and games may scroll in two directions.

    Usual fix: Use a responsive layout (media queries, flexbox or grid), let long words and URLs wrap, and make sure menus and sticky elements still work at that width.

    Usually fixed in the code.

  18. 1.4.11Non-text ContrastAA

    Do buttons, form field borders, icons, focus indicators and key parts of charts have at least 3:1 contrast with the colors next to them?

    How to test it and fix it

    Test: With a contrast checker, measure what people need to see to identify controls and their state: field borders, checkbox outlines, icon buttons, toggle states, focus outlines, chart lines and segments. Each needs 3:1 against adjacent colors; disabled controls and unstyled browser defaults are exempt. Automated tools barely check this, so it is mostly manual.

    Usual fix: Darken field borders and icons, use a high-contrast focus indicator, and add borders, labels or patterns to chart segments with similar colors.

    Usually fixed in design.

  19. 1.4.12Text SpacingAA

    If someone increases line, paragraph, letter and word spacing, does all text stay visible, without being cut off or overlapping?

    How to test it and fix it

    Test: Apply the WCAG values with a text spacing bookmarklet or browser extension: line height 1.5 times the font size, paragraph spacing 2 times, letter spacing 0.12 times and word spacing 0.16 times. Check buttons, menus, cards and tooltips: no text should be clipped, hidden or overlapping.

    Usual fix: Avoid fixed heights and overflow: hidden on containers with text, and let boxes grow with their content.

    Usually fixed in the code.

  20. 1.4.13Content on Hover or FocusAA

    Can tooltips, submenus and other content that appears on hover or focus be closed with Esc, be hovered over without vanishing, and stay until the user moves away?

    How to test it and fix it

    Test: Hover with the mouse and tab with the keyboard over elements that show extra content, such as custom tooltips, submenus and hover cards. Check that Esc closes it without moving the pointer or focus, that you can move the pointer onto it without it disappearing, and that it doesn't vanish on a timer.

    Usual fix: Let users close the extra content with Esc, keep it open while the pointer is over the trigger or the content itself, and remove auto-hide timers.

    Usually fixed in the code.

  21. 2.1.1KeyboardA

    Can everything on the site (menus, forms, sliders, pop-ups, video players, checkout) be used with the keyboard alone?

    How to test it and fix it

    Test: Put the mouse aside and use Tab, Shift+Tab, Enter, Space, the arrow keys and Esc to complete your key journeys: navigation, search, forms, dialogs, carousels, media and checkout. Every action must be possible without precise timing. No automated tool can verify this; it is a manual test.

    Usual fix: Use native HTML links, buttons and form controls, which work with the keyboard by default. For custom widgets, make them focusable and add keyboard handling that follows the WAI-ARIA Authoring Practices patterns.

    Usually fixed in the code.

  22. 2.1.2No Keyboard TrapA

    Can keyboard users always move focus away from any part of the page, including embedded videos, maps, chat widgets and dialogs?

    How to test it and fix it

    Test: Tab into every component, including third-party embeds (video, maps, chat, payment forms) and dialogs, and check you can leave each one with Tab, Shift+Tab or Esc. If another key is needed, the page must tell users which one.

    Usual fix: Fix or replace components that capture focus, and make dialogs close with Esc and return focus to the element that opened them.

    Usually fixed in the code.

  23. 2.1.4Character Key ShortcutsA

    If your site uses single-character keyboard shortcuts (a letter, number or symbol without Ctrl or Alt), can users turn them off or change them?

    How to test it and fix it

    Test: Check your documentation and code for shortcuts that use only a printable character, such as 's' for search or '?' for help. With focus outside any text field, press letters and see whether anything happens. Answer 'not applicable' if there are none.

    Usual fix: Offer a setting to turn these shortcuts off or remap them to use Ctrl or Alt, or make them work only while the relevant component has focus.

    Usually fixed in the code.

  24. 2.2.1Timing AdjustableA

    If anything on your site has a time limit (session timeouts, timed forms, automatic redirects), can users turn it off, adjust it, or extend it?

    How to test it and fix it

    Test: Find every time limit: session expiry, checkout or booking timers, automatic redirects or refreshes. Check that users can turn it off, adjust it to at least ten times the default, or get a warning with at least 20 seconds to extend it with a simple action (extendable at least ten times). Real-time events such as auctions, essential limits and limits over 20 hours are exempt.

    Usual fix: Warn users before the session expires and let them extend it with one click or key press, and remove automatic redirects and page refreshes.

    Usually fixed in the code.

  25. 2.2.2Pause, Stop, HideA

    Can visitors pause, stop or hide anything that moves, blinks, scrolls or updates automatically, such as carousels, animated banners, tickers and background videos?

    How to test it and fix it

    Test: List content that moves, blinks or scrolls on its own for more than 5 seconds alongside other content (carousels, background video, animations, tickers), and content that updates automatically (feeds, live scores). Each needs a visible, keyboard-operable pause, stop or hide control; for updates, a way to control their frequency also works.

    Usual fix: Add a pause button to carousels and background videos, stop animations within 5 seconds, or don't start them automatically.

    Usually fixed in the code.

  26. 2.3.1Three Flashes or Below ThresholdA

    Is your site free of anything that flashes more than three times in any one second?

    How to test it and fix it

    Test: Review videos, animations, GIFs and transitions for flashing or strobe effects, especially bright red. Content that flashes more than three times in any one second passes only if the flashes are below the general and red flash thresholds, which needs a flash analysis tool to measure. When in doubt, remove it.

    Usual fix: Remove or edit the flashing sequence, slow it to three flashes per second or fewer, or reduce the flashing area.

    Usually fixed by whoever writes or uploads content.

  27. 2.4.1Bypass BlocksA

    Can keyboard and screen reader users skip repeated content, such as the header and main menu, to go straight to the main content?

    How to test it and fix it

    Test: Load a page and press Tab once: a 'Skip to main content' link that moves focus to the main content is the most reliable way to pass. Also check with WAVE or a screen reader that the page uses landmarks (header, nav, main, footer) and headings, which screen reader users rely on to jump between sections.

    Usual fix: Add a skip link as the first focusable element, pointing to the main content, and mark up page regions with the header, nav, main and footer elements.

    Usually fixed in the code.

  28. 2.4.2Page TitledA

    Does every page have a title (the text in the browser tab) that describes its topic or purpose?

    How to test it and fix it

    Test: Look at the browser tab for each template, or the title in search results. It should describe the page, such as 'Contact us | Company', not just the site name or 'Untitled'. In single-page apps, check that the title changes when the view changes.

    Usual fix: Give each page its own title element, with the page topic first and the site name after it.

    Usually fixed by whoever writes or uploads content.

  29. 2.4.3Focus OrderA

    When moving through a page with the Tab key, does focus follow a logical order that preserves the meaning and the way the page works?

    How to test it and fix it

    Test: Tab through each template and journey and watch where focus goes. It should follow the reading order, move into dialogs and menus when they open, return to the trigger when they close, and never land on hidden or unexpected elements.

    Usual fix: Match the HTML order to the visual order, avoid positive tabindex values, and move focus deliberately when dialogs open and close.

    Usually fixed in the code.

  30. 2.4.4Link Purpose (In Context)A

    Can people tell where each link goes from its text, or from its text together with the sentence, paragraph or list item around it?

    How to test it and fix it

    Test: Review link text in a screen reader's links list (NVDA: Insert+F7; VoiceOver: the rotor) or with WAVE. Vague links such as 'click here' or 'read more' pass only if the surrounding sentence, paragraph, list item or table cell makes the destination clear, and image links need alt text that says where they go. WAVE flags empty links, but only a person can judge whether text is clear.

    Usual fix: Write descriptive link text ('Download the 2026 price list (PDF)') or add the missing context in the code, for example visually hidden text that completes the visible words.

    Usually fixed by whoever writes or uploads content.

  31. 2.4.5Multiple WaysAA

    Can people find each page in more than one way, for example a menu plus a search box, a site map or links between related pages?

    How to test it and fix it

    Test: Check that every page, except steps in a process such as checkout, can be reached in at least two ways: main navigation, search, a site map, a table of contents or links from related pages. A small site whose home page links to every page can use those links as the site map.

    Usual fix: Add a site search or an HTML site map, or link related pages to each other, in addition to the main menu.

    Usually fixed in design.

  32. 2.4.6Headings and LabelsAA

    Do headings and form labels clearly describe the topic of their section or the information requested?

    How to test it and fix it

    Test: Review the list of headings (HeadingsMap extension or a screen reader) and every form label. Each heading should say what its section covers and each label what to enter; vague ones such as 'Section 1', 'More' or a lone asterisk fail. Tools can list headings, but only a person can judge whether they describe the content.

    Usual fix: Rewrite headings and labels so they are short and specific.

    Usually fixed by whoever writes or uploads content.

  33. 2.4.7Focus VisibleAA

    When someone moves through the page with the keyboard, can they always see which element has focus?

    How to test it and fix it

    Test: Tab through each template and check that every link, button and field shows a visible focus indicator, including on dark backgrounds, over images and in the header and footer. CSS such as outline: none without a replacement style is the usual cause of failure.

    Usual fix: Design a clear focus style (for example a 2 px outline with an offset, in a color that contrasts with the element and the background) and apply it with :focus-visible to every interactive element.

    Usually fixed in design.

  34. 2.4.11Focus Not Obscured (Minimum)AANew in 2.2

    When an element receives keyboard focus, is at least part of it visible, not completely hidden behind sticky headers, cookie banners or chat buttons?

    How to test it and fix it

    Test: Repeat the keyboard test with the cookie banner open, the sticky header or footer showing and chat widgets visible. No focused element may be completely hidden by content the site added. Content the user opened, like an expanded menu, is acceptable if they can reveal the focused element without moving focus.

    Usual fix: Use CSS scroll-padding to make room for sticky headers and footers, keep banners and widgets from covering content, and close non-modal pop-ups when focus leaves them.

    Usually fixed in the code.

  35. 2.5.1Pointer GesturesA

    Can everything that uses multi-finger or path-based gestures (pinch, swipe, drawing a shape) also be done with a single tap or click?

    How to test it and fix it

    Test: Look for carousels, maps, image viewers and sliders that respond to swipes, pinches or tracing a path. Check that each function also has buttons or single-tap controls, such as next and previous arrows or zoom buttons. Gestures that belong to the browser or operating system don't count.

    Usual fix: Add single-pointer controls: arrows for carousels, + and - buttons for maps, and tap-to-select instead of swipe-only actions.

    Usually fixed in the code.

  36. 2.5.2Pointer CancellationA

    Do buttons and controls act when the mouse button or finger is released, not on the initial press, so people can slide away to cancel an accidental touch?

    How to test it and fix it

    Test: Press the mouse button down on a control, move the pointer off it and then release: nothing should happen. Repeat on a touchscreen. Controls that act on mousedown or touchstart fail, unless the action can be undone or acting on the press is essential, as in an on-screen piano.

    Usual fix: Trigger actions on the click event or with native buttons, not on mousedown, pointerdown or touchstart.

    Usually fixed in the code.

  37. 2.5.3Label in NameA

    For buttons, links and fields with a visible text label, does the name used by assistive technology contain that same text?

    How to test it and fix it

    Test: Compare each control's visible label with its accessible name, in the Accessibility panel of Chrome or Firefox developer tools or by listening with a screen reader. If a button shows 'Send' but its aria-label says 'Submit form', it fails, and voice-control users who say what they see can't activate it. Check by hand; automated tools catch few of these.

    Usual fix: Make the accessible name match the visible text, or start with it, and remove aria-labels that replace it with different words.

    Usually fixed in the code.

  38. 2.5.4Motion ActuationA

    If anything works by shaking or tilting the device, or by gesturing at the camera, can it also be done with a normal control, and can the motion response be turned off?

    How to test it and fix it

    Test: Look for features triggered by shaking, tilting or camera gestures, such as shake to undo. Check that each has an on-screen alternative and that the motion response can be switched off. Answer 'not applicable' if there are none.

    Usual fix: Add a regular button for each motion-triggered action and a setting to turn motion response off.

    Usually fixed in the code.

  39. 2.5.7Dragging MovementsAANew in 2.2

    Can everything done by dragging (sliders, reordering lists, moving map pins, drag-and-drop uploads) also be done with simple clicks or taps?

    How to test it and fix it

    Test: Find every drag interaction: range sliders, sortable lists, boards, map pins, file drop zones. Using a mouse or touch, try each one with single clicks or taps only, for example clicking the slider track, move up and move down buttons, or a 'Choose file' button. Keyboard support alone does not meet this criterion.

    Usual fix: Add a single-pointer alternative: click or tap to position, buttons to move items, or a file picker next to the drop zone.

    Usually fixed in the code.

  40. 2.5.8Target Size (Minimum)AANew in 2.2

    Are clickable targets at least 24 by 24 CSS pixels, or spaced far enough apart that people won't hit the wrong one?

    How to test it and fix it

    Test: Measure small targets in your browser's developer tools: icon buttons, close buttons, pagination, carousel dots, social icons. A target under 24 by 24 CSS px passes only if a 24 px circle centered on it doesn't touch another target or another small target's circle, if a larger control does the same thing on the page, or if it is a link inside a sentence. Automated tools only check part of this.

    Usual fix: Give icon buttons and small controls at least 24 by 24 CSS px with padding or min-width and min-height, or add space between them.

    Usually fixed in design.

  41. 3.1.1Language of PageA

    Does each page declare its main language in the code (for example lang="en"), so screen readers pronounce it correctly?

    How to test it and fix it

    Test: View the page source or run WAVE or axe DevTools: the html element needs a lang attribute with the right language code, such as en, es or pt-BR. Tools find a missing attribute; check by hand that the code matches the page's real language, especially on translated pages.

    Usual fix: Set lang on the html element in every template, with each translated version using its own language code.

    Usually fixed in the code.

  42. 3.1.2Language of PartsAA

    When a passage or phrase is in a different language from the rest of the page, is that marked in the code?

    How to test it and fix it

    Test: Look for quotes, testimonials, product names or menu items in another language, such as 'Español' in the language switcher of an English page. Listen with a screen reader: wrong pronunciation means the element lacks a lang attribute. Proper names, technical terms and words that have become part of the surrounding language are exempt.

    Usual fix: Add a lang attribute to the element that contains the other-language text, for example <span lang="es">.

    Usually fixed by whoever writes or uploads content.

  43. 3.2.1On FocusA

    Does moving focus to an element (with Tab or a click) avoid unexpected changes, such as opening a new window, submitting a form or moving focus elsewhere?

    How to test it and fix it

    Test: Tab through each page and its forms. Merely focusing an element must not submit a form, open a new window or dialog, load another page or move focus somewhere else.

    Usual fix: Trigger changes only when the user activates a control (click, Enter or Space), never on focus.

    Usually fixed in the code.

  44. 3.2.2On InputA

    Does changing a form control (choosing an option, ticking a box, typing) avoid unexpected changes like submitting the form or loading a new page, unless users are told beforehand?

    How to test it and fix it

    Test: Change select menus, radio buttons, checkboxes and text fields and watch what happens. If the page submits, navigates, opens a new window or moves focus elsewhere as soon as a value changes, it fails unless users were told before using the control.

    Usual fix: Add a submit or 'Go' button instead of acting on change, or explain the behavior before the control.

    Usually fixed in the code.

  45. 3.2.3Consistent NavigationAA

    Do navigation menus and links that repeat across pages appear in the same order on every page?

    How to test it and fix it

    Test: Compare the header, main menu, footer and breadcrumbs across several templates. Repeated navigation must keep the same relative order: items can be added or removed, but not reordered, unless the user changes it.

    Usual fix: Use one shared navigation component in every template.

    Usually fixed in design.

  46. 3.2.4Consistent IdentificationAA

    Are components that do the same thing identified the same way across pages (for example, the search button is always called 'Search')?

    How to test it and fix it

    Test: Compare repeated components across pages: search, cart, login, language switcher, download icons. The same function should use the same label, icon and text alternative everywhere. Consistent doesn't have to mean identical: 'Go to page 4' and 'Go to page 5' are fine.

    Usual fix: Define names and icons for recurring components in your design system and reuse them.

    Usually fixed in design.

  47. 3.2.6Consistent HelpANew in 2.2

    If you offer help (phone, email, contact form, chat or FAQ) on several pages, does it appear in the same order relative to the rest of the content on each page?

    How to test it and fix it

    Test: Note where help appears on several templates: contact details, a link to the contact form, a chat or chatbot, a link to the FAQ. Where these repeat, they must appear in the same order relative to the rest of the content; compare pages at the same screen size and zoom. The criterion doesn't require offering help, only consistency when you do.

    Usual fix: Put help links and contact details in a shared component, such as the header or footer, used on every page.

    Usually fixed in design.

  48. 3.3.1Error IdentificationA

    When a form error is detected, does the site identify the field with the problem and describe the error in text?

    How to test it and fix it

    Test: Submit each form empty and then with invalid data, such as a malformed email or a short phone number. Every error must identify the field and describe the problem in text, not only with a red border or icon. With NVDA or VoiceOver running, check that the errors are announced.

    Usual fix: Show a text message next to each field in error, link it to the field with aria-describedby, set aria-invalid="true", and for long forms list the errors at the top with links to the fields.

    Usually fixed in the code.

  49. 3.3.2Labels or InstructionsA

    Does every form field have a visible label or instructions saying what to enter, including which fields are required and any special format?

    How to test it and fix it

    Test: Review each form: every field, radio group and checkbox needs a visible label or instructions, and required fields and special formats (dates, phone numbers, passwords) must be explained before the user submits. Placeholder text that disappears while typing doesn't count as a label. WAVE and axe flag fields with no label in the code; a person must judge whether the visible instructions are enough.

    Usual fix: Add a persistent visible label above or beside each field, mark required fields in text (not just with color), and show the expected format with an example.

    Usually fixed in design.

  50. 3.3.3Error SuggestionAA

    When an error is detected and you know how to fix it, does the error message suggest the correction?

    How to test it and fix it

    Test: Trigger errors in each form. Messages should say how to fix the problem when that is known, such as 'Enter the date as MM/DD/YYYY' or 'Use at least 8 characters', not just 'Invalid input'. Leaving out a suggestion is acceptable only when giving it would compromise security or the purpose of the content, as in a test.

    Usual fix: Rewrite error messages to state the expected format, the allowed values or a suggested correction.

    Usually fixed by whoever writes or uploads content.

  51. 3.3.4Error Prevention (Legal, Financial, Data)AA

    For purchases, legal commitments, changes to stored data or test submissions, can users review and correct their information before confirming, or undo the submission?

    How to test it and fix it

    Test: Go through checkout, bookings, contracts, account deletion and any form that commits users legally or financially, changes or deletes their stored data, or submits test answers. At least one must be true: there is a review step before the final submission, the data is checked and users can correct errors, or the submission can be reversed.

    Usual fix: Add a summary and confirmation step before the final submission, a confirmation checkbox, or a period during which users can cancel.

    Usually fixed in the code.

  52. 3.3.7Redundant EntryANew in 2.2

    In multi-step processes, does the site avoid making people type the same information twice, by filling it in or letting them select it?

    How to test it and fix it

    Test: Go through multi-step forms such as checkout, sign-up or quote requests. If information entered earlier in the same process is asked for again (a billing address that matches the shipping address, for example), it must be filled in automatically or available to select. Exceptions: when re-entry is essential, required for security (like confirming a new password), or the earlier information is no longer valid.

    Usual fix: Carry data forward between steps, add a 'Same as shipping address' option, or show earlier answers for the user to select.

    Usually fixed in the code.

  53. 3.3.8Accessible Authentication (Minimum)AANew in 2.2

    Can people log in without having to memorize, transcribe or solve something, for example by letting password managers fill the form and allowing codes to be pasted?

    How to test it and fix it

    Test: Log in using a password manager, then by pasting the password and the verification code. Blocking paste or autofill, making people retype characters from an image, or a puzzle CAPTCHA without an alternative all fail. At this level, recognizing objects or recognizing content the user provided earlier is allowed. This is a manual test.

    Usual fix: Allow paste and autofill (autocomplete="username", "current-password" and "one-time-code"), and offer alternatives such as email login links, passkeys or third-party sign-in instead of puzzles.

    Usually fixed in the code.

  54. 4.1.2Name, Role, ValueA

    Do all interactive elements, especially custom ones like menus, tabs, accordions and toggles, tell assistive technology what they are, what they are called and what state they're in?

    How to test it and fix it

    Test: Use a screen reader (NVDA or VoiceOver) on menus, accordions, tabs, toggles, dialogs and custom select boxes. Each should announce a name, a role (button, tab, checkbox) and its state (expanded, selected, checked), and announce changes. axe DevTools and WAVE catch missing names on links, buttons and fields, but roles and states need a manual test.

    Usual fix: Prefer native HTML elements. For custom widgets, follow the WAI-ARIA Authoring Practices patterns: the right role, states such as aria-expanded, aria-selected or aria-checked, and a name for every control.

    Usually fixed in the code.

  55. 4.1.3Status MessagesAA

    Are status messages that appear without moving focus (such as 'Added to cart', '12 results' or 'Message sent') announced by screen readers?

    How to test it and fix it

    Test: Trigger messages that appear without taking focus: added to cart, search result counts, saved confirmations, upload progress, error summaries. With NVDA or VoiceOver running, check that each one is read aloud without you navigating to it.

    Usual fix: Insert these messages into a container with role="status" (or aria-live="polite") that is already in the page, and use role="alert" only for important, time-sensitive messages.

    Usually fixed in the code.

Your results and what to fix first

Answer the questions above; the plan builds itself as you go. Your answers stay in this browser.

    Want an audit you can show a buyer or a regulator?

    Send us your results. Our WCAG 2.2 AA audit (from USD 690) tests your templates and key journeys with keyboard and screen readers and gives you a prioritized report.

    On this page

    How to use the checklist

    • Pick a sample. Test a representative sample, as the W3C's evaluation methodology (WCAG-EM) recommends: the home page, one page of each template, a form, and complete journeys such as sign-up, contact or checkout.
    • Test in this order. Keyboard only (Tab, Shift+Tab, Enter, Space, arrow keys), then zoom to 200% and 400%, then a screen reader (NVDA on Windows or VoiceOver on Mac), then color contrast, then the content itself: alt text, headings, link text, error messages.
    • Answer strictly. "Yes" only when every page in the sample passes; "partly" when some do; "not applicable" only when the site has no such content (no video, no time limits).
    • Fix Level A first. The plan lists failures at Level A before AA, then the partial ones, with who usually fixes each: design, content or development.

    Why WCAG 2.2 AA is the target

    WCAG 2.2 became a W3C Recommendation on 5 October 2023, and in October 2025 it was approved as the international standard ISO/IEC 40500:2025. The W3C says the 2.0 and 2.1 success criteria are essentially the same in 2.2, except that 4.1.1 Parsing is obsolete and removed, so a site that meets 2.2 AA also covers what 2.1 AA asks.

    In the United States, DOJ's Title II rule requires state and local governments to meet WCAG 2.1 Level AA; an interim final rule of 20 April 2026 moved the deadlines to 26 April 2027 and 26 April 2028, depending on size. For businesses, DOJ's position is that Title III of the ADA covers their websites, without a technical standard in a regulation; its web guidance points to WCAG. Our guide to ADA website compliance covers what that means in practice.

    In Latin America, Colombia's Resolución 1519 de 2020 and Brazil's ABNT NBR 17225 also build on WCAG; see our WCAG 2.2 reference in Spanish and our guide to Brazil's accessibility law (in Portuguese).

    What's new in WCAG 2.2

    Nine success criteria are new in 2.2; six of them are at Level A or AA and are marked "New in 2.2" in the checklist:

    • 2.4.11 Focus Not Obscured (Minimum), AA: sticky headers, cookie banners and chat buttons must not completely hide the element that has keyboard focus.
    • 2.5.7 Dragging Movements, AA: anything done by dragging can also be done with a single tap or click.
    • 2.5.8 Target Size (Minimum), AA: targets are at least 24 by 24 CSS pixels, or have enough space around them.
    • 3.2.6 Consistent Help, A: help (contact details, a chat, a help page) appears in the same place across pages.
    • 3.3.7 Redundant Entry, A: people aren't asked to type the same information twice in one process.
    • 3.3.8 Accessible Authentication (Minimum), AA: signing in doesn't depend on a cognitive test such as remembering or transcribing a code, unless there's an alternative such as pasting or a password manager.

    What a self-check can't tell you

    A checklist records what your team found; it doesn't prove conformance. The W3C is explicit that evaluation tools can't determine accessibility: they help, but some checks need human judgement. The same goes for overlays: in 2025 the FTC ordered accessiBe to pay USD 1 million over claims that its tool could make any website compliant. If you need evidence for a buyer, a procurement process or a regulator, an audit tests a defined sample with assistive technology and documents each criterion.

    From self-check to audit

    Send us your results and we'll tell you what we'd test. Our web accessibility audit (WCAG 2.2 AA, from USD 690) combines automated scans with manual keyboard, screen reader, zoom and contrast testing and gives you a prioritized report; we can also fix what it finds. Our guide to what an accessibility audit costs compares published prices if you're collecting quotes.

    Questions before you choose

    How many success criteria does WCAG 2.2 AA have?

    55 at Levels A and AA: 31 at Level A and 24 at Level AA. WCAG 2.2 added nine criteria (six at A or AA, three at AAA) and removed 4.1.1 Parsing.

    What's new in WCAG 2.2?

    At Levels A and AA: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) and Accessible Authentication (3.3.8). 4.1.1 Parsing was removed as obsolete.

    Does the ADA require WCAG 2.2?

    No regulation names WCAG 2.2. DOJ's Title II rule requires WCAG 2.1 AA for state and local governments, with deadlines in 2027 and 2028; for businesses under Title III there is no technical standard in a regulation, and DOJ's guidance points to WCAG. Meeting 2.2 AA covers 2.1 AA.

    Does passing an automated scan mean my site is accessible?

    No. The W3C says evaluation tools can't determine accessibility; many criteria need a person, a keyboard and a screen reader. Use scans to find issues fast, then test manually.

    Where are my answers stored?

    In your own browser only (local storage). Nothing is sent to Dardo unless you press the button to send your results to the contact form, and even then nothing is sent until you submit the form.

    Is this checklist enough for an accessibility statement or a VPAT?

    It's a good starting point for your team, but a conformance report should rest on a documented evaluation of a defined sample. An audit provides that.

    Sources & further reading

    Sources behind this page, with further detail from the original publishers.

    From a checklist to a site that passes

    Know what the rules ask, check your site, then get it audited and fixed.