CarlasHub QA

Accessibility test case manager

WCAG 2.2 Level A and Level AA test cases for websites and web applications.

  • 14component procedures
  • 17WCAG test groups
  • 55Level A and AA criteria

Scope: all active WCAG 2.2 Level A and Level AA success criteria. Level AAA is outside this manager.

Before testing

  1. Agree the website or web application, release, languages, pages, components, states and user journeys in scope.
  2. Record the real browsers, devices, viewport sizes, input methods and assistive technologies available.
  3. Use safe test data. Do not put real user information, credentials or unnecessary personal data in evidence.
  4. Run an automated pre-check, then complete every applicable manual procedure below.
  5. Save enough evidence for another tester to identify the target and repeat the result.

Requirements and guidance

WCAG 2.2 contains the normative requirements. W3C Understanding documents, How to Meet WCAG and the ARIA Authoring Practices Guide are informative guidance.

Use the actions in this manager to collect evidence. They are not the only valid test methods, and completing one technique does not by itself prove that a success criterion passes. Assign the result from the success criterion's requirement and all applicable content in the recorded test scope.

Record outcome and progress separately

Pass — criterion outcome
Every applicable target and state completed for that criterion met the requirement.
Fail — criterion outcome
At least one applicable target failed. Record the exact target, state, action and result.
Not applicable — criterion outcome
The completed inventory contains no content or function to which the criterion applies. Do not use this when testing was blocked or incomplete.
Needs specialist review — execution status
Do not assign a completed criterion outcome until the evidence has been reviewed.
Not started, in progress or blocked — execution status
Use the status that describes the unfinished work. Do not assign a criterion outcome.

Open the working results CSV template

Test catalogue

Choose a test

Search by component, task or WCAG criterion. Add relevant tests to the plan in the sidebar, or open one directly.

Start with components: choose what is present on the page, then add WCAG groups to complete coverage.

Searches test names, summaries and covered WCAG criteria.
Test type
Theme

31 tests shown

Flashing content

Identify content that may flash more than three times per second and route it for objective analysis.

Media & motion WCAG group · 2 steps · 1 criterion
Open test TC-17 Flashing content

Selected test workflow

Run your test plan

Choose at least one test to start a guided run.

Your selected tests will appear here in a repeatable sequence.

Choose tests

WCAG-EM-inspired reporting

Review and export the evaluation

Turn the working test data into a readable report or structured data file. The report is organised around WCAG-EM 2.0; it is not a W3C conformance claim, certification or endorsement.

Report readiness

Choose at least one test to prepare a report.

    The working CSV is for continuing a test run. The HTML report is for people; the JSON file preserves the complete evaluation data for reuse.

    Detailed QA procedures

    Test common web components

    Open only the procedures you need. Follow each step in order, record the listed evidence and use the linked success-criterion decisions.

    CP-01

    Page structure, headings, landmarks and language

    Structure & content 6 steps · 7 criteria

    Check the basic structure that lets users understand and navigate a page without relying on its visual layout.

    Use this for

    • Every page template
    • Headings and content sections
    • Lists, groups and landmarks
    • Pages or passages in multiple languages

    What should happen

    • The browser title and main heading identify the page purpose.
    • Headings describe their sections and form a meaningful outline.
    • Landmarks, lists, groups and relationships shown visually are available programmatically.
    • Reading order preserves meaning at every viewport.
    • The page language and material language changes are identified programmatically.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionOpen the page and compare the browser-tab title, visible main heading and page purpose.

    Expected result
    The browser title describes the page topic or purpose, and the main heading describes the main content. Duplicate titles are not automatically failures when the pages genuinely share the same topic or purpose.
    Record
    URL, browser title, main heading, page purpose and any mismatch.

    Step 2 of 6

    ActionList every visible heading in order, then inspect the programmatic heading outline.

    Expected result
    Visible headings are exposed as headings, use descriptive text and represent the same section structure.
    Record
    First missing, empty, misleading or incorrectly represented heading.

    Step 3 of 6

    ActionInspect header, navigation, main, complementary regions and footer using landmarks or the accessibility tree.

    Expected result
    Major page regions have appropriate semantics and repeated regions can be bypassed.
    Record
    Landmark list, duplicate labels and missing main or navigation regions.

    Step 4 of 6

    ActionInspect visible lists, tables, field groups, labels and related instructions.

    Expected result
    Each visual relationship has equivalent HTML structure or programmatic association.
    Record
    Target, visible relationship and computed structure.

    Step 5 of 6

    ActionRead the page in DOM or screen-reader order without using visual position.

    Expected result
    The order remains understandable and dependent content is not separated from its trigger or label.
    Record
    The first item read in an unexpected or meaning-changing order.

    Step 6 of 6

    ActionInspect the html language and any substantial passage written in another language.

    Expected result
    The default language is correct and language changes are marked except for valid WCAG exceptions.
    Record
    Visible language, html lang value and relevant element lang values.
    Previous step Final step

    Common failures

    • A styled paragraph is used instead of a heading
    • Several pages share a generic title
    • Content order differs from visual order
    • A language selector changes text but not the page language

    Back to test catalogue

    CP-04

    Forms, labels, validation and submission

    Forms & journeys 6 steps · 13 criteria

    Check that users can understand, complete, correct and submit forms without guessing.

    Use this for

    • Contact and registration forms
    • Checkout and application forms
    • Settings and profile forms
    • File upload and multi-step forms

    What should happen

    • Every field has a persistent label and clear instructions.
    • Required status and constraints are explained before submission.
    • Errors identify the field, problem and known correction.
    • Focus moves to useful error feedback and entered data is preserved when safe.
    • Success and status messages are visible and announced.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionBefore entering data, review every label, required marker, instruction and format example.

    Expected result
    Users can determine what to enter without relying on placeholder text or triggering an error.
    Record
    Field, label, instructions and missing requirement.

    Step 2 of 6

    ActionTab through the complete form and inspect each field's accessible name, description and state.

    Expected result
    Focus order is logical and programmatic information matches the visible form.
    Record
    Focus order and computed field properties.

    Step 3 of 6

    ActionInspect autocomplete values on fields collecting personal information.

    Expected result
    Supported personal-data fields use tokens matching their purpose.
    Record
    Field purpose and autocomplete value.

    Step 4 of 6

    ActionSubmit the form empty, then with invalid formats and conflicting values.

    Expected result
    Specific text errors appear, identify each affected field and do not rely only on colour.
    Record
    Input used, error text and associated field.

    Step 5 of 6

    ActionNavigate from the error summary or submit result to every invalid field and correct it.

    Expected result
    Focus reaches the correct field, errors update accurately and valid data remains available.
    Record
    Focus destination and state after correction.

    Step 6 of 6

    ActionComplete review and submission using only the keyboard.

    Expected result
    Important data can be reviewed and corrected, submission works and the final status is announced.
    Record
    Review mechanism, submit result and announcement.
    Previous step Final step

    Common failures

    • Placeholder text is the only label
    • Errors say only Invalid
    • Focus remains on Submit while errors appear elsewhere
    • Success is visible but not announced

    Back to test catalogue

    CP-05

    Dialogs, modals, popovers and tooltips

    Interaction 8 steps · 8 criteria

    Check that layered content opens, operates and closes predictably without hiding or losing keyboard focus.

    Use this for

    • Modal dialogs
    • Cookie and consent banners
    • Popovers and non-modal panels
    • Tooltips and hover/focus content

    What should happen

    • Focus moves to a logical place when a modal opens.
    • Tab and Shift+Tab remain within a modal until it closes.
    • Dismissible content closes using Escape and a clearly named control.
    • Focus returns to the trigger after closing.
    • Tooltips and popovers are hoverable, persistent and dismissible when WCAG requires.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 8

    ActionUse Tab to reach the control that opens the layered content and activate it with Enter or Space.

    Expected result
    The content opens and a modal moves focus to a logical element inside it.
    Record
    Trigger name and first focused element.

    Step 2 of 8

    ActionPress Tab through every control in the modal and continue after the final control.

    Expected result
    Controls are reached in logical order and focus cycles within the modal instead of reaching the background page.
    Record
    Forward focus order and where focus goes after the last control.

    Step 3 of 8

    ActionPress Shift+Tab repeatedly from the first control.

    Expected result
    Reverse focus order remains inside the modal and reaches controls in reverse logical order.
    Record
    Reverse order and any background target reached.

    Step 4 of 8

    ActionAt every focus stop, inspect visibility and obstruction.

    Expected result
    A visible indicator identifies focus and the focused control is not completely hidden.
    Record
    Control and screenshot of any invisible or obscured focus.

    Step 5 of 8

    ActionPress Escape, then reopen and use the visible close control with Enter and Space.

    Expected result
    Dismissible content closes by expected methods and the close control has a clear accessible name.
    Record
    Escape result, close-control name and keyboard result.

    Step 6 of 8

    ActionAfter each close method, identify the focused element.

    Expected result
    Focus returns to the trigger or another documented logical destination.
    Record
    Focus destination after closing.

    Step 7 of 8

    ActionFor hover or focus content, reveal it, move the pointer onto it and attempt dismissal without moving focus.

    Expected result
    Applicable content remains available, can be hovered and can be dismissed under the WCAG conditions.
    Record
    Trigger method and which persistence, hover or dismissal behaviour failed.

    Step 8 of 8

    ActionInspect dialog role, accessible name, descriptions and any status messages.

    Expected result
    The layer and its controls expose correct semantics and important updates are announced.
    Record
    Role, name, descriptions and announced message.
    Previous step Final step

    Common failures

    • Focus stays behind a modal
    • Tab escapes the modal
    • Escape does nothing
    • Focus returns to the page start
    • An icon close button has no name

    Back to test catalogue

    CP-06

    Tabs, accordions and disclosure controls

    Interaction 6 steps · 7 criteria

    Check that expandable and tabbed content exposes its state, relationships and keyboard behaviour.

    Use this for

    • Accordions and FAQs
    • Tab interfaces
    • Show more controls
    • Expandable navigation or filter groups

    What should happen

    • Triggers have clear names and expose expanded or selected state.
    • Enter or Space operates button-style disclosures.
    • Supported tab arrow-key behaviour is consistent.
    • Hidden content is removed from normal focus order.
    • Triggers and controlled panels are programmatically associated.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionTab to each trigger and inspect its name, role and initial state.

    Expected result
    The trigger is visibly focused, clearly named and exposes collapsed, expanded or selected state.
    Record
    Trigger properties before activation.

    Step 2 of 6

    ActionActivate disclosure and accordion triggers with Enter and Space.

    Expected result
    The correct content opens or closes and state changes programmatically.
    Record
    Key used and state before and after.

    Step 3 of 6

    ActionTab through opened content, then close it and continue tabbing.

    Expected result
    Visible controls are reachable and controls in collapsed content are not focusable.
    Record
    First hidden control reached or visible control skipped.

    Step 4 of 6

    ActionFor tabs, use arrow keys, Home and End where the widget supports the standard pattern.

    Expected result
    Focus and selection move consistently and the corresponding panel is presented.
    Record
    Keys, focused tab, selected tab and visible panel.

    Step 5 of 6

    ActionUse Shift+Tab to leave the component and return to it.

    Expected result
    Focus enters and leaves predictably without becoming trapped.
    Record
    Entry and exit targets.

    Step 6 of 6

    ActionInspect trigger-to-panel relationships and read the component in DOM order.

    Expected result
    Each trigger controls the correct panel and the reading sequence remains meaningful.
    Record
    Control relationship and first order issue.
    Previous step Final step

    Common failures

    • A clickable heading is not keyboard operable
    • Collapsed content remains focusable
    • Selected tab is not announced
    • Activation loses focus

    Back to test catalogue

    CP-07

    Tables, lists and grouped content

    Structure & content 6 steps · 4 criteria

    Check that structured information preserves its relationships when read programmatically.

    Use this for

    • Data tables
    • Comparison tables
    • Ordered and unordered lists
    • Definition lists, radio groups and checkbox groups

    What should happen

    • Data tables identify captions and header relationships.
    • Layout tables do not expose misleading data-table semantics.
    • Visible lists are represented as lists.
    • Grouped controls have an understandable group label.
    • Reading order preserves the relationship between labels, headers and values.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionIdentify every visible table, list and grouped set of controls on the page.

    Expected result
    Each item can be classified by its actual information purpose.
    Record
    Target, type and screenshot.

    Step 2 of 6

    ActionInspect data-table caption, row headers, column headers and cell associations.

    Expected result
    Headers are programmatically associated with the cells they describe.
    Record
    Caption, header structure and first incorrect cell association.

    Step 3 of 6

    ActionNavigate the table with a screen reader or accessibility tree reading method.

    Expected result
    Users can determine the relevant headers for each data cell.
    Record
    Cell and announced headers.

    Step 4 of 6

    ActionInspect tables used only for visual layout.

    Expected result
    Layout structure does not create false header or data relationships.
    Record
    Table role and misleading announcement.

    Step 5 of 6

    ActionCompare every visual list with the DOM or accessibility tree.

    Expected result
    List boundaries and item counts are programmatically available when they convey structure.
    Record
    Visible list and computed role or item count.

    Step 6 of 6

    ActionInspect related radio buttons, checkboxes and fields as a group.

    Expected result
    The group has a programmatic label and each control has its individual label.
    Record
    Group label and control names.
    Previous step Final step

    What to record

    • Structure inventory
    • Table captions and headers
    • Cell announcements
    • List semantics
    • Group labels

    Related success criteria

    Common failures

    • Headers are styled bold but use data cells
    • A layout table announces meaningless coordinates
    • A visual list uses only div elements
    • A radio group has no group label

    Back to test catalogue

    CP-08

    Search, autocomplete, filters and results

    Interaction 6 steps · 11 criteria

    Check query entry, suggestions, filtering and result updates using keyboard and assistive technology.

    Use this for

    • Site and catalogue search
    • Autocomplete and comboboxes
    • Filters and sorting
    • Pagination, load more and result counts

    What should happen

    • Search fields and filters have clear labels.
    • Suggestions are keyboard reachable and programmatically identified.
    • Filters update without unexpected context changes.
    • Selected states do not rely only on colour.
    • Loading, counts, empty results and errors are announced appropriately.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionTab to search and filter controls and inspect their names, roles and states.

    Expected result
    Every control is clearly labelled and programmatic information matches the visible interface.
    Record
    Control label and computed properties.

    Step 2 of 6

    ActionType a partial query and wait for suggestions without moving focus.

    Expected result
    Suggestions appear without stealing focus and the number or availability is communicated.
    Record
    Typed value, focus location and announcement.

    Step 3 of 6

    ActionUse arrow keys to review suggestions, Enter to choose one and Escape to dismiss them.

    Expected result
    The active suggestion is identified, selection works and dismissal preserves valid input.
    Record
    Key sequence, active option and resulting value.

    Step 4 of 6

    ActionApply and remove each filter using only the keyboard.

    Expected result
    Controls work, selected states update and focus remains predictable.
    Record
    Filter, state before and after, and focus position.

    Step 5 of 6

    ActionTrigger result updates, empty results, invalid input and loading where available.

    Expected result
    Useful status or error information is visible and programmatically announced.
    Record
    State triggered, visible message and announcement.

    Step 6 of 6

    ActionUse pagination or Load more and then continue keyboard navigation.

    Expected result
    New content is available and focus moves or remains at a logical location.
    Record
    Activation control, new content and focus position.
    Previous step Final step

    Common failures

    • Suggestions require a mouse
    • Active suggestion is not announced
    • Filtering moves focus to the page start
    • Result updates are silent

    Back to test catalogue

    CP-09

    Images, icons, SVG, charts and canvas

    Visual & layout 6 steps · 7 criteria

    Check that non-text content has an equivalent appropriate to its purpose.

    Use this for

    • Content and decorative images
    • Logos and iconography
    • Charts, diagrams and maps
    • SVG, canvas and image buttons

    What should happen

    • Informative images have concise equivalent alternatives.
    • Decorative images are ignored by assistive technology.
    • Functional images and icons are named by purpose.
    • Complex graphics provide the same data or conclusion accessibly.
    • Information and states do not rely only on colour.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionInventory images, icons, SVG, canvas, charts and background images in every tested state.

    Expected result
    Each non-text item is classified as informative, functional, decorative or complex.
    Record
    Target, classification and screenshot.

    Step 2 of 6

    ActionCompare each informative item's alternative text with its visual purpose and surrounding text.

    Expected result
    The alternative communicates equivalent information without unnecessary duplication.
    Record
    Visible content, alternative text and missing information.

    Step 3 of 6

    ActionInspect decorative and redundant items in the accessibility tree.

    Expected result
    They do not add noise or create empty focusable controls.
    Record
    Computed role/name for questionable items.

    Step 4 of 6

    ActionInspect icon buttons, linked images and image controls.

    Expected result
    Their accessible names describe the action or destination and include visible wording where present.
    Record
    Visible icon/label and accessible name.

    Step 5 of 6

    ActionReview charts, diagrams and maps without relying on colour or visual position.

    Expected result
    Labels, patterns, text or an accessible data alternative communicate the same information.
    Record
    Visual conclusion and available non-visual equivalent.

    Step 6 of 6

    ActionMeasure applicable text, graphic parts and required control boundaries against adjacent colours.

    Expected result
    Required WCAG contrast ratios are met in all meaningful states.
    Record
    Foreground, background, ratio and tested state.
    Previous step Final step

    What to record

    • Non-text inventory
    • Alternative text
    • Decorative treatment
    • Functional names
    • Complex-data alternative
    • Contrast measurements

    Related success criteria

    Common failures

    • Alt text repeats nearby text
    • A meaningful CSS image has no alternative
    • Chart data is available only by colour
    • An icon control has no name

    Back to test catalogue

    CP-10

    Carousels, animation and dynamic updates

    Media & motion 6 steps · 8 criteria

    Check movement controls, hidden-slide focus, live updates and user control of changing content.

    Use this for

    • Carousels and sliders
    • Animations and video backgrounds
    • Tickers and auto-refresh
    • Toasts, banners, loading and infinite scroll

    What should happen

    • Applicable automatic movement can be paused, stopped or hidden.
    • Controls are named, keyboard operable and visibly focused.
    • Hidden slides are not in the focus order.
    • Automatic changes do not move focus unexpectedly.
    • Important updates are announced without excessive interruption.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionReload and observe the page without interaction for at least ten seconds.

    Expected result
    Every automatically moving or updating item can be identified and timed.
    Record
    Item, start behaviour and duration.

    Step 2 of 6

    ActionReach and operate pause, stop or hide controls using Enter and Space.

    Expected result
    Applicable movement stops and remains stopped until the user restarts it.
    Record
    Control name, key and content that did or did not stop.

    Step 3 of 6

    ActionUse keyboard controls to move through every carousel item.

    Expected result
    Previous, next and selection controls work and expose the current item.
    Record
    Control names, keys and current-item state.

    Step 4 of 6

    ActionTab through the component while different items are visible.

    Expected result
    Only visible operable content receives focus and focus order remains logical.
    Record
    Hidden item reached or visible control skipped.

    Step 5 of 6

    ActionLeave focus in the component while an automatic change occurs.

    Expected result
    Focus is not moved or lost and the user is not repeatedly interrupted.
    Record
    Focus before and after the update.

    Step 6 of 6

    ActionTrigger loading, a toast, refreshed data or added content.

    Expected result
    Important status is announced without moving focus unnecessarily.
    Record
    Trigger, visible message, announcement and focus position.
    Previous step Final step

    Common failures

    • Pause works only on hover
    • Hidden slides remain focusable
    • Rotation moves focus
    • Toasts are visible but silent

    Back to test catalogue

    CP-11

    Audio, video, captions and media controls

    Media & motion 6 steps · 9 criteria

    Check media alternatives and keyboard operation from the beginning to the end of the content.

    Use this for

    • Audio-only content
    • Prerecorded video
    • Live streams
    • Custom and embedded media players

    What should happen

    • Automatic audio can be controlled when required.
    • Prerecorded speech and sounds have accurate synchronized captions.
    • Important visuals have the required alternative or audio description.
    • Live synchronized media provides captions.
    • Media controls work by keyboard and display visible focus.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionClassify the media as audio-only, video-only, synchronized prerecorded or synchronized live.

    Expected result
    The correct WCAG alternative requirements can be selected.
    Record
    Media URL, type, duration and whether it is itself an alternative.

    Step 2 of 6

    ActionReload and check whether audio starts without user action.

    Expected result
    Audio continuing beyond three seconds has a pause, stop or independent volume control.
    Record
    Autoplay duration and available control.

    Step 3 of 6

    ActionTab to every player control and operate it with expected keyboard keys.

    Expected result
    Playback, captions, volume and full-screen functions are reachable, named and visibly focused.
    Record
    Control, accessible name, key and result.

    Step 4 of 6

    ActionPlay the complete prerecorded item with captions enabled.

    Expected result
    Captions include speech, speakers and important sounds with usable timing.
    Record
    Timestamp and exact omission or timing problem.

    Step 5 of 6

    ActionReview the content without seeing the screen, then compare the transcript or audio description.

    Expected result
    Important visual information is communicated by the required alternative.
    Record
    Missing visual information and available alternative.

    Step 6 of 6

    ActionFor live media, observe a representative sample of speech, names, numbers and sounds.

    Expected result
    Live captions are present, timely and sufficiently accurate for the content.
    Record
    Observation time and material caption error.
    Previous step Final step

    Common failures

    • Captions omit speakers or sounds
    • Controls disappear from keyboard focus
    • A transcript is treated as sufficient for every video requirement
    • Autoplay audio lacks independent control

    Back to test catalogue

    CP-12

    Pointer, touch, dragging and target size

    Interaction 6 steps · 6 criteria

    Check that pointer and touch actions do not require precision, complex gestures or accidental activation.

    Use this for

    • Drag and drop
    • Sliders and maps
    • Swipe and multipoint gestures
    • Small buttons, links and adjacent controls

    What should happen

    • Complex gestures have a simple alternative unless essential.
    • Dragging has a non-dragging alternative unless exempt.
    • Pointer actions can be cancelled or undone where required.
    • Motion-controlled functions have user-interface alternatives.
    • Targets meet minimum size or a documented exception.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 6

    ActionInventory swipe, pinch, path, drag, motion and precision-dependent operations.

    Expected result
    Every complex interaction and its purpose are identified.
    Record
    Component, gesture and intended result.

    Step 2 of 6

    ActionComplete each path-based or multipoint action using one pointer without a path.

    Expected result
    A simple control completes the same function unless the gesture is essential.
    Record
    Original gesture, alternative and result.

    Step 3 of 6

    ActionComplete each drag operation without dragging.

    Expected result
    Buttons, menus, fields or another method provide the same result unless exempt.
    Record
    Dragged item and alternative method.

    Step 4 of 6

    ActionPress down on a control, move away and release outside it; then press outside and release on it.

    Expected result
    The action does not trigger unexpectedly and can be aborted or undone as required.
    Record
    Pointer sequence and actual activation.

    Step 5 of 6

    ActionTrigger any function controlled by device motion and disable motion access where possible.

    Expected result
    An ordinary interface control performs the same function and motion can be disabled unless essential.
    Record
    Motion action, alternative and setting.

    Step 6 of 6

    ActionMeasure small targets and spacing in each responsive state.

    Expected result
    Targets are at least 24 by 24 CSS pixels or satisfy a documented WCAG exception.
    Record
    Target dimensions, spacing and claimed exception.
    Previous step Final step

    What to record

    • Gesture inventory
    • Simple alternatives
    • Cancellation result
    • Motion alternative
    • Target measurements

    Related success criteria

    Common failures

    • A slider works only by dragging
    • A map requires pinch zoom
    • Controls activate on pointer down
    • Small adjacent icons do not meet size or spacing

    Back to test catalogue

    CP-13

    Authentication, timeouts and multi-step processes

    Forms & journeys 7 steps · 10 criteria

    Check sign-in, session limits, repeated information, uploads, review and final submission.

    Use this for

    • Sign-in and account creation
    • One-time codes and CAPTCHA
    • Timed sessions
    • Multi-step processes, uploads and final submission

    What should happen

    • Users can extend or control applicable time limits.
    • Authentication supports password managers, paste and accessible alternatives.
    • Information already supplied is not unnecessarily requested again.
    • Errors preserve progress and identify corrections.
    • Important submissions can be reviewed and corrected as required.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 7

    ActionStart the complete process in a clean session and record every step, page title and initial focus target.

    Expected result
    Each step has a clear purpose and focus begins at a logical location.
    Record
    Step sequence, titles and focus targets.

    Step 2 of 7

    ActionUse password-manager fill and paste in authentication fields.

    Expected result
    Users can complete authentication without unnecessary memory or transcription barriers.
    Record
    Method attempted and any blocked action.

    Step 3 of 7

    ActionIdentify CAPTCHA, puzzle or cognitive requirements and use the supplied alternative.

    Expected result
    An accessible method exists that does not depend on prohibited cognitive-function tests unless an exception applies.
    Record
    Challenge and alternative route.

    Step 4 of 7

    ActionApproach every content-controlled timeout without completing the task.

    Expected result
    Users receive warning and can extend, adjust or turn off the limit where WCAG requires.
    Record
    Timeout length, warning time and extension result.

    Step 5 of 7

    ActionEnter information early, continue and check whether it is requested again.

    Expected result
    Previously supplied information is populated or selectable unless a valid exception applies.
    Record
    Repeated field and available reuse method.

    Step 6 of 7

    ActionTrigger upload, validation and server errors, then return to a previous step.

    Expected result
    Errors are specific, focus is useful and safely entered information is preserved.
    Record
    Error, focus destination and lost data.

    Step 7 of 7

    ActionReview, correct and submit authorized test data using only the keyboard.

    Expected result
    Required safeguards exist and final success or failure is announced.
    Record
    Review route, correction result and final announcement.
    Previous step Final step

    Common failures

    • Paste is blocked
    • Timeout warning cannot be extended
    • Information must be retyped
    • Returning to correct data loses progress
    • Submission status is silent

    Back to test catalogue

    CP-14

    Responsive layout, zoom, orientation and text spacing

    Visual & layout 7 steps · 6 criteria

    Check that content remains readable and operable when users enlarge, rotate or restyle it.

    Use this for

    • Every representative page
    • Sticky headers and banners
    • Responsive navigation and forms
    • Tables and other potentially two-dimensional regions

    What should happen

    • Content works in portrait and landscape unless essential.
    • Text resizes to 200 percent without loss.
    • At the WCAG reflow viewport, ordinary content does not require horizontal page scrolling.
    • Text-spacing overrides do not clip or overlap content.
    • Focused controls remain at least partly visible and targets remain usable.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 7

    ActionRecord browser, operating system, viewport and zoom before changing anything.

    Expected result
    The environment can be reproduced by another tester.
    Record
    Browser version, viewport, zoom and device orientation.

    Step 2 of 7

    ActionComplete the main task in portrait and landscape on a device supporting both.

    Expected result
    Content and controls remain available in both orientations unless one is essential.
    Record
    Orientation and missing or blocked function.

    Step 3 of 7

    ActionIncrease text size to 200 percent without using operating-system magnification as a substitute.

    Expected result
    Text remains readable and all content and functionality remain available.
    Record
    Clipped, overlapping or missing target.

    Step 4 of 7

    ActionUse a 1280 CSS-pixel viewport at 400 percent zoom, or an equivalent 320 CSS-pixel viewport, and complete the task.

    Expected result
    Ordinary content reflows to one-dimensional scrolling; valid two-dimensional regions scroll within their own area.
    Record
    Horizontal page scroll and the content causing it.

    Step 5 of 7

    ActionApply line height 1.5, paragraph spacing 2, letter spacing 0.12 and word spacing 0.16 times font size.

    Expected result
    No text, labels, controls or messages are clipped, hidden or overlapped.
    Record
    Affected target and screenshot.

    Step 6 of 7

    ActionTab through the page at the narrow viewport with sticky content and banners visible.

    Expected result
    Focused components are not completely obscured and remain operable.
    Record
    Focused target and obstructing content.

    Step 7 of 7

    ActionMeasure controls whose size or spacing changes responsively.

    Expected result
    Targets continue to meet minimum size or a documented exception.
    Record
    Viewport, target dimensions and exception.
    Previous step Final step

    What to record

    • Environment
    • Orientation results
    • Resize issue
    • Reflow issue
    • Spacing issue
    • Obscured focus
    • Target dimensions

    Related success criteria

    Common failures

    • Mobile controls disappear at high zoom
    • Text overlaps buttons
    • Sticky banners cover focused controls
    • Spacing overrides clip labels

    Back to test catalogue

    Complete WCAG coverage

    WCAG test groups and result decisions

    Open each applicable group. Every group contains its guided steps, criterion-level manual checks and separate result decisions.

    TC-01

    Page structure, reading order and language

    Structure & content 4 guided steps · 6 criteria

    Confirm that each page has a useful title and language, and that its visual structure and reading order are available programmatically.

    Who this affects: People who use screen readers, braille, reading tools, voice control, simplified views or page headings to navigate.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on every sampled page template and language.
    • Repeat when responsive layout, page content or the document language changes.
    • Include headings, lists, tables, groups, landmarks and instructions whose order affects meaning.

    What you need

    • A browser accessibility-tree or headings inspection tool.
    • A screen reader for a representative journey when available.
    • The expected page purpose and language.

    What should happen

    • The title identifies the page and distinguishes it from other pages in the sample.
    • Visual relationships are represented by appropriate HTML structure and useful labels.
    • The reading sequence preserves meaning, including in responsive layouts and revealed content. Assess keyboard focus order separately under SC 2.4.3.
    • The page language is correct, and language changes are identified except for names, technical terms and words adopted into the surrounding language.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 4

    ActionRead the browser-tab title, main heading and visible page purpose.

    Expected result
    The title identifies the page and distinguishes it from other pages in the sample.
    Evidence to save
    Page URL, browser title and main heading.

    Step 2 of 4

    ActionInspect headings, landmarks, lists, tables, labels and grouped controls in the accessibility tree or with a structure tool.

    Expected result
    Visual relationships are represented by appropriate HTML structure and useful labels.
    Evidence to save
    Structure outline or accessibility-tree extract for any material issue.

    Step 3 of 4

    ActionRead the page in DOM or screen-reader order without relying on its visual position.

    Expected result
    The reading sequence preserves meaning, including in responsive layouts and revealed content. Assess keyboard focus order separately under SC 2.4.3.
    Evidence to save
    The first point where reading order differs materially from the intended order.

    Step 4 of 4

    ActionInspect the page language and any passages written in another language.

    Expected result
    The page language is correct, and language changes are identified except for names, technical terms and words adopted into the surrounding language.
    Evidence to save
    The html lang value and any relevant element lang values.
    Previous step Final step

    What to record

    • Page URL, browser title and main heading.
    • Structure outline or accessibility-tree extract for any material issue.
    • The first point where reading order differs materially from the intended order.
    • The html lang value and any relevant element lang values.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.3.1 · Level A

    Info and Relationships
    Manual check — follow these steps in order

    Test with: Visual inspection, Accessibility tree, Screen reader.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory visual headings, landmarks, lists, tables, field labels, field groups, instructions, emphasized text and relationships created by position or formatting.

    Expected result
    Every meaningful structure or relationship that needs programmatic representation is included in the test inventory.
    Record
    Page area, visible relationship and element reference.

    Step 2 of 3

    ActionInspect each inventoried item in the DOM or accessibility tree, including table header associations and form label or description relationships.

    Expected result
    HTML semantics or programmatic associations expose the same structure and relationships shown visually.
    Record
    Visible presentation, computed role/name/relationship and first mismatch.

    Step 3 of 3

    ActionRead a representative complex section with a screen reader using headings, landmarks, lists, table navigation and form navigation.

    Expected result
    The announced structure lets the user understand and navigate the same relationships without relying on visual presentation.
    Record
    Navigation command, announcement and any relationship that cannot be determined.
    Previous step Final step
    Decide the result
    Pass when
    Information, structure and relationships conveyed visually are available in text or can be determined programmatically.
    Fail when
    A heading, group, list, table relationship, label or other meaningful relationship exists only visually.
    Not applicable
    Not applicable is rarely valid for an HTML page; use it only when the selected target contains no visual or programmatic structure to compare.
    Needs specialist review — execution status
    Escalate complex tables, custom widgets or relationships whose correct semantics are unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.3.1 requirement

    WCAG 1.3.2 · Level A

    Meaningful Sequence
    Manual check — follow these steps in order

    Test with: DOM-order review, Screen reader, Responsive review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify content where sequence affects meaning or operation, including instructions, form steps, cards, columns and content revealed by controls.

    Expected result
    Every sequence that could change meaning is included in the review.
    Record
    Page area, intended sequence and why order matters.

    Step 2 of 3

    ActionRead the content in DOM or screen-reader order without using its visual position.

    Expected result
    The programmatic reading sequence preserves meaning and relationships. Assess keyboard focus order separately under SC 2.4.3.
    Record
    Announced sequence and the first item that appears too early or too late.

    Step 3 of 3

    ActionRepeat after responsive reordering and after opening or updating dynamic content.

    Expected result
    Every supported layout and state keeps a meaningful programmatic sequence.
    Record
    Viewport or state, visual sequence and programmatic sequence.
    Previous step Final step
    Decide the result
    Pass when
    When presentation order affects meaning, a correct reading sequence can be programmatically determined.
    Fail when
    The DOM or assistive-technology reading sequence changes the meaning or separates dependent content.
    Not applicable
    Use only when no sequence on the selected target affects meaning.
    Needs specialist review — execution status
    Escalate when several reading sequences might reasonably preserve meaning. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.3.2 requirement

    WCAG 2.4.2 · Level A

    Page Titled
    Manual check — follow these steps in order

    Test with: Browser-title review, Screen reader or DOM inspection.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionOpen every sampled page and read the full title shown by the browser or exposed in the document title element.

    Expected result
    Each web page has a non-empty programmatic title.
    Record
    URL and exact title text.

    Step 2 of 3

    ActionCompare the title with the page purpose, main heading, task step and important state such as an error or confirmation.

    Expected result
    The title describes the page topic or purpose accurately enough to identify it.
    Record
    Title, page purpose and material mismatch.

    Step 3 of 3

    ActionCompare titles across the tested sample and revisit pages using browser history or a screen-reader page list.

    Expected result
    Each title still describes its page topic or purpose. Duplicate titles are not automatically failures when the pages genuinely share the same topic or purpose.
    Record
    Duplicated or ambiguous titles, affected pages and whether each title describes its page.
    Previous step Final step
    Decide the result
    Pass when
    The browser title describes the page topic or purpose.
    Fail when
    The title is missing, generic for a page with a specific purpose, or materially misleading. A duplicate title is a failure only when it does not describe the topic or purpose of one of the pages.
    Not applicable
    Not applicable is not valid for an in-scope web page.
    Needs specialist review — execution status
    Escalate only when the item may not meet WCAG's definition of a web page. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.2 requirement

    WCAG 2.4.6 · Level AA

    Headings and Labels
    Manual check — follow these steps in order

    Test with: Content inventory, Context review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory visible headings and labels for controls, groups, regions and task steps in every meaningful state.

    Expected result
    All text that introduces content or identifies a user-interface component is included.
    Record
    Heading or label text, target and state.

    Step 2 of 3

    ActionCompare each heading with the content it introduces and each label with the control or information it identifies.

    Expected result
    The wording describes the topic or purpose accurately and distinguishes similar sections or controls where needed.
    Record
    Target purpose and exact vague, misleading or duplicated wording.

    Step 3 of 3

    ActionAs a guided review, ask a tester unfamiliar with the page to predict the section topic or control purpose from the heading or label.

    Expected result
    Use the response to find unclear wording, but determine the WCAG result from whether the heading or label describes its topic or purpose; one tester's prediction is not conformance proof.
    Record
    Predicted topic or purpose, actual topic or purpose and the wording reviewed.
    Previous step Final step
    Decide the result
    Pass when
    Headings and labels describe their topic or purpose.
    Fail when
    A heading or label is vague, misleading or does not describe the topic or purpose of the associated content or control.
    Not applicable
    Use only when the selected target contains no headings or labelled controls.
    Needs specialist review — execution status
    Escalate wording whose adequacy depends on specialised subject matter or legal context. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.6 requirement

    WCAG 3.1.1 · Level A

    Language of Page
    Manual check — follow these steps in order

    Test with: DOM inspection, Screen-reader pronunciation check.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify the default human language used by the page's main content.

    Expected result
    The intended language is clear enough to compare with programmatic metadata.
    Record
    Page URL, visible language and locale.

    Step 2 of 3

    ActionInspect the language on the root html element and verify that the language tag is valid and matches the content.

    Expected result
    The default language can be programmatically determined using a recognized language tag.
    Record
    Exact html lang value and any validation or mismatch.

    Step 3 of 3

    ActionAs a supporting check, change locale where supported and listen to a representative passage with a screen reader that supports language switching.

    Expected result
    Use pronunciation as compatibility evidence only. Determine the WCAG result from whether a valid programmatic language matches the page; one screen reader's pronunciation is not by itself a pass or failure.
    Record
    Locale, lang value, screen reader and pronunciation observation.
    Previous step Final step
    Decide the result
    Pass when
    The default human language of the page can be programmatically determined and matches the content.
    Fail when
    The page language is missing, invalid or identifies the wrong language.
    Not applicable
    Not applicable is not valid for a page containing human-language content.
    Needs specialist review — execution status
    Escalate mixed-language shells where no default language is clear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.1.1 requirement

    WCAG 3.1.2 · Level AA

    Language of Parts
    Manual check — follow these steps in order

    Test with: Content-language inventory, DOM inspection, Screen reader.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionReview visible content for passages or phrases in a language different from the page default.

    Expected result
    Material language changes are identified while names, technical terms, indeterminate words and adopted words are separated as possible exceptions.
    Record
    Exact passage, page language and passage language.

    Step 2 of 3

    ActionInspect the nearest element containing each language change for a valid matching language attribute.

    Expected result
    Each applicable change of human language can be programmatically determined.
    Record
    Element, lang value and missing or incorrect language tag.

    Step 3 of 3

    ActionAs a supporting check, read representative changed-language content with a screen reader that supports automatic language switching.

    Expected result
    Use pronunciation as compatibility evidence only. Determine the WCAG result from whether the applicable language change can be programmatically determined.
    Record
    Passage, screen reader, pronunciation observation and programmatic language evidence.
    Previous step Final step
    Decide the result
    Pass when
    Passages or phrases in another language are identified programmatically, except names, technical terms, indeterminate words and adopted words.
    Fail when
    A material language change is not identified and is pronounced or processed as the page language.
    Not applicable
    The inspected page contains no passage or phrase in a different human language.
    Needs specialist review — execution status
    Escalate uncertainty about whether a term is a proper name, technical term or adopted expression. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.1.2 requirement

    Example targets

    • Home page, search results, detail page, legal page and every supported locale.
    • Content cards whose visual headings or grouping must also be exposed structurally.

    Common mistakes

    • Judging heading appearance without inspecting semantics.
    • Treating skipped heading levels as an automatic failure without checking whether relationships remain understandable.
    • Checking only the visible language selector instead of the programmatic language.

    Back to test catalogue

    TC-02

    Images, icons and visual text

    Visual & layout 4 guided steps · 2 criteria

    Confirm that meaningful non-text content has an equivalent and that decorative content is ignored.

    Who this affects: Blind and low-vision people, people who disable images and people using text-only or braille output.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run wherever images, icons, charts, logos, image buttons, CSS images, CAPTCHA or text embedded in images appear.

    What you need

    • Rendered page, surrounding content and an accessibility-tree or image inspection tool.

    What should happen

    • Every non-text item is classified by its purpose in context.
    • The alternative provides the same purpose or information without unnecessary duplication.
    • They do not add noise or hide meaningful information.
    • Real text is used whenever the required visual presentation can be achieved with web technology, except when the presentation is essential or customisable.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 4

    ActionInventory meaningful, functional and decorative images and icons in every tested state.

    Expected result
    Every non-text item is classified by its purpose in context.
    Evidence to save
    Target identifier, screenshot and classification.

    Step 2 of 4

    ActionCompare each meaningful item's accessible alternative with the information or purpose conveyed visually.

    Expected result
    The alternative provides the same purpose or information without unnecessary duplication.
    Evidence to save
    Accessible name or alternative text and the visual context.

    Step 3 of 4

    ActionInspect decorative and redundant images with a screen reader or accessibility tree.

    Expected result
    They do not add noise or hide meaningful information.
    Evidence to save
    Accessibility-tree state for any questionable item.

    Step 4 of 4

    ActionLook for important text presented only as an image.

    Expected result
    Real text is used whenever the required visual presentation can be achieved with web technology, except when the presentation is essential or customisable.
    Evidence to save
    Screenshot and content comparison.
    Previous step Final step

    What to record

    • Target identifier, screenshot and classification.
    • Accessible name or alternative text and the visual context.
    • Accessibility-tree state for any questionable item.
    • Screenshot and content comparison.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.1.1 · Level A

    Non-text Content
    Manual check — follow these steps in order

    Test with: Visual inspection, Accessibility tree or screen reader, Code inspection.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory every image, icon, SVG, canvas item, chart, CAPTCHA and other non-text item in the tested target, including items revealed after interaction.

    Expected result
    Every non-text item is identified and classified as informative, functional, complex, sensory, test/CAPTCHA or decorative.
    Record
    Target, state, classification and screenshot or element reference.

    Step 2 of 3

    ActionInspect the accessible name or text alternative for each informative, functional, complex, sensory or test item and compare it with the item's purpose in context.

    Expected result
    The alternative provides the same purpose or information; functional items are named by action, and complex items have an adequate extended equivalent.
    Record
    Visible content, computed alternative and any information or purpose that is missing.

    Step 3 of 3

    ActionInspect decorative or redundant items, then inspect the accessible name of every functional non-text control.

    Expected result
    Decorative items can be ignored by assistive technology, redundant alternatives do not repeat nearby content unnecessarily, and functional items have names that describe their purpose. Record keyboard operation separately under SC 2.1.1.
    Record
    Computed role and name and the first unnecessary or missing text alternative.
    Previous step Final step
    Decide the result
    Pass when
    Each non-text item meets the WCAG branch for its purpose: equivalent text, a purpose-identifying name, an appropriate media/test/sensory alternative, accessible CAPTCHA alternatives, or correct decorative treatment.
    Fail when
    A meaningful or functional item lacks an equivalent, a control name does not describe purpose, or meaningful content is hidden as decorative.
    Not applicable
    The completed sample contains no non-text content, including CSS images or image roles.
    Needs specialist review — execution status
    Escalate complex charts, CAPTCHA, sensory experiences and tests where a text equivalent could invalidate the purpose. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.1.1 requirement

    WCAG 1.4.5 · Level AA

    Images of Text
    Manual check — follow these steps in order

    Test with: Visual and code inspection, Zoom comparison.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory images, CSS backgrounds, SVG and canvas content that visibly contain words or letterforms.

    Expected result
    Every possible image of text is identified, including banners, diagrams, buttons and responsive variants.
    Record
    Target, visible wording, implementation type and screenshot.

    Step 2 of 3

    ActionDetermine whether the same visual presentation could be created with real text and CSS, or whether the image is customizable or essential to the information.

    Expected result
    Images of text are used only under the WCAG customizable or essential exceptions, including genuine logos.
    Record
    Reason real text is not used and evidence for any claimed exception.

    Step 3 of 3

    ActionZoom and inspect the suspected item and compare its accessible alternative with the visible wording.

    Expected result
    Non-exempt wording is implemented as text; exempt items still expose an appropriate text alternative.
    Record
    Zoom result, alternative text and exact non-exempt image-of-text failure.
    Previous step Final step
    Decide the result
    Pass when
    Text is used when the technologies in use can achieve the required visual presentation; only customisable or essential images of text use the criterion exceptions.
    Fail when
    Text is presented as an image even though the same visual presentation can be achieved with text and the image is neither customisable nor essential.
    Not applicable
    No image of text appears in the completed sample. Text incidental to a picture containing significant other visual content is not an image of text under WCAG.
    Needs specialist review — execution status
    Escalate logos, required visual presentations or technical diagrams when essentiality is disputed. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.5 requirement

    Example targets

    • Logos, decorative banners, profile photographs, icon-only controls, infographics and map markers.

    Common mistakes

    • Accepting a filename as useful alternative text.
    • Writing alternatives that repeat adjacent text.
    • Assuming an empty alt attribute makes a meaningful image decorative.

    Back to test catalogue

    TC-03

    Instructions and colour meaning

    Visual & layout 2 guided steps · 2 criteria

    Confirm that instructions and states do not depend only on position, shape, sound or colour.

    Who this affects: Blind and low-vision people, people with colour-vision differences and people who interpret spatial instructions differently.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on instructions, required-field indicators, validation states, charts, maps, legends, filters and selected or saved states.

    What you need

    • Every default, selected, error and success state in the sample.

    What should happen

    • The instruction also identifies the control or information in a non-sensory way when needed.
    • Text, symbols, patterns, borders or programmatic state provide the same meaning.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 2

    ActionFind instructions that refer to location, shape, size, direction, sound or another sensory characteristic.

    Expected result
    The instruction also identifies the control or information in a non-sensory way when needed.
    Evidence to save
    Exact instruction and referenced target.

    Step 2 of 2

    ActionView the page without colour or compare all states whose only visible difference may be colour.

    Expected result
    Text, symbols, patterns, borders or programmatic state provide the same meaning.
    Evidence to save
    Screenshots of each compared state.
    Previous step Final step

    What to record

    • Exact instruction and referenced target.
    • Screenshots of each compared state.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.3.3 · Level A

    Sensory Characteristics
    Manual check — follow these steps in order

    Test with: Content review, Keyboard and screen-reader confirmation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionSearch instructions and help text for references that depend on shape, colour, size, visual location, orientation or sound.

    Expected result
    All instructions using sensory descriptions are identified, including instructions revealed after errors or interaction.
    Record
    Exact instruction text and target it describes.

    Step 2 of 3

    ActionFollow each instruction without relying on the referenced sensory characteristic.

    Expected result
    The target can also be identified by text, accessible name, sequence or another non-sensory description.
    Record
    Available non-sensory identifier or the missing information.

    Step 3 of 3

    ActionConfirm the alternative description still identifies one unambiguous target with keyboard and assistive technology.

    Expected result
    Users can locate and operate the intended target without seeing its position, shape or colour or hearing a cue.
    Record
    Method used, identified target and any ambiguity.
    Previous step Final step
    Decide the result
    Pass when
    Instructions needed to understand or operate content do not rely solely on shape, colour, size, visual location, orientation or sound.
    Fail when
    A user must perceive a sensory characteristic, such as 'use the green button on the right', with no other identifier.
    Not applicable
    No instruction in the completed sample refers to a sensory characteristic.
    Needs specialist review — execution status
    Escalate when the sensory description may be incidental rather than required. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.3.3 requirement

    WCAG 1.4.1 · Level A

    Use of Color
    Manual check — follow these steps in order

    Test with: Visual review, Grayscale or colour-filter review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory every place where colour indicates meaning, state, category, selection, error, required status or interactive text.

    Expected result
    Default, hover, focus, selected, disabled, validation and data-visualization states are included.
    Record
    Target, state and meaning conveyed by colour.

    Step 2 of 3

    ActionReview each target without distinguishing its colours, using grayscale or a suitable colour-vision filter as support.

    Expected result
    Text, shape, pattern, iconography, underline or another visual cue provides the same information.
    Record
    Non-colour cue or the meaning that becomes unavailable.

    Step 3 of 3

    ActionOperate relevant controls and read charts, statuses and errors using the non-colour cue alone.

    Expected result
    The user can determine and use the information without colour perception.
    Record
    Task attempted, state selected and first ambiguous or unusable result.
    Previous step Final step
    Decide the result
    Pass when
    Colour is not the only visual means of conveying information, indicating an action, requesting a response or distinguishing an element.
    Fail when
    Meaning such as required, selected, error, available or unavailable is conveyed only by colour.
    Not applicable
    No information or state in the completed sample is conveyed through colour.
    Needs specialist review — execution status
    Escalate charts, maps and complex visualisations when the non-colour alternative is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.1 requirement

    Example targets

    • Selected filters, required fields, availability indicators, validation errors, maps and saved-item indicators.

    Common mistakes

    • Treating a contrast measurement as proof that colour is not the only cue.
    • Checking only default state and missing error or selected states.

    Back to test catalogue

    TC-04

    Orientation, text resizing, reflow and spacing

    Visual & layout 4 guided steps · 4 criteria

    Confirm that content remains available and usable when the display rotates, text grows, the viewport narrows and text spacing changes.

    Who this affects: People with low vision, people who magnify content and people who mount a device in one orientation.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on every representative page template and critical user task.

    What you need

    • Desktop browser zoom, a 320 CSS-pixel viewport, portrait and landscape device orientations and a text-spacing bookmarklet or equivalent style injection.

    What should happen

    • Content and operation are not restricted to one orientation unless that orientation is essential.
    • Text grows without losing content or functionality, except captions and images of text.
    • Content does not require scrolling in two dimensions and no content or function is lost, except parts that genuinely require a two-dimensional layout.
    • No text or function is clipped, overlapped or lost.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 4

    ActionUse the page in portrait and landscape orientation.

    Expected result
    Content and operation are not restricted to one orientation unless that orientation is essential.
    Evidence to save
    Device, orientation and any lost content or function.

    Step 2 of 4

    ActionIncrease text size to 200 percent without using assistive technology.

    Expected result
    Text grows without losing content or functionality, except captions and images of text.
    Evidence to save
    Zoom or text-size setting and affected target.

    Step 3 of 4

    ActionAt 400 percent browser zoom on a 1280 CSS-pixel-wide viewport, or an equivalent 320 CSS-pixel viewport, complete vertically scrolling tasks. Also inspect any horizontally scrolling content at a height equivalent to 256 CSS pixels.

    Expected result
    Content does not require scrolling in two dimensions and no content or function is lost, except parts that genuinely require a two-dimensional layout.
    Evidence to save
    Viewport width and height, zoom and overflow location.

    Step 4 of 4

    ActionApply line height 1.5 times font size, paragraph spacing 2 times font size, letter spacing 0.12 times font size and word spacing 0.16 times font size without changing other properties.

    Expected result
    No text or function is clipped, overlapped or lost.
    Evidence to save
    Applied settings and affected content.
    Previous step Final step

    What to record

    • Device, orientation and any lost content or function.
    • Zoom or text-size setting and affected target.
    • Viewport width and height, zoom and overflow location.
    • Applied settings and affected content.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.3.4 · Level AA

    Orientation
    Manual check — follow these steps in order

    Test with: Real mobile device or browser emulation, Portrait and landscape.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionOpen each representative page or task in portrait orientation and inventory visible content and available functionality.

    Expected result
    The page is usable in portrait unless a specific orientation is essential to its function.
    Record
    Device or emulation settings, page, content and available controls.

    Step 2 of 3

    ActionRotate to landscape without reloading and repeat the same content review and task.

    Expected result
    Content and functionality remain available and usable; the page does not enforce an unnecessary orientation.
    Record
    Landscape result, missing content and failed task step.

    Step 3 of 3

    ActionIf an orientation is restricted, verify and document why that orientation is essential rather than merely preferred.

    Expected result
    A restriction is treated as an exception only when the content or function cannot operate in the other orientation.
    Record
    Restricted orientation, affected function and evidence for the claimed exception.
    Previous step Final step
    Decide the result
    Pass when
    The content does not restrict view or operation to portrait or landscape unless a specific orientation is essential.
    Fail when
    A user cannot view or operate content after rotating the device and the restriction is not essential.
    Not applicable
    Use only when the target has no display-orientation behaviour, such as a non-visual background endpoint.
    Needs specialist review — execution status
    Escalate claims that an orientation is essential. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.3.4 requirement

    WCAG 1.4.4 · Level AA

    Resize Text
    Manual check — follow these steps in order

    Test with: Browser text zoom, Keyboard task review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionSet the browser to 100% zoom with no separate magnifier, then increase browser zoom to 200%.

    Expected result
    Text, including control labels and error messages, resizes to 200% using the browser-supported method.
    Record
    Browser, viewport, initial zoom and final zoom.

    Step 2 of 3

    ActionInspect all content and open menus, dialogs, tooltips, validation and other meaningful states at 200%.

    Expected result
    Text is readable and is not clipped, overlapped, hidden or replaced by an inaccessible alternative.
    Record
    Target, state and screenshot of any lost or obscured text.

    Step 3 of 3

    ActionComplete the representative task using only the keyboard while still at 200%.

    Expected result
    All content and functionality remain available without requiring the tester to reduce text size.
    Record
    Task, failed step, focused element and actual result.
    Previous step Final step
    Decide the result
    Pass when
    Text can be resized to 200 percent without loss of content or functionality, excluding captions and images of text.
    Fail when
    Text, instructions or controls become clipped, overlap, disappear or stop working at 200 percent.
    Not applicable
    Use only when the selected target contains no text to resize.
    Needs specialist review — execution status
    Escalate when the technology's text-resize method or an exception is uncertain. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.4 requirement

    WCAG 1.4.10 · Level AA

    Reflow
    Manual check — follow these steps in order

    Test with: Responsive viewport, 400% browser zoom, Keyboard task review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionFor horizontal writing, use a 320 CSS-pixel-wide viewport or 400% zoom with a 1280 CSS-pixel-wide browser viewport. For vertical writing, use a 256 CSS-pixel-high viewport or its equivalent zoom setup.

    Expected result
    The test represents the applicable WCAG reflow dimension without applying a separate screen magnifier.
    Record
    Browser, viewport dimensions, zoom and writing direction.

    Step 2 of 3

    ActionInspect the full page and all opened, error, loading and success states for horizontal scrolling and loss of content.

    Expected result
    Content reflows into one dimension without requiring horizontal and vertical scrolling, except for content that genuinely requires two-dimensional layout.
    Record
    State, scroll dimensions, affected content and any claimed exception.

    Step 3 of 3

    ActionComplete the representative task using keyboard controls at the test width.

    Expected result
    Text and controls remain visible, understandable and operable without returning to a wider viewport.
    Record
    Task, first blocked step, focus target and screenshot.
    Previous step Final step
    Decide the result
    Pass when
    Information and functionality remain available without two-dimensional scrolling at 320 CSS pixels wide for vertically scrolling content and at 256 CSS pixels high for horizontally scrolling content, except parts that require a two-dimensional layout for meaning or use.
    Fail when
    Ordinary page content requires scrolling in two dimensions or content or functionality is lost at either applicable dimension.
    Not applicable
    Use only when the target is not visual web content capable of reflow.
    Needs specialist review — execution status
    Escalate maps, diagrams, data tables and other content that may require two-dimensional layout. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.10 requirement

    WCAG 1.4.12 · Level AA

    Text Spacing
    Manual check — follow these steps in order

    Test with: Text-spacing bookmarklet or stylesheet, Visual and keyboard review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionApply line height of 1.5 times font size, paragraph spacing of 2 times font size, letter spacing of 0.12 times font size and word spacing of 0.16 times font size without changing other styles.

    Expected result
    All properties used by the content's language and script are set to the WCAG values. A language or script that does not use a listed property is tested with only the properties that exist for it.
    Record
    Tool or stylesheet used, language or script, applicable properties and confirmation of applied values.

    Step 2 of 3

    ActionInspect the page and every opened, validation, tooltip, dialog and responsive state with the spacing applied.

    Expected result
    No text or control is clipped, overlapped, hidden or made unreadable, and no content disappears.
    Record
    Target, state and screenshot of any loss or overlap.

    Step 3 of 3

    ActionComplete the representative task with keyboard while the text-spacing override remains active.

    Expected result
    All functionality remains available and labels, instructions and values remain associated with their controls.
    Record
    Task, failed step and observed layout or operation problem.
    Previous step Final step
    Decide the result
    Pass when
    Applying the supported WCAG text-spacing values without changing other styles causes no loss of content or functionality. For a language or script that does not use a listed property, test only the properties that exist for that language and script.
    Fail when
    Text is clipped, hidden, overlaps other content or makes a control unusable after the applicable spacing values are applied.
    Not applicable
    The selected target contains no text in markup that supports any of the listed spacing properties.
    Needs specialist review — execution status
    Escalate languages, scripts, canvas, SVG or embedded content when the applicable spacing properties or text technology are uncertain. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.12 requirement

    Example targets

    • Search forms, filter panels, content cards, sticky primary controls, cookie dialogs, navigation menus and registration forms.

    Common mistakes

    • Testing a narrow window without setting or recording the CSS-pixel viewport.
    • Using only operating-system magnification instead of browser zoom for reflow.
    • Failing content merely because a genuinely two-dimensional table scrolls within its own region.

    Back to test catalogue

    TC-05

    Text and control contrast

    Visual & layout 2 guided steps · 2 criteria

    Measure whether text and essential visual boundaries have enough contrast in every meaningful state.

    Who this affects: People with low vision, colour-vision differences or reduced contrast sensitivity.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on representative text styles and every control state, including focus, hover, selected, disabled when meaningful and validation error.

    What you need

    • A contrast measurement tool that reports foreground, background and ratio.
    • Unmodified page colours and no colour-vision simulation during measurement.

    What should happen

    • Ordinary text reaches 4.5:1; qualifying large-scale text reaches 3:1; documented WCAG exceptions are handled separately.
    • Required visual information reaches 3:1 against adjacent colours unless a documented exception applies.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 2

    ActionMeasure ordinary text and images of text against their actual background.

    Expected result
    Ordinary text reaches 4.5:1; qualifying large-scale text reaches 3:1; documented WCAG exceptions are handled separately.
    Evidence to save
    Foreground, background, ratio, font size and weight.

    Step 2 of 2

    ActionMeasure boundaries and visual states needed to identify or operate controls, plus meaningful graphic parts.

    Expected result
    Required visual information reaches 3:1 against adjacent colours unless a documented exception applies.
    Evidence to save
    Target, state, adjacent colours and ratio.
    Previous step Final step

    What to record

    • Foreground, background, ratio, font size and weight.
    • Target, state, adjacent colours and ratio.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.4.3 · Level AA

    Contrast (Minimum)
    Manual check — follow these steps in order

    Test with: Contrast analyser, Manual colour sampling, State review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory visible text and images of text in every meaningful state, including text over images, gradients, placeholders and validation messages.

    Expected result
    All applicable foreground/background combinations are included; logos and incidental or inactive text are identified separately.
    Record
    Text sample, state, size, weight and background.

    Step 2 of 3

    ActionSample the actual foreground and adjacent background colours at the least favourable readable point and calculate the contrast ratio.

    Expected result
    Normal text reaches 4.5:1 and qualifying large text reaches 3:1, unless a WCAG exception applies.
    Record
    Foreground, background, calculated ratio, text size/weight and threshold.

    Step 3 of 3

    ActionRepeat for hover, focus, selected, error and responsive states and check any automated indeterminate results manually.

    Expected result
    Text remains above the applicable ratio in every state a user must read.
    Record
    State, ratio and screenshot of each confirmed failure or unresolved sample.
    Previous step Final step
    Decide the result
    Pass when
    Text reaches 4.5:1, or 3:1 for qualifying large-scale text, unless it is incidental, inactive, part of a logo or otherwise covered by the criterion's exception.
    Fail when
    Applicable text or an image of text is below its required ratio.
    Not applicable
    The selected target contains no visual text or image of text requiring contrast.
    Needs specialist review — execution status
    Escalate uncertain font-size conversion, anti-aliased sampling, gradients, images or exception claims. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.3 requirement

    WCAG 1.4.11 · Level AA

    Non-text Contrast
    Manual check — follow these steps in order

    Test with: Contrast analyser, Manual colour sampling, Interactive-state review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory visual boundaries and states required to identify or operate controls, plus meaningful parts of graphics.

    Expected result
    Input boundaries, focus indicators, selected states, icons, chart marks and adjacent colours are included where required for understanding.
    Record
    Component or graphic, required visual part, state and adjacent colour.

    Step 2 of 3

    ActionMeasure the required visual part against each adjacent colour at the least favourable point.

    Expected result
    Required control and graphic information reaches at least 3:1 unless a WCAG exception applies.
    Record
    Foreground, adjacent colour, ratio, state and threshold.

    Step 3 of 3

    ActionRepeat after hover, focus, selection, validation and theme changes; separately identify inactive controls or author-unchanged native controls.

    Expected result
    Every user-required state remains perceivable, and exceptions are not applied to active custom controls.
    Record
    State, result and evidence for any claimed exception.
    Previous step Final step
    Decide the result
    Pass when
    Visual information required to identify controls, states and meaningful graphics reaches 3:1 against adjacent colours, unless the appearance is user-agent controlled or essential.
    Fail when
    A required boundary, state indicator, focus indicator or meaningful graphic part is below 3:1.
    Not applicable
    No required non-text visual information appears in the selected target.
    Needs specialist review — execution status
    Escalate uncertainty about which visual parts are required to identify or understand the target. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.11 requirement

    Example targets

    • Search-field borders, filter checkboxes, focus indicators, selected tabs, form errors, charts and map controls.

    Common mistakes

    • Sampling from a compressed screenshot instead of rendered colours.
    • Measuring decorative borders that are not required to identify the control.
    • Using one measurement for all interactive states.

    Back to test catalogue

    TC-06

    Content shown on hover or focus

    Interaction 2 guided steps · 1 criterion

    Confirm that tooltips, menus and other additional content can be dismissed, reached and kept visible when required.

    Who this affects: People using magnification, keyboard navigation, pointer alternatives or screen readers.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run when pointer hover or keyboard focus reveals content that later disappears.

    What you need

    • A mouse or trackpad and keyboard.

    What should happen

    • The same useful content is available for relevant input methods.
    • The content is hoverable, dismissible and persistent until its trigger is removed, the user dismisses it or it is no longer valid, unless a WCAG exception applies.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 2

    ActionReveal each tooltip, popover, menu or preview using both hover and keyboard focus where available.

    Expected result
    The same useful content is available for relevant input methods.
    Evidence to save
    Trigger, input method and revealed content.

    Step 2 of 2

    ActionMove the pointer onto the revealed content, dismiss it without moving focus where appropriate, and leave it open without interacting.

    Expected result
    The content is hoverable, dismissible and persistent until its trigger is removed, the user dismisses it or it is no longer valid, unless a WCAG exception applies.
    Evidence to save
    Exact action and which of the three behaviours failed.
    Previous step Final step

    What to record

    • Trigger, input method and revealed content.
    • Exact action and which of the three behaviours failed.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.4.13 · Level AA

    Content on Hover or Focus
    Manual check — follow these steps in order

    Test with: Keyboard, Pointer, Zoomed-state review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory additional content that appears on pointer hover or keyboard focus and is controlled by the page rather than the browser.

    Expected result
    Tooltips, custom previews, submenus and other applicable hover/focus content are included.
    Record
    Trigger, reveal method and displayed content.

    Step 2 of 3

    ActionReveal each item, attempt to dismiss it without moving pointer or focus, and move the pointer from the trigger onto the additional content.

    Expected result
    The content can be dismissed without moving focus or hover when required, and pointer-triggered content remains visible while hovered.
    Record
    Dismissal key or control, pointer path and actual result.

    Step 3 of 3

    ActionLeave the content visible without dismissing it, then move focus or hover away and repeat at increased zoom.

    Expected result
    The content persists until the user dismisses it, the trigger condition ends or its information is no longer valid, and it does not prevent access to page content.
    Record
    Persistence result, end condition and any content obscured.
    Previous step Final step
    Decide the result
    Pass when
    Author-controlled additional content triggered by hover or focus is dismissible without moving hover or focus unless it communicates an input error or does not obscure or replace other content; hover-triggered content is hoverable; and the content remains until its trigger is removed, the user dismisses it or it is no longer valid.
    Fail when
    The content covers other information with no qualifying dismissal, disappears when the pointer enters it, or disappears before the user removes the trigger or dismisses it.
    Not applicable
    No author-controlled additional content becomes visible and then hidden because of hover or focus.
    Needs specialist review — execution status
    Escalate whether content is user-agent controlled or whether the input-error or non-obscuring condition applies. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.13 requirement

    Example targets

    • Navigation flyouts, location suggestions, help tooltips, share controls and content-card previews.

    Common mistakes

    • Testing hover without keyboard focus.
    • Failing content that is controlled entirely by an unmodified browser title tooltip without reviewing the exception.

    Back to test catalogue

    TC-07

    Keyboard access, focus and bypass

    Interaction 4 guided steps · 6 criteria

    Complete every interaction with a keyboard while tracking focus order, visibility and recovery.

    Who this affects: People using keyboards, switch devices, keyboard emulators, screen readers or other sequential input.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on every shared interactive component and complete user task.

    What you need

    • Physical keyboard and a clean browser session.
    • Pointer parked outside the page content.

    What should happen

    • Every function is reachable in a meaningful order, and focus is always visible and not entirely hidden.
    • All functionality works without a pointer and focus remains predictable when content opens, closes, updates or reports an error.
    • Focus is never trapped unless a documented method for leaving is provided and usable.
    • Focus moves to the intended main region or repeated block is otherwise bypassed.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 4

    ActionStarting from the browser controls, use Tab and Shift+Tab through the full page and every revealed state.

    Expected result
    Every function is reachable in a meaningful order, and focus is always visible and not entirely hidden.
    Evidence to save
    Exact key sequence and first unexpected focus target.

    Step 2 of 4

    ActionUse Enter, Space, arrow keys and Escape according to each control's expected keyboard behaviour.

    Expected result
    All functionality works without a pointer and focus remains predictable when content opens, closes, updates or reports an error.
    Evidence to save
    Control, key, expected operation and actual result.

    Step 3 of 4

    ActionEnter and leave menus, dialogs, autocomplete, carousels, embedded media and third-party content.

    Expected result
    Focus is never trapped unless a documented method for leaving is provided and usable.
    Evidence to save
    Entry, attempted exit and recovery.

    Step 4 of 4

    ActionActivate the skip link or another bypass mechanism before traversing repeated content.

    Expected result
    Focus moves to the intended main region or repeated block is otherwise bypassed.
    Evidence to save
    Bypass control and resulting focus target.
    Previous step Final step

    What to record

    • Exact key sequence and first unexpected focus target.
    • Control, key, expected operation and actual result.
    • Entry, attempted exit and recovery.
    • Bypass control and resulting focus target.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 2.1.1 · Level A

    Keyboard
    Manual check — follow these steps in order

    Test with: Keyboard only, Component interaction review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionPut the pointer aside, reload the page and use Tab, Shift+Tab and the expected component keys to reach every interactive function.

    Expected result
    All functionality is reachable by keyboard except functions whose input path is essential.
    Record
    Exact key sequence and first unreachable target or function.

    Step 2 of 3

    ActionOperate every link, button, form control, menu, dialog, disclosure, media control, drag alternative and custom widget using its expected keyboard interaction.

    Expected result
    Each operation completes once and exposes the same result available to pointer users.
    Record
    Control, key, expected action and actual result.

    Step 3 of 3

    ActionRepeat for content added after loading and for opened, error, empty, loading and success states.

    Expected result
    Dynamic and state-specific functions remain keyboard operable and do not require a mouse.
    Record
    State, new control or function and any unavailable keyboard operation.
    Previous step Final step
    Decide the result
    Pass when
    All functionality is operable through a keyboard interface without requiring specific timing for individual keystrokes, except functions whose underlying purpose requires path-dependent input.
    Fail when
    A function requires a mouse, touch or path gesture and has no keyboard operation.
    Not applicable
    The selected target provides no user functionality.
    Needs specialist review — execution status
    Escalate drawing, handwriting, free-path or other functions that may meet the exception. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.1.1 requirement

    WCAG 2.1.2 · Level A

    No Keyboard Trap
    Manual check — follow these steps in order

    Test with: Keyboard only, Forward and reverse navigation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionTab and Shift+Tab through the complete page, entering every embedded player, menu, dialog, editor and custom widget.

    Expected result
    Focus can enter and leave each component using keyboard interaction, except while intentionally contained in an open modal that can be closed.
    Record
    Component, entry key sequence and attempted exit sequence.

    Step 2 of 3

    ActionWhere ordinary Tab or arrow keys do not leave a component, follow any displayed keyboard instruction and test Escape or the documented exit command.

    Expected result
    A working exit method is available and users are informed when a non-standard method is required.
    Record
    Instruction text, exit keys and focus destination.

    Step 3 of 3

    ActionRepeat after validation errors, dynamic updates and nested overlays.

    Expected result
    No state leaves keyboard focus permanently trapped or lost.
    Record
    State, trapped element, keys attempted and last known focus target.
    Previous step Final step
    Decide the result
    Pass when
    Keyboard focus can move away from every component; any non-standard exit method is communicated to the user.
    Fail when
    Focus enters a component and cannot be moved away with the keyboard, or the required exit method is not explained.
    Not applicable
    The selected target contains no keyboard-focusable component.
    Needs specialist review — execution status
    Escalate embedded third-party content when responsibility or an exit mechanism is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.1.2 requirement

    WCAG 2.4.1 · Level A

    Bypass Blocks
    Manual check — follow these steps in order

    Test with: Keyboard, Landmark and heading inspection.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify every available mechanism for bypassing blocks repeated across pages, such as a skip link, page regions, headings or another supported navigation method.

    Expected result
    At least one mechanism enables users of its supported input or assistive technology to bypass the repeated block.
    Record
    Repeated block, bypass mechanism, supported user method and visible or programmatic label.

    Step 2 of 3

    ActionUse each bypass mechanism with the input method it supports.

    Expected result
    The mechanism moves navigation to the named destination or otherwise skips the repeated block. For a skip link, focus and subsequent Tab navigation start at the intended location.
    Record
    Mechanism, command or activation key, destination and next navigation target.

    Step 3 of 3

    ActionCompare the available bypass mechanism on another page containing the same repeated block.

    Expected result
    The repeated block can be bypassed on every applicable page in the tested set.
    Record
    Compared pages, repeated block and missing or ineffective mechanism.
    Previous step Final step
    Decide the result
    Pass when
    A mechanism lets users bypass blocks repeated across pages, such as navigation and repeated filters.
    Fail when
    Keyboard or assistive-technology users must traverse the same substantial repeated block on every page with no bypass method.
    Not applicable
    The page contains no content block repeated across multiple pages.
    Needs specialist review — execution status
    Escalate single-page applications whose route changes may alter what counts as repeated content. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.1 requirement

    WCAG 2.4.3 · Level A

    Focus Order
    Manual check — follow these steps in order

    Test with: Tab and Shift+Tab, Screen-reader or DOM order review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionList interactive elements in the order a user needs to encounter them to preserve meaning and complete the task.

    Expected result
    A logical reference order is documented before keyboard order is judged.
    Record
    Target list and intended sequence.

    Step 2 of 3

    ActionUse Tab and Shift+Tab through the page and operate controls that add, remove, reorder or reveal focusable content.

    Expected result
    Focus moves in an order that preserves meaning and operation in both directions and after state changes.
    Record
    Exact focus sequence and first unexpected transition.

    Step 3 of 3

    ActionOpen menus and dialogs, trigger errors and complete navigation or submission actions while tracking focus.

    Expected result
    Focus moves to useful destinations and returns logically without skipping required content or moving behind overlays.
    Record
    Trigger, focus before and after, and why any transition blocks understanding or operation.
    Previous step Final step
    Decide the result
    Pass when
    When focus order affects meaning or operation, focus moves in an order that preserves both.
    Fail when
    Focus jumps, enters hidden content, misses revealed controls or reaches controls in an order that makes the task confusing or unusable.
    Not applicable
    The selected target has no focusable component or meaningful focus sequence.
    Needs specialist review — execution status
    Escalate composite widgets with managed focus patterns. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.3 requirement

    WCAG 2.4.7 · Level AA

    Focus Visible
    Manual check — follow these steps in order

    Test with: Keyboard only, Default and interactive-state review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionUse Tab, Shift+Tab, arrow keys and other expected component keys to move focus through every operable element.

    Expected result
    A visible focus indicator is present whenever a keyboard-operable element has focus.
    Record
    Element, key and screenshot of its focused state.

    Step 2 of 3

    ActionCheck focus against all backgrounds and in hover, selected, error, disabled-adjacent and responsive states.

    Expected result
    The indicator remains visually identifiable and is not removed by a component state or background change.
    Record
    State, background and first invisible or ambiguous indicator.

    Step 3 of 3

    ActionMove focus into and out of custom widgets, menus, dialogs and content revealed dynamically.

    Expected result
    Focus remains visible during managed-focus interaction and after focus is moved by script.
    Record
    Component, focus sequence and state where the indicator disappears.
    Previous step Final step
    Decide the result
    Pass when
    Every keyboard-operable control has a mode in which keyboard focus is visible.
    Fail when
    Focus is absent, indistinguishable or visible only on some interactive controls.
    Not applicable
    The selected target has no keyboard-operable user interface.
    Needs specialist review — execution status
    Escalate custom focus styling whose visibility cannot be distinguished reliably. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.7 requirement

    WCAG 2.4.11 · Level AA

    Focus Not Obscured (Minimum)
    Manual check — follow these steps in order

    Test with: Keyboard only, Overlay and sticky-content review, Forward and reverse navigation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionTab forward through the page while sticky headers, cookie notices, chat controls, drawers and other author-created overlays are present.

    Expected result
    No focused component is entirely hidden by author-created content.
    Record
    Focused component, overlay and screenshot at the failure point.

    Step 2 of 3

    ActionRepeat with Shift+Tab and after opening menus, dialogs, validation messages and responsive navigation.

    Expected result
    Reverse and state-specific focus targets are also not completely obscured.
    Record
    State, reverse focus sequence and obscuring content.

    Step 3 of 3

    ActionScroll each partially covered target into view using only ordinary keyboard navigation and activate it.

    Expected result
    Partially visible focus remains usable for this minimum criterion; any completely hidden target is recorded as a failure.
    Record
    Visible portion, activation result and whether the target was completely hidden.
    Previous step Final step
    Decide the result
    Pass when
    When a component receives keyboard focus, it is not entirely hidden by author-created content. If user-opened content obscures it, the focused component can be revealed without advancing focus.
    Fail when
    Sticky headers, cookie banners, dialogs or other authored content entirely hide the focused component with no qualifying way to reveal it.
    Not applicable
    The selected target has no keyboard-focusable component.
    Needs specialist review — execution status
    Escalate user-opened or user-repositioned content when the focus-obscuring boundary is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.4.11 requirement

    Example targets

    • Global navigation, language picker, site search, filters, autocomplete, pagination, save control, cookie dialog, video controls and external handoff.

    Common mistakes

    • Using the mouse after focus disappears.
    • Counting every nonstandard arrow-key pattern as a WCAG failure without checking whether Tab and activation still operate the function.
    • Checking only the homepage.

    Back to test catalogue

    TC-08

    Character-key shortcuts

    Interaction 1 guided step · 1 criterion

    Confirm that single-letter, number or punctuation shortcuts do not activate unexpectedly during speech input or typing.

    Who this affects: People using speech recognition, dictation or keyboard input who may trigger controls accidentally.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run when the website defines shortcuts activated by a letter, number, punctuation mark or symbol without a modifier key.

    What you need

    • Feature shortcut documentation and every relevant editable field or focused component.

    What should happen

    • Each shortcut can be turned off, remapped to include a non-printable key, or is active only while its component has focus.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 1

    ActionIdentify author-defined shortcuts that use only a printable character and test them while focus is outside and inside their component.

    Expected result
    Each shortcut can be turned off, remapped to include a non-printable key, or is active only while its component has focus.
    Evidence to save
    Shortcut, focus location, configuration and observed action.
    Final step

    What to record

    • Shortcut, focus location, configuration and observed action.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 2.1.4 · Level A

    Character Key Shortcuts
    Manual check — follow these steps in order

    Test with: Keyboard, Shortcut settings review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify shortcuts that activate using one letter, number, punctuation mark or symbol without a modifier key.

    Expected result
    All page-defined single-character shortcuts are inventoried; ordinary typing inside inputs is not misclassified.
    Record
    Key, function, active context and where the shortcut is documented.

    Step 2 of 3

    ActionWith focus in each relevant page context, press the inventoried shortcut and common printable characters.

    Expected result
    No single-character shortcut triggers unexpectedly while the user is typing or issuing speech commands.
    Record
    Focus target, key pressed and triggered function.

    Step 3 of 3

    ActionFor each active shortcut, locate and test a method to turn it off, remap it to include a modifier, or restrict it to when the relevant component has focus.

    Expected result
    At least one permitted control method works and persists for the intended scope.
    Record
    Available setting, changed shortcut and retest result.
    Previous step Final step
    Decide the result
    Pass when
    Every author-defined character-only shortcut can be disabled, remapped to use a modifier or non-printable key, or is active only when the associated component has focus.
    Fail when
    A character-only shortcut remains globally active with no qualifying control.
    Not applicable
    The completed sample contains no author-defined character-only keyboard shortcut.
    Needs specialist review — execution status
    Escalate shortcuts supplied entirely by the browser, operating system or unmodified assistive technology. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.1.4 requirement

    Example targets

    • Custom media players, interactive maps, command menus or advanced search interfaces.

    Common mistakes

    • Testing ordinary access keys or browser shortcuts as though they were authored by the website.
    • Assuming no visible shortcut help means no shortcut exists.

    Back to test catalogue

    TC-10

    Pointer, touch, dragging and motion

    Interaction 3 guided steps · 5 criteria

    Confirm that pointer and touch interactions can be completed without complex gestures, accidental activation, dragging or device motion.

    Who this affects: People with limited dexterity, tremor, speech input, alternative pointing devices or mounted devices.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on touch layouts, maps, sliders, carousels, draggable filters, swipe interfaces and motion-controlled features.

    What you need

    • Mouse or trackpad, a touch device where touch behaviour exists, and a way to measure CSS-pixel target size.

    What should happen

    • A simple alternative completes the same function unless the complex input is essential or the functionality falls within a documented exception.
    • Activation does not occur on the down event, or the user can abort, undo or reverse it, unless completing on down is essential.
    • Targets are at least 24 by 24 CSS pixels or meet a documented spacing or other criterion exception.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify multipoint, path-based, dragging and device-motion operations, then try the documented single-pointer alternative.

    Expected result
    A simple alternative completes the same function unless the complex input is essential or the functionality falls within a documented exception.
    Evidence to save
    Original gesture and alternative control.

    Step 2 of 3

    ActionPress down on controls, move away before release, and release on the target.

    Expected result
    Activation does not occur on the down event, or the user can abort, undo or reverse it, unless completing on down is essential.
    Evidence to save
    Pointer sequence and resulting action.

    Step 3 of 3

    ActionMeasure small pointer targets and the spacing around them in each responsive state.

    Expected result
    Targets are at least 24 by 24 CSS pixels or meet a documented spacing or other criterion exception.
    Evidence to save
    Target dimensions, spacing and exception if used.
    Previous step Final step

    What to record

    • Original gesture and alternative control.
    • Pointer sequence and resulting action.
    • Target dimensions, spacing and exception if used.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 2.5.1 · Level A

    Pointer Gestures
    Manual check — follow these steps in order

    Test with: Touch or pointer, Single-pointer alternative review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory functions that use multipoint or path-based gestures, including pinch, two-finger movement, swipe paths, drawing and free-form tracing.

    Expected result
    Every complex pointer gesture and the function it performs are identified.
    Record
    Component, gesture, device and resulting function.

    Step 2 of 3

    ActionComplete the same function using a single pointer without following a path, such as tapping a button, choosing a value or using separate zoom controls.

    Expected result
    A simple alternative performs the same function unless the complex gesture is essential.
    Record
    Alternative control, pointer action and result.

    Step 3 of 3

    ActionIf no alternative exists, verify whether the path or multipoint input is essential to the function rather than merely the chosen design.

    Expected result
    Only genuinely essential gestures are treated as exceptions; unresolved claims are escalated.
    Record
    Claimed essential purpose and evidence showing why a simple input cannot work.
    Previous step Final step
    Decide the result
    Pass when
    Functionality using multipoint or path-based gestures also works with a single pointer without a path-based gesture, unless the gesture is essential.
    Fail when
    A user must pinch, draw a path or perform another complex gesture with no simple alternative.
    Not applicable
    No multipoint or path-based author-defined gesture appears in the sample.
    Needs specialist review — execution status
    Escalate essentiality and unmodified user-agent or assistive-technology gestures. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.1 requirement

    WCAG 2.5.2 · Level A

    Pointer Cancellation
    Manual check — follow these steps in order

    Test with: Mouse or touch pointer, Cancellation and reversal review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionOn each single-pointer control, press down inside the target, move outside it and release without completing a click.

    Expected result
    The action does not complete on the down-event, or moving away aborts it before completion.
    Record
    Control, pointer sequence and any action triggered.

    Step 2 of 3

    ActionPress down outside a target, move onto it and release, then test drag, selection and drawing functions at their completion point.

    Expected result
    Controls do not activate unexpectedly, and functions that require a down-event complete on up-event or provide abort/undo behaviour where required.
    Record
    Sequence, completion event and cancellation method.

    Step 3 of 3

    ActionFor any action that completes on pointer down, immediately try to reverse or undo it and assess any claimed essential down-event exception.

    Expected result
    The result can be reversed before completion, undone after completion or is demonstrably essential.
    Record
    Action, reversal method, final state and exception evidence.
    Previous step Final step
    Decide the result
    Pass when
    Single-pointer functions avoid completion on down-event, can be aborted or undone, reverse an up-event action when appropriate, or document why down-event completion is essential.
    Fail when
    A destructive or consequential action completes immediately on pointer down with no qualifying recovery.
    Not applicable
    The selected target has no author-defined single-pointer operation.
    Needs specialist review — execution status
    Escalate drag-and-drop, freehand input and controls where down-event completion may be essential. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.2 requirement

    WCAG 2.5.4 · Level A

    Motion Actuation
    Manual check — follow these steps in order

    Test with: Real device or sensor emulation, Settings review, User-interface alternative.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory functions triggered by device motion or user motion detected by the device, such as shake, tilt, pan or camera-detected gesture.

    Expected result
    Every motion-actuated function and its trigger are identified.
    Record
    Function, required motion, device and state.

    Step 2 of 3

    ActionPerform the same function through an ordinary user-interface control without moving the device or user.

    Expected result
    A keyboard- and pointer-operable alternative provides the same result unless motion is essential or supported through an accessibility interface.
    Record
    Alternative control, operation and result.

    Step 3 of 3

    ActionFind and activate the method that prevents accidental motion activation, then repeat the motion.

    Expected result
    Users can disable response to motion while retaining the ordinary interface alternative, unless a documented exception applies.
    Record
    Setting, state before and after, retest result and exception evidence.
    Previous step Final step
    Decide the result
    Pass when
    Functionality triggered by device or user motion also works through interface controls, and motion triggering can be disabled, unless motion is essential or supported through an accessibility interface.
    Fail when
    A user must shake, tilt or gesture at the device with no control alternative or disable option.
    Not applicable
    No author-defined functionality responds to device or user motion.
    Needs specialist review — execution status
    Escalate camera-based gestures and motion whose purpose may be essential. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.4 requirement

    WCAG 2.5.7 · Level AA

    Dragging Movements
    Manual check — follow these steps in order

    Test with: Mouse or touch drag, Single-pointer alternative.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory operations that require dragging, including sliders, maps, reorder lists, splitters, drawing controls and drag-and-drop uploads.

    Expected result
    Every drag action and its final result are identified.
    Record
    Component, item moved or value changed, start point and end result.

    Step 2 of 3

    ActionComplete the same result with a single pointer without dragging, using controls such as buttons, menus, direct value entry or select-then-place.

    Expected result
    A non-dragging alternative performs the same function unless dragging is essential.
    Record
    Alternative method, actions and resulting state.

    Step 3 of 3

    ActionIf an alternative is absent, test keyboard operation and assess the claimed essential exception separately.

    Expected result
    Keyboard access is recorded under SC 2.1.1, while SC 2.5.7 passes only with a single-pointer non-drag alternative or a valid essential exception.
    Record
    Keyboard result, pointer alternative status and exception evidence.
    Previous step Final step
    Decide the result
    Pass when
    Any functionality using dragging can also be achieved by a single pointer without dragging, unless dragging is essential or the function is controlled by the user agent and not modified by the author.
    Fail when
    A user must drag an item and no button, selection or other non-drag alternative performs the same function.
    Not applicable
    No author-defined dragging movement appears in the sample.
    Needs specialist review — execution status
    Escalate maps, drawing tools and native controls where essentiality or author control is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.7 requirement

    WCAG 2.5.8 · Level AA

    Target Size (Minimum)
    Manual check — follow these steps in order

    Test with: Browser measurement, Responsive and state review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory pointer targets in each responsive layout and meaningful state, including icon controls, inline links, map markers and controls revealed on hover.

    Expected result
    Every author-sized target is included and inline, user-agent, equivalent, spacing and essential exceptions are identified for review.
    Record
    Target, state, viewport and possible exception.

    Step 2 of 3

    ActionMeasure the rendered target width and height in CSS pixels without relying on the visible icon size alone.

    Expected result
    Each target is at least 24 by 24 CSS pixels, or proceeds to the spacing/exception check.
    Record
    Target dimensions and measurement method.

    Step 3 of 3

    ActionFor each undersized target, centre a 24 CSS-pixel-diameter circle on its bounding box and compare it with every other target and with the same circle around every other undersized target.

    Expected result
    The circle does not intersect another target or another undersized target's circle, or the target meets the equivalent-control, inline, user-agent-control or essential exception.
    Record
    Target bounding box, circle or spacing measurement, neighbouring targets, exception and final result.
    Previous step Final step
    Decide the result
    Pass when
    Pointer targets are at least 24 by 24 CSS pixels, meet the criterion's exact non-overlapping 24 CSS-pixel spacing calculation, or qualify for the equivalent-control, inline, user-agent-control or essential exception.
    Fail when
    A target is smaller than 24 by 24 CSS pixels, fails the exact spacing calculation and has no applicable exception.
    Not applicable
    The selected target has no author-defined pointer target.
    Needs specialist review — execution status
    Escalate small inline links, overlapping target-spacing measurements and exception decisions. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.8 requirement

    Example targets

    • Carousel swipe, map pan and zoom, range sliders, draggable filter chips, save icons, pagination and small close buttons.

    Common mistakes

    • Testing only desktop mouse behaviour.
    • Failing every target below 24 pixels without evaluating spacing and other exceptions.
    • Treating operating-system gestures as author-defined website gestures.

    Back to test catalogue

    TC-11

    Form names, instructions and autocomplete

    Forms & journeys 3 guided steps · 4 criteria

    Confirm that form controls have understandable visible and programmatic labels, instructions and recognised input purposes.

    Who this affects: People using screen readers, speech input, memory support, autofill or alternative input.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on search, filters, registration, sign-in, account and multi-step forms.

    What you need

    • Accessibility-tree inspection and representative form data.

    What should happen

    • Each control exposes the correct name, role, state and value and has visible instructions where users need them.
    • The accessible name contains the visible label text, preferably at the beginning.
    • Supported fields use the correct programmatic input-purpose token, normally an appropriate autocomplete value.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInspect every input, select, checkbox, radio button and custom form control in each state.

    Expected result
    Each control exposes the correct name, role, state and value and has visible instructions where users need them.
    Evidence to save
    Visible label, accessible name, role and state.

    Step 2 of 3

    ActionFor controls with a visible text label, compare the visible words with the computed accessible name.

    Expected result
    The accessible name contains the visible label text, preferably at the beginning.
    Evidence to save
    Exact visible text and computed accessible name.

    Step 3 of 3

    ActionInspect fields collecting information about the user, such as name, email or telephone number.

    Expected result
    Supported fields use the correct programmatic input-purpose token, normally an appropriate autocomplete value.
    Evidence to save
    Field purpose and autocomplete value.
    Previous step Final step

    What to record

    • Visible label, accessible name, role and state.
    • Exact visible text and computed accessible name.
    • Field purpose and autocomplete value.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.3.5 · Level AA

    Identify Input Purpose
    Manual check — follow these steps in order

    Test with: Form inventory, Code or accessibility inspection, Browser autofill.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory fields that collect information about the user and map each field to the WCAG input-purpose list where a matching purpose exists.

    Expected result
    Applicable personal-information fields are distinguished from search, one-off domain data and fields about another person.
    Record
    Field label, purpose, ownership and applicable autocomplete token.

    Step 2 of 3

    ActionInspect the programmatic purpose or autocomplete value for every applicable field.

    Expected result
    Each field uses a valid token that matches the meaning of the requested information.
    Record
    Field element, visible label and actual autocomplete value.

    Step 3 of 3

    ActionAs a supporting check, use browser autofill on a representative form and verify the populated value categories before submission.

    Expected result
    Autofill behaviour is recorded as compatibility evidence only. Determine the WCAG result from whether each applicable input purpose can be programmatically determined; a browser choosing not to autofill is not by itself a failure.
    Record
    Browser, field, populated value category and any mismatch; do not save personal values.
    Previous step Final step
    Decide the result
    Pass when
    The purpose of fields collecting information about the user can be programmatically determined when the field has a purpose listed by WCAG and the technology supports identification.
    Fail when
    A qualifying personal-information field lacks or uses the wrong recognised input-purpose token.
    Not applicable
    The form collects no information about the user covered by WCAG's input-purpose list.
    Needs specialist review — execution status
    Escalate fields whose purpose or correct autocomplete token is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.3.5 requirement

    WCAG 2.5.3 · Level A

    Label in Name
    Manual check — follow these steps in order

    Test with: Visible-label inventory, Accessibility-tree inspection, Voice-input check where available.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory user-interface components with visible text or a visible text symbol as their label.

    Expected result
    Links, buttons, form controls, menu items and custom controls with visible wording are included.
    Record
    Control, visible label and state.

    Step 2 of 3

    ActionInspect the computed accessible name of each inventoried component and compare it with the visible wording.

    Expected result
    The accessible name contains the visible label words in the same order. Ignore ordinary differences in capitalisation, spacing and punctuation unless they change meaning; symbolic characters used as icons require separate interpretation.
    Record
    Visible label, computed name and missing, reordered or interspersed words.

    Step 3 of 3

    ActionWhere voice input is available, speak the visible label to operate representative controls.

    Expected result
    The visible wording identifies the intended control; failures are confirmed against the accessible-name comparison rather than voice software alone.
    Record
    Spoken command, selected target and computed-name evidence.
    Previous step Final step
    Decide the result
    Pass when
    For controls with visible text or an image-of-text label, the accessible name contains that visible text.
    Fail when
    The accessible name omits or replaces the words a speech-input user can see.
    Not applicable
    The selected control has no visible label containing text or images of text.
    Needs specialist review — execution status
    Escalate split labels, localisation or name computation that produces conflicting visible text. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.5.3 requirement

    WCAG 3.3.2 · Level A

    Labels or Instructions
    Manual check — follow these steps in order

    Test with: Form inventory, Keyboard, Accessibility-tree inspection.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionBefore entering data, inventory every input and the visible label, required indication, format, constraint and task instruction needed to use it.

    Expected result
    Users receive labels or instructions when content requires their input.
    Record
    Field, visible label and available instructions.

    Step 2 of 3

    ActionInspect each field's accessible name and description and compare them with the persistent visible information.

    Expected result
    Use programmatic association as supporting evidence for SC 1.3.1 and SC 4.1.2. For SC 3.3.2, determine whether a label or instruction is provided when the content requires user input; placeholder-only wording is not a reliable persistent label.
    Record
    Field, visible label or instruction, computed name or description and any missing association.

    Step 3 of 3

    ActionComplete the form without intentionally making an error, using keyboard and the provided instructions only.

    Expected result
    The required input, format and choice can be understood before submission.
    Record
    Field where guessing was required and the missing or unclear instruction.
    Previous step Final step
    Decide the result
    Pass when
    Labels or instructions are provided when content requires user input, including required formats and constraints needed before submission.
    Fail when
    A user must guess a field's purpose, required status, format or essential constraint.
    Not applicable
    The selected target requires no user input.
    Needs specialist review — execution status
    Escalate whether an instruction is necessary before input or only useful after an error. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.2 requirement

    WCAG 4.1.2 · Level A

    Name, Role, Value
    Manual check — follow these steps in order

    Test with: Accessibility tree, Keyboard, Screen reader.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory form controls, links, buttons and custom widgets in their default and changed states.

    Expected result
    Every user-interface component and its possible states are included in the semantic review.
    Record
    Component, implementation type and states.

    Step 2 of 3

    ActionInspect each component's computed name, role, value, state and programmatic relationships before and after interaction.

    Expected result
    Assistive technology can determine the component's identity and current state, and user-settable changes update programmatically.
    Record
    Visible label/state and computed properties before and after.

    Step 3 of 3

    ActionOperate representative native and every custom component with keyboard and a screen reader.

    Expected result
    The announced role and interaction match the visible component, and state or value changes are communicated accurately.
    Record
    Keys, announcements, actual change and first missing or incorrect property.
    Previous step Final step
    Decide the result
    Pass when
    For every user-interface component, name and role can be programmatically determined; user-settable states, properties and values can be programmatically set; and changes are available to user agents and assistive technologies.
    Fail when
    A component has a missing or wrong name or role, or its current state/value is not exposed or updated.
    Not applicable
    The selected target contains no user-interface component.
    Needs specialist review — execution status
    Escalate custom widgets, shadow DOM, third-party components and conflicting accessibility-tree results. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 4.1.2 requirement

    Example targets

    • Keyword and location search, autocomplete suggestions, range selectors, filter checkboxes, email subscription, account fields and submit controls.

    Common mistakes

    • Using placeholder text as the only label.
    • Checking the HTML label but not the computed accessible name.
    • Adding autocomplete to organisation-specific fields that are not about the user.

    Back to test catalogue

    TC-12

    Form errors, unexpected changes and status messages

    Forms & journeys 3 guided steps · 5 criteria

    Confirm that forms do not change context unexpectedly and that errors and status updates are visible, specific and programmatically available.

    Who this affects: People using screen readers, magnification, keyboard navigation or cognitive support.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on search, filters, autocomplete, subscriptions, sign-in and application forms, including invalid, loading, empty and success states.

    What you need

    • Known invalid and valid test data and a screen reader or accessibility-tree/live-region inspection method.

    What should happen

    • Receiving focus does not cause a change of context. Changing a setting does not cause a change of context unless the user was advised of that behaviour before using the control.
    • Automatically detected errors identify the field and describe the error in text; known correction suggestions are provided unless doing so would harm security or purpose.
    • Status messages are exposed by role or properties so assistive technology can present them without receiving focus.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionMove focus through controls without changing values, then change each relevant value without pressing a submit button.

    Expected result
    Receiving focus does not cause a change of context. Changing a setting does not cause a change of context unless the user was advised of that behaviour before using the control.
    Evidence to save
    Control, focus or input action, prior instruction and unexpected navigation, focus change or major content change.

    Step 2 of 3

    ActionSubmit empty, malformed and conflicting values.

    Expected result
    Automatically detected errors identify the field and describe the error in text; known correction suggestions are provided unless doing so would harm security or purpose.
    Evidence to save
    Entered value, submitted state, error text and association.

    Step 3 of 3

    ActionTrigger loading, result counts, saved-item confirmation, errors and successful submission without moving focus.

    Expected result
    Status messages are exposed by role or properties so assistive technology can present them without receiving focus.
    Evidence to save
    Trigger, visual message, role or properties and screen-reader observation where tested.
    Previous step Final step

    What to record

    • Control, focus or input action, prior instruction and unexpected navigation, focus change or major content change.
    • Entered value, submitted state, error text and association.
    • Trigger, visual message, role or properties and screen-reader observation where tested.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 3.2.1 · Level A

    On Focus
    Manual check — follow these steps in order

    Test with: Keyboard focus review, Forward and reverse navigation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionUse Tab, Shift+Tab and component arrow keys to move focus onto every interactive component without activating it.

    Expected result
    Receiving focus alone does not submit data, open an unrelated window, navigate, move focus elsewhere or make another unexpected context change.
    Record
    Component, focus key and any event triggered on focus.

    Step 2 of 3

    ActionRepeat after validation, filtering, responsive changes and dynamic content updates.

    Expected result
    State-specific controls remain stable when they merely receive focus.
    Record
    State, focused control and context before and after.

    Step 3 of 3

    ActionIf any component changes context when it receives focus, repeat the test and confirm that focus alone caused the change.

    Expected result
    A change of context caused by focus fails SC 3.2.1. Prior warning does not create an exception for this criterion; warning is relevant to changes caused by input under SC 3.2.2.
    Record
    Component, focus action, context before and after and any prior warning.
    Previous step Final step
    Decide the result
    Pass when
    Receiving focus does not initiate a change of context.
    Fail when
    Tabbing to a control submits, opens a new page, moves focus unexpectedly or causes another major context change.
    Not applicable
    The selected target contains no component capable of receiving focus.
    Needs specialist review — execution status
    Escalate whether a change qualifies as a change of context rather than a local content update. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.2.1 requirement

    WCAG 3.2.2 · Level A

    On Input
    Manual check — follow these steps in order

    Test with: Form and control input review, Keyboard and pointer.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory controls where changing a value can update content, submit data, navigate, open a window or move focus.

    Expected result
    Selects, radio buttons, checkboxes, text fields and custom inputs with change behaviour are included.
    Record
    Control, input action and possible context change.

    Step 2 of 3

    ActionChange each value without activating a separate submit or continue control.

    Expected result
    Input alone does not cause an unexpected change of context; ordinary content updates that preserve context are distinguished from navigation or focus changes.
    Record
    Value before and after, focus location and resulting change.

    Step 3 of 3

    ActionWhere changing input intentionally changes context, check for instructions provided before the control and repeat with keyboard.

    Expected result
    Users are advised in advance and can understand the consequence before changing the setting.
    Record
    Instruction text, reading/focus order and keyboard result.
    Previous step Final step
    Decide the result
    Pass when
    Changing a control's setting does not automatically cause a change of context unless the user was advised before using it.
    Fail when
    Selecting or typing a value unexpectedly navigates, submits or substantially changes context with no prior advice.
    Not applicable
    The selected target contains no user-interface control whose setting can change.
    Needs specialist review — execution status
    Escalate dynamic filtering or route updates whose context impact is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.2.2 requirement

    WCAG 3.3.1 · Level A

    Error Identification
    Manual check — follow these steps in order

    Test with: Invalid form submission, Keyboard, Screen reader.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionFor each form, submit with required fields empty and then with representative invalid formats, values and combinations.

    Expected result
    Every detectable input error is triggered and available for review.
    Record
    Field, input used, submit action and resulting state.

    Step 2 of 3

    ActionReview the visible error summary, inline messages, icons and field states without relying on colour.

    Expected result
    Text identifies that an error occurred and identifies the specific item in error.
    Record
    Exact error text, affected field and any colour-only indication.

    Step 3 of 3

    ActionNavigate the errors with keyboard and screen reader and inspect each error-to-field association.

    Expected result
    Users are alerted to the errors and can determine which field each message describes.
    Record
    Announcement, focus path, programmatic relationship and first unassociated error.
    Previous step Final step
    Decide the result
    Pass when
    Automatically detected input errors identify the item in error and describe the error in text.
    Fail when
    An error is shown only by colour or icon, is generic, or is not associated clearly with the affected input.
    Not applicable
    The selected input has no automatically detected error condition in the tested scope.
    Needs specialist review — execution status
    Escalate server-side rejection that cannot be reproduced safely. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.1 requirement

    WCAG 3.3.3 · Level AA

    Error Suggestion
    Manual check — follow these steps in order

    Test with: Invalid form submission, Error-message review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionEnter values with known corrections, such as an invalid date, unavailable choice, malformed email or value outside an allowed range.

    Expected result
    The system detects representative errors for which a correction can be known.
    Record
    Field, invalid value pattern and detected error.

    Step 2 of 3

    ActionRead the associated error and identify whether it states how to correct the problem or provides valid options.

    Expected result
    A specific correction suggestion is provided when known, unless it would jeopardize security or the purpose of the content.
    Record
    Exact error text and the correction information provided or missing.

    Step 3 of 3

    ActionFollow the suggestion using keyboard and resubmit.

    Expected result
    The suggestion is accurate, usable and resolves the stated error without introducing a different ambiguity.
    Record
    Correction entered, resubmit result and any misleading guidance.
    Previous step Final step
    Decide the result
    Pass when
    When correction suggestions are known, they are provided unless they would jeopardise security or purpose.
    Fail when
    The system knows the required correction but reports only that an error occurred.
    Not applicable
    No automatically detected error has a known safe correction suggestion.
    Needs specialist review — execution status
    Escalate security-sensitive fields or suggestions whose safety is disputed. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.3 requirement

    WCAG 4.1.3 · Level AA

    Status Messages
    Manual check — follow these steps in order

    Test with: Screen reader, Dynamic-state review, Accessibility-tree inspection.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionTrigger status messages that report success, results, loading, progress, cart changes, validation or errors without taking focus.

    Expected result
    All non-modal messages that meet the WCAG status-message definition are identified.
    Record
    Trigger, visible message, focus position and message purpose.

    Step 2 of 3

    ActionKeep keyboard focus on the initiating control and listen with a screen reader that supports the implemented status semantics as each status appears or changes.

    Expected result
    Use the announcement as compatibility evidence. A qualifying status can be presented without receiving focus; one screen reader's silence is not by itself enough to assign the WCAG result.
    Record
    Focus before and after, screen reader, exact announcement and timing.

    Step 3 of 3

    ActionInspect the message role or properties and repeat rapid, repeated and error states.

    Expected result
    The role or properties allow assistive technology to determine and present the status without receiving focus. Record disruptive or duplicate announcements as usability or compatibility findings unless another success criterion is failed.
    Record
    Role or properties, update sequence and missing, repeated or interruptive announcement.
    Previous step Final step
    Decide the result
    Pass when
    Qualifying status messages can be programmatically determined through role or properties and presented by assistive technology without receiving focus.
    Fail when
    A result count, progress, success or error status appears visually but is not exposed, or unnecessary focus movement is the only announcement method.
    Not applicable
    No content change in the completed sample meets the definition of a status message.
    Needs specialist review — execution status
    Escalate uncertainty about whether content is a status message or a change of context. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 4.1.3 requirement

    Example targets

    • Search autocomplete, filter result count, no-results message, saved-item confirmation, registration validation and submission status.

    Common mistakes

    • Moving focus to every status message instead of using appropriate status semantics.
    • Checking error text but not its association with the field.
    • Treating every dynamic update as a prohibited context change.

    Back to test catalogue

    TC-13

    Timeouts, repeated data and authentication

    Forms & journeys 4 guided steps · 4 criteria

    Confirm that users can extend time, avoid re-entering information and complete authentication without unnecessary cognitive tests.

    Who this affects: People who need more time, have memory or cognitive disabilities, use assistive technology or experience interruptions.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on sign-in, account settings, registration, multi-step forms, assessments and sessions with inactivity limits.

    What you need

    • A safe test account when authentication is in scope and knowledge of configured time limits.

    What should happen

    • The user can turn off, adjust or extend the limit as required, or a documented WCAG exception applies.
    • Previously entered information is auto-populated or available for selection unless re-entry is essential, needed for security or no longer valid.
    • No cognitive-function test is required unless a qualifying alternative, assistance mechanism, object recognition or personal-content exception is provided.
    • The action is reversible, checked for input errors, or confirmed after a review opportunity.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 4

    ActionIdentify each content-controlled time limit and approach expiry without completing the task.

    Expected result
    The user can turn off, adjust or extend the limit as required, or a documented WCAG exception applies.
    Evidence to save
    Limit, warning time, available action and preserved data.

    Step 2 of 4

    ActionComplete a multi-step process that requests the same information more than once.

    Expected result
    Previously entered information is auto-populated or available for selection unless re-entry is essential, needed for security or no longer valid.
    Evidence to save
    Repeated field, earlier value and available reuse method.

    Step 3 of 4

    ActionComplete authentication using password-manager paste and available alternatives.

    Expected result
    No cognitive-function test is required unless a qualifying alternative, assistance mechanism, object recognition or personal-content exception is provided.
    Evidence to save
    Authentication step, blocked action and available alternative.

    Step 4 of 4

    ActionBefore a legal, financial, test-response or user-controlled data submission, attempt to review and correct the information.

    Expected result
    The action is reversible, checked for input errors, or confirmed after a review opportunity.
    Evidence to save
    Consequential action and prevention method.
    Previous step Final step

    What to record

    • Limit, warning time, available action and preserved data.
    • Repeated field, earlier value and available reuse method.
    • Authentication step, blocked action and available alternative.
    • Consequential action and prevention method.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 2.2.1 · Level A

    Timing Adjustable
    Manual check — follow these steps in order

    Test with: Timed observation, Keyboard, Session warning review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory session, page, form, reading and inactivity time limits and identify which limits are controlled by the content.

    Expected result
    The duration, trigger and consequence of every applicable time limit are known before testing.
    Record
    Limit, duration, trigger, consequence and any claimed real-time, essential or over-20-hour exception.

    Step 2 of 3

    ActionBefore each limit begins, look for a method to turn it off or adjust it to at least ten times the default where WCAG permits these options.

    Expected result
    A permitted control is available before the user encounters the limit, unless an exception applies.
    Record
    Setting, available range, keyboard result and exception evidence.

    Step 3 of 3

    ActionAllow the limit warning to appear and use the extension control repeatedly.

    Expected result
    The warning provides at least 20 seconds for a simple action and permits extension at least ten times unless a documented exception applies.
    Record
    Warning time, action required, extension count and retained data or session state.
    Previous step Final step
    Decide the result
    Pass when
    Before encountering each content-set time limit, the user can turn it off or adjust it over a range at least ten times the default; or the user receives at least 20 seconds to extend it with a simple action and can extend it at least ten times. A documented real-time, essential or longer-than-20-hours exception may apply.
    Fail when
    A user loses the task or data because a content-controlled time limit lacks the required turn-off, adjustment or extension route and no exception applies.
    Not applicable
    No content-controlled time limit exists in the completed sample.
    Needs specialist review — execution status
    Escalate real-time events, security timeouts, auctions, assessments and claims that timing is essential. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.2.1 requirement

    WCAG 3.3.4 · Level AA

    Error Prevention (Legal, Financial, Data)
    Manual check — follow these steps in order

    Test with: End-to-end submission, Review, correction and reversal review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify submissions that create legal commitments, financial transactions, changes to user-controlled data or test responses.

    Expected result
    Only transactions within the criterion's scope proceed to error-prevention testing.
    Record
    Process, submission consequence and data affected.

    Step 2 of 3

    ActionComplete the process with a deliberate but safe error and inspect all review, validation and confirmation stages before final submission.

    Expected result
    At least one permitted safeguard is available: the submission is reversible; entered data is checked and can be corrected; or the information can be reviewed, confirmed and corrected before finalising.
    Record
    Input, review screen, detected error, correction path and safeguard used.

    Step 3 of 3

    ActionAfter safe test submission, attempt the documented reversal or correction route where that route is the provided safeguard.

    Expected result
    At least one permitted safeguard—reversible submission, checked/correctable data, or review/confirmation—works for the complete process.
    Record
    Safeguard used, time limit if any and final state; never use a real transaction.
    Previous step Final step
    Decide the result
    Pass when
    A qualifying legal, financial, test-response or user-controlled data action is reversible, checked for input errors with an opportunity to correct them, or reviewed, confirmed and correctable before finalisation.
    Fail when
    A qualifying consequential submission becomes final with no reversal, input check and correction opportunity, or review-and-confirm route.
    Not applicable
    The completed process performs none of the transactions or data changes named by the criterion.
    Needs specialist review — execution status
    Escalate whether a submission, assessment response or account-data change meets the criterion's legal, data or test-response scope. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.4 requirement

    WCAG 3.3.7 · Level A

    Redundant Entry
    Manual check — follow these steps in order

    Test with: End-to-end process, Repeated-information inventory.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionComplete a multi-step process with safe data and record every item of information entered by the user.

    Expected result
    A reference list exists for identifying repeated requests within the same process.
    Record
    Step, field label and non-sensitive description of entered information.

    Step 2 of 3

    ActionContinue through the process and identify any request for information already supplied during that process.

    Expected result
    Repeated requests are distinguished from confirmation, security-essential re-entry and information that is no longer valid.
    Record
    Original field, repeated field and reason given for repetition.

    Step 3 of 3

    ActionAt each non-exempt repeated request, use the available prepopulation or selection method.

    Expected result
    Previously supplied information is automatically populated or available for selection without retyping.
    Record
    Reuse method, keyboard result and any data that had to be entered again.
    Previous step Final step
    Decide the result
    Pass when
    Information previously entered by or provided to the user in the same process is auto-populated or available for selection, unless re-entry is essential, required for security or the information is no longer valid.
    Fail when
    A user must type the same valid information again in one process with no qualifying reason.
    Not applicable
    The process does not request previously entered or provided information again.
    Needs specialist review — execution status
    Escalate security confirmation and fields whose apparent duplication may serve a distinct purpose. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.7 requirement

    WCAG 3.3.8 · Level AA

    Accessible Authentication (Minimum)
    Manual check — follow these steps in order

    Test with: Authentication flow, Password manager and paste, Alternative-method review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory every cognitive task required for authentication, including remembering/transcribing secrets, solving problems, recognizing objects or reproducing non-text content.

    Expected result
    Each authentication step and any permitted exception mechanism can be assessed separately.
    Record
    Step, requested cognitive task and available alternatives.

    Step 2 of 3

    ActionUse password-manager autofill and copy/paste for passwords and one-time codes, including codes received on another device where safe.

    Expected result
    The flow does not block mechanisms that reduce memory and transcription demands.
    Record
    Method, field, blocked action and actual result; do not record credentials or codes.

    Step 3 of 3

    ActionFor puzzles, object recognition or transcription tasks, use a non-cognitive alternative, an assisting mechanism or authentication based on user-provided content.

    Expected result
    Authentication can be completed without a prohibited cognitive-function test unless a WCAG exception applies.
    Record
    Challenge, alternative or mechanism, completion result and exception evidence.
    Previous step Final step
    Decide the result
    Pass when
    Authentication does not require a cognitive-function test unless another method, an assistance mechanism, object recognition or personal content provides a qualifying route.
    Fail when
    Authentication requires memory, transcription, calculation or puzzle solving and blocks password managers or other qualifying alternatives.
    Not applicable
    No authentication process appears in the completed scope.
    Needs specialist review — execution status
    Escalate CAPTCHA, one-time codes, security restrictions and whether an alternative meets the criterion. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 3.3.8 requirement

    Example targets

    • Sign-in, account editing, saved items, multi-step submissions, assessments, session expiry and registration.

    Common mistakes

    • Failing every security timeout without evaluating exceptions.
    • Treating confirmation of critical information as automatically redundant.
    • Testing authentication without trying paste or a password manager.

    Back to test catalogue

    TC-14

    Automatic audio and moving content

    Media & motion 2 guided steps · 2 criteria

    Confirm that users can control automatic sound, movement, blinking, scrolling and updates.

    Who this affects: Screen-reader users, people with attention, vestibular or cognitive disabilities and people who need more time to read.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run when audio starts automatically or content moves, blinks, scrolls or updates automatically.

    What you need

    • A clean session that has not stored media preferences.

    What should happen

    • Audio lasting more than three seconds has an independent pause/stop control or an independent volume control.
    • Qualifying movement can be paused, stopped or hidden, and qualifying auto-updates can be paused, stopped, hidden or have their update frequency controlled, unless essential.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 2

    ActionLoad the page and listen for audio that starts without user action.

    Expected result
    Audio lasting more than three seconds has an independent pause/stop control or an independent volume control.
    Evidence to save
    Audio source, duration and control.

    Step 2 of 2

    ActionObserve carousels, video backgrounds, animations, tickers, result refreshes and other moving or updating content for more than five seconds.

    Expected result
    Qualifying movement can be paused, stopped or hidden, and qualifying auto-updates can be paused, stopped, hidden or have their update frequency controlled, unless essential.
    Evidence to save
    Content, start behaviour, duration and control.
    Previous step Final step

    What to record

    • Audio source, duration and control.
    • Content, start behaviour, duration and control.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.4.2 · Level A

    Audio Control
    Manual check — follow these steps in order

    Test with: Page-load observation, Keyboard operation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionReload the page and listen for audio that begins without a user request; time any automatic audio that continues.

    Expected result
    Every automatic sound is identified and its duration is known.
    Record
    Page, audio source, start behaviour and duration.

    Step 2 of 3

    ActionFor automatic audio lasting more than three seconds, locate the pause, stop or independent volume control.

    Expected result
    A control is available near the start of the interaction and does not depend on changing the system volume.
    Record
    Control name, location and whether it is keyboard reachable.

    Step 3 of 3

    ActionUse the control with the keyboard and confirm the audio stops, pauses or becomes independently adjustable.

    Expected result
    The control works before the audio prevents users from hearing assistive-technology output.
    Record
    Key used, control state and audio result.
    Previous step Final step
    Decide the result
    Pass when
    Audio that starts automatically and plays for more than three seconds can be paused or stopped, or its volume can be controlled independently of the overall system volume.
    Fail when
    Automatic audio lasts more than three seconds with no qualifying control.
    Not applicable
    No audio starts automatically, or automatic audio does not exceed three seconds.
    Needs specialist review — execution status
    Escalate multiple simultaneous audio sources or controls whose independence is unclear. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.4.2 requirement

    WCAG 2.2.2 · Level A

    Pause, Stop, Hide
    Manual check — follow these steps in order

    Test with: Timed visual observation, Keyboard operation.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionObserve the page for at least long enough to identify automatic moving, blinking, scrolling and updating content, and record when each item starts and how long it continues.

    Expected result
    All content that starts automatically, appears with other content and may meet the timing conditions is inventoried.
    Record
    Item, behaviour, start time, duration and update frequency.

    Step 2 of 3

    ActionFor movement lasting more than five seconds, use the available keyboard control to pause, stop or hide it.

    Expected result
    Applicable movement stops and remains stopped unless it is essential to the activity.
    Record
    Control name, key, stopped content and any claimed essential exception.

    Step 3 of 3

    ActionFor automatic updates, use the control to pause, stop, hide or change the update frequency, then interact with the remaining page.

    Expected result
    Applicable updates are under user control and paused content does not restart unexpectedly.
    Record
    Control used, selected frequency or state and restart behaviour.
    Previous step Final step
    Decide the result
    Pass when
    Automatically started moving, blinking or scrolling content lasting more than five seconds and presented alongside other content can be paused, stopped or hidden; auto-updating content can be paused, stopped, hidden or have its frequency controlled, unless essential.
    Fail when
    Qualifying movement or updates continue with no required user control.
    Not applicable
    No content matches the criterion's automatic start, duration, parallel presentation or updating conditions.
    Needs specialist review — execution status
    Escalate live feeds, progress indicators and content claimed to be essential. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.2.2 requirement

    Example targets

    • Background video, carousel, animated statistics, live result counts and automatically rotating featured content.

    Common mistakes

    • Failing a short transition that ends within five seconds.
    • Assuming reduced-motion support alone satisfies the pause requirement.
    • Testing after a stored preference already stopped the content.

    Back to test catalogue

    TC-15

    Prerecorded audio and video

    Media & motion 3 guided steps · 4 criteria

    Confirm that prerecorded media has accurate alternatives for speech, sounds and important visual information.

    Who this affects: Deaf and hard-of-hearing people, blind and low-vision people and people who cannot play audio or video.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on every prerecorded audio-only, video-only and synchronised media item in the sample.

    What you need

    • Access to captions, transcripts, audio description and the complete media item.

    What should happen

    • The applicable media branch is documented. The media-alternative-for-text exception applies to SC 1.2.1, 1.2.2 and 1.2.3, but not to SC 1.2.5.
    • Prerecorded synchronised media has accurate, synchronised captions unless it is a clearly labelled media alternative for text.
    • The applicable Level A and Level AA visual-information alternatives are present and equivalent.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionClassify the item as audio-only, video-only or synchronised media, and identify whether it is itself a clearly labelled media alternative for text.

    Expected result
    The applicable media branch is documented. The media-alternative-for-text exception applies to SC 1.2.1, 1.2.2 and 1.2.3, but not to SC 1.2.5.
    Evidence to save
    Media URL, duration, classification and any applicable exception.

    Step 2 of 3

    ActionPlay the full item with captions enabled and compare captions with speech, speaker changes and important sounds.

    Expected result
    Prerecorded synchronised media has accurate, synchronised captions unless it is a clearly labelled media alternative for text.
    Evidence to save
    Timestamp and missing or inaccurate caption.

    Step 3 of 3

    ActionReview the transcript, media alternative or audio description against important visual information.

    Expected result
    The applicable Level A and Level AA visual-information alternatives are present and equivalent.
    Evidence to save
    Timestamp, visual information and available alternative.
    Previous step Final step

    What to record

    • Media URL, duration, classification and any applicable exception.
    • Timestamp and missing or inaccurate caption.
    • Timestamp, visual information and available alternative.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.2.1 · Level A

    Audio-only and Video-only (Prerecorded)
    Manual check — follow these steps in order

    Test with: Media review, Transcript comparison.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify each prerecorded audio-only and video-only item and confirm whether it is itself a clearly labelled alternative for text.

    Expected result
    Every applicable item is classified correctly before an alternative is assessed.
    Record
    Media URL, type, duration and alternative-for-text status.

    Step 2 of 3

    ActionFor audio-only content, listen to the complete recording while reading its transcript or equivalent alternative.

    Expected result
    The alternative includes all speech, speaker identification and important non-speech audio needed to convey equivalent information.
    Record
    Timestamp and exact omitted, inaccurate or out-of-order information.

    Step 3 of 3

    ActionFor video-only content, watch the complete recording while reviewing its text alternative or audio track.

    Expected result
    The alternative communicates the actions, people, settings, on-screen text and visual changes needed to provide equivalent information.
    Record
    Timestamp, visual information and the corresponding alternative.
    Previous step Final step
    Decide the result
    Pass when
    Prerecorded audio-only content has an equivalent time-based media alternative, and prerecorded video-only content has an equivalent time-based media alternative or audio track, unless the media is a clearly labelled text alternative.
    Fail when
    Applicable audio-only or video-only content lacks the required equivalent.
    Not applicable
    The completed sample contains no prerecorded audio-only or video-only content, or the item is a qualifying text alternative.
    Needs specialist review — execution status
    Escalate whether an alternative conveys equivalent information and purpose. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.2.1 requirement

    WCAG 1.2.2 · Level A

    Captions (Prerecorded)
    Manual check — follow these steps in order

    Test with: Complete media playback, Caption review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify every prerecorded video with synchronized audio and enable closed captions where they are not always visible.

    Expected result
    Captions are provided unless the media is a clearly labelled media alternative for text. If the caption control cannot be operated, also record that issue under SC 2.1.1 and SC 4.1.2.
    Record
    Media URL, media-alternative status, caption-control name and enabled state.

    Step 2 of 3

    ActionPlay the complete media and compare captions with all speech, speakers and important sounds.

    Expected result
    Captions accurately communicate spoken content, identify speakers when needed and include meaningful sounds.
    Record
    Timestamp, spoken or audible content and the caption shown.

    Step 3 of 3

    ActionCheck caption timing, order, readability and continued availability after seek, pause, full-screen and responsive changes.

    Expected result
    Captions are synchronized closely enough to follow, remain readable and do not disappear during supported player states.
    Record
    Player state, timestamp and any timing, clipping or availability problem.
    Previous step Final step
    Decide the result
    Pass when
    Captions are provided for all prerecorded audio in synchronised media, except when the media is a clearly labelled text alternative.
    Fail when
    Captions are absent, materially inaccurate, omit important sounds or are not synchronised.
    Not applicable
    The completed sample has no prerecorded synchronised media with audio, or the media is a qualifying text alternative.
    Needs specialist review — execution status
    Escalate caption-quality judgements in unfamiliar languages or specialist terminology. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.2.2 requirement

    WCAG 1.2.3 · Level A

    Audio Description or Media Alternative (Prerecorded)
    Manual check — follow these steps in order

    Test with: Media review, Audio-description or text-alternative comparison.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionIdentify each applicable prerecorded synchronized video and locate its audio description or complete media alternative.

    Expected result
    At least one permitted alternative is available unless the video is a clearly labelled alternative for text.
    Record
    Media URL, alternative type and how it is reached.

    Step 2 of 3

    ActionWatch the complete video and list important visual information not already provided in the main soundtrack.

    Expected result
    Actions, people, scene changes, on-screen text and other visuals needed to understand the content are identified for comparison.
    Record
    Timestamp and each material visual detail not present in the main audio.

    Step 3 of 3

    ActionCompare the identified visual details with the audio description or media alternative from start to finish.

    Expected result
    The provided alternative communicates the material visual information in a usable sequence.
    Record
    Timestamp, expected information and the exact omission or mismatch.
    Previous step Final step
    Decide the result
    Pass when
    Prerecorded synchronised video has either an equivalent time-based media alternative or audio description for important visual information, unless it is a qualifying text alternative.
    Fail when
    Important visual information is unavailable through either permitted alternative.
    Not applicable
    There is no prerecorded synchronised video requiring visual-information alternatives, or the media is a qualifying text alternative.
    Needs specialist review — execution status
    Escalate equivalence and whether existing dialogue already conveys the visual information. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.2.3 requirement

    WCAG 1.2.5 · Level AA

    Audio Description (Prerecorded)
    Manual check — follow these steps in order

    Test with: Complete media playback, Audio-description comparison.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionLocate and enable the audio-description version or track for each prerecorded video in synchronized media.

    Expected result
    Audio description is provided for important visual information that is not already conveyed in the main soundtrack. The media-alternative-for-text exception does not apply to SC 1.2.5. Record an inoperable control separately under SC 2.1.1 and SC 4.1.2.
    Record
    Media URL, control or alternative version, activation result and information already available in the main soundtrack.

    Step 2 of 3

    ActionPlay the complete video and note important visual information that is not already spoken in the main soundtrack.

    Expected result
    Material actions, characters, scene changes, on-screen text and other visual information are identified for comparison.
    Record
    Timestamp and each material visual detail.

    Step 3 of 3

    ActionListen to the audio description without watching the screen and compare it with the identified visual details.

    Expected result
    The description communicates the necessary visual information at an appropriate time without making the main audio unusable.
    Record
    Timestamp, description heard and any missing, late or conflicting information.
    Previous step Final step
    Decide the result
    Pass when
    Important visual information in prerecorded synchronised video is provided through audio description or is already available in the main soundtrack.
    Fail when
    Important visual information in applicable prerecorded synchronised media is not available through the main soundtrack or audio description.
    Not applicable
    The completed sample contains no prerecorded video content in synchronised media. Being a media alternative for text is not an exception to SC 1.2.5.
    Needs specialist review — execution status
    Escalate whether an audio description is complete, accurately timed and needed. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.2.5 requirement

    Example targets

    • Training videos, recorded presentations, demonstrations, interviews and recorded events.

    Common mistakes

    • Treating automatically generated captions as passed without checking accuracy.
    • Using a dialogue transcript as proof that visual information is covered.
    • Combining Level A 1.2.3 and Level AA 1.2.5 into one result.

    Back to test catalogue

    TC-16

    Live media captions

    Media & motion 1 guided step · 1 criterion

    Confirm that live synchronised media provides accurate captions.

    Who this affects: Deaf and hard-of-hearing people and anyone who cannot use the audio stream.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on live webinars, meetings, presentations or broadcasts containing synchronised audio and video.

    What you need

    • Access to the live event or an authorised rehearsal using the same captioning arrangement.

    What should happen

    • Captions are present, identify meaningful speakers and sounds, and are accurate and timely enough to follow the event.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 1

    ActionJoin the live event with captions enabled and observe representative speech, names, numbers and important sounds.

    Expected result
    Captions are present, identify meaningful speakers and sounds, and are accurate and timely enough to follow the event.
    Evidence to save
    Event, platform, timestamp and representative caption observations.
    Final step

    What to record

    • Event, platform, timestamp and representative caption observations.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 1.2.4 · Level AA

    Captions (Live)
    Manual check — follow these steps in order

    Test with: Live-session observation, Caption review.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionBefore an in-scope live synchronized broadcast begins, verify that live captions are scheduled and available to viewers.

    Expected result
    An operational caption method is present for the live audio content.
    Record
    Broadcast, caption method, language and how captions are enabled.

    Step 2 of 3

    ActionDuring the broadcast, observe representative segments containing ordinary speech, names, numbers, speaker changes and important sounds.

    Expected result
    Captions appear for the live audio and communicate material content with usable delay and accuracy.
    Record
    Observation time, spoken content, displayed caption and delay or material error.

    Step 3 of 3

    ActionCheck captions through player state changes such as full-screen, layout changes and reconnecting where these are supported.

    Expected result
    Captions remain available, readable and associated with the correct live content.
    Record
    Player state and any loss, clipping or incorrect association.
    Previous step Final step
    Decide the result
    Pass when
    Captions are provided for all live audio content in synchronised media.
    Fail when
    Applicable live synchronised media has no captions or captions are materially unusable.
    Not applicable
    The completed scope contains no live synchronised media with audio.
    Needs specialist review — execution status
    Escalate caption accuracy in unfamiliar languages, specialist terminology and high-risk live events. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 1.2.4 requirement

    Example targets

    • Live webinars, streamed events, presentations and live question-and-answer sessions.

    Common mistakes

    • Testing a recording instead of the live caption service.
    • Checking only that a caption button exists.

    Back to test catalogue

    TC-17

    Flashing content

    Media & motion 2 guided steps · 1 criterion

    Identify content that may flash more than three times per second and route it for objective analysis.

    Who this affects: People with photosensitive seizure disorders and people who experience physical reactions to flashing content.

    Covered success criteria

    Record every criterion separately

    A grouped test does not have one overall result. Record Pass, Fail or Not applicable for each completed criterion. If testing is incomplete, record its execution status without assigning a criterion outcome.

    When to use this test

    • Run on animation, video, advertising, transitions, loading effects and user-generated media that may flash.

    What you need

    • A safe preview and an approved flash-analysis tool operated by a trained reviewer when flashing is suspected.

    What should happen

    • Suspected content is paused and sent for objective analysis rather than judged by eye.
    • Content does not flash more than three times in any one-second period, or the combined flash is below the general and red-flash thresholds.

    How to test it — follow these steps in order

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 2

    ActionReview the inventory for rapid light-dark or saturated-red changes; do not repeatedly watch suspected flashing content.

    Expected result
    Suspected content is paused and sent for objective analysis rather than judged by eye.
    Evidence to save
    Content identifier, timestamp range and reason for escalation.

    Step 2 of 2

    ActionAnalyse suspected content with an approved photosensitive-epilepsy analysis method.

    Expected result
    Content does not flash more than three times in any one-second period, or the combined flash is below the general and red-flash thresholds.
    Evidence to save
    Tool, version, source file, analysed interval and report.
    Previous step Final step

    What to record

    • Content identifier, timestamp range and reason for escalation.
    • Tool, version, source file, analysed interval and report.

    Decide each WCAG result

    Use the completed target inventory and evidence. A failure on one applicable target prevents a pass for that criterion in the tested sample.

    WCAG 2.3.1 · Level A

    Three Flashes or Below Threshold
    Manual check — follow these steps in order

    Test with: Timed media review, Flash-analysis tool, Specialist review when needed.

    Choose a numbered step. Use Left and Right Arrow keys when the tabs have focus.

    Step 1 of 3

    ActionInventory animations, video, transitions, advertisements, game effects and other content that flashes or changes rapidly.

    Expected result
    Every possible flash source and its complete duration are identified before a result is assigned.
    Record
    Source, state that triggers it, duration and captured media where safe.

    Step 2 of 3

    ActionReview the content frame by frame or at reduced playback speed to identify any period containing more than three flashes in one second.

    Expected result
    Content with no period above three flashes per second can be distinguished from content requiring threshold analysis.
    Record
    Timestamp, one-second interval and observed flash count.

    Step 3 of 3

    ActionIf a period exceeds three flashes, analyse the general-flash and red-flash thresholds with an appropriate tool or escalate rather than estimating visually.

    Expected result
    A pass is recorded only when the measured flashes are below the applicable thresholds; unresolved content receives specialist review.
    Record
    Tool, input file, analysis result and reviewer or limitation.
    Previous step Final step
    Decide the result
    Pass when
    The page contains nothing that flashes more than three times in any one-second period, or the flash is below the general and red-flash thresholds.
    Fail when
    Objective analysis finds an applicable flash above the frequency and threshold limits.
    Not applicable
    The completed inventory contains no flashing content.
    Needs specialist review — execution status
    Always escalate suspected flashing for objective analysis; novice visual judgement is not sufficient for a pass. Do not assign a completed criterion outcome until the review is resolved.

    Read the normative WCAG 2.3.1 requirement

    Example targets

    • Background video, celebratory animation, loading effects, event footage and embedded media.

    Common mistakes

    • Watching suspected flashing repeatedly.
    • Passing content by eye without threshold analysis.
    • Confusing ordinary motion with rapid flashing.

    Back to test catalogue