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
- Agree the website or web application, release, languages, pages, components, states and user journeys in scope.
- Record the real browsers, devices, viewport sizes, input methods and assistive technologies available.
- Use safe test data. Do not put real user information, credentials or unnecessary personal data in evidence.
- Run an automated pre-check, then complete every applicable manual procedure below.
- 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.
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.
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 testsWCAG-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
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.
What to record
- Page URL and template
- Title and heading outline
- Landmark list
- Reading-order issue
- Language values
Related success criteria
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
CP-03
Links, buttons, icons and custom controls
Interaction
Check that interactive controls are identifiable, operable and correctly exposed in every state.
Use this for
- Text and image links
- Buttons and icon buttons
- Toggles, switches and custom widgets
- Embedded and third-party controls
What should happen
- Links describe their destination or purpose in context.
- Buttons describe the action they perform.
- Visible text is included in the accessible name.
- Role, state and value are programmatically available.
- Every control works by keyboard and displays 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
ActionInventory links, buttons, icon controls, toggles and custom widgets in default and changed states.
- Expected result
- Every interactive item has a clear purpose and no meaningful control is missing from the inventory.
- Record
- Control text, location, state and screenshot.
Step 2 of 6
ActionInspect each control's accessible name, role, value and state.
- Expected result
- The computed information matches the visible purpose and current state.
- Record
- Visible label and computed accessibility properties.
Step 3 of 6
ActionRead links out of visual context using a links list or accessibility tree.
- Expected result
- Each destination can be determined from link text or permitted programmatic context.
- Record
- Ambiguous link text and available context.
Step 4 of 6
ActionReach every control with Tab and Shift+Tab.
- Expected result
- Focus order is logical and each focused control has a visible indicator.
- Record
- First unreachable, hidden or unexpectedly ordered control.
Step 5 of 6
ActionActivate links with Enter and buttons with Enter and Space.
- Expected result
- The expected action occurs once, using the correct keyboard interaction.
- Record
- Control, key and actual result.
Step 6 of 6
ActionChange toggles, switches or selected controls and inspect them again.
- Expected result
- Visible and programmatic states update consistently and do not rely only on colour.
- Record
- State before and after activation.
What to record
- Control inventory
- Visible and accessible names
- Role and state
- Keyboard result
- Focus issue
Related success criteria
Common failures
- An icon button is announced only as button
- A div responds to clicks but not keyboard
- Visible text is absent from the accessible name
- Selected state changes only by colour
CP-04
Forms, labels, validation and submission
Forms & journeys
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.
What to record
- Field labels and names
- Required and autocomplete states
- Error inputs and messages
- Focus after error
- Submission status
Related success criteria
- SC 1.3.1Info and RelationshipsLevel A
- SC 1.3.5Identify Input PurposeLevel AA
- SC 2.1.1KeyboardLevel A
- SC 2.4.3Focus OrderLevel A
- SC 2.4.6Headings and LabelsLevel AA
- SC 2.5.3Label in NameLevel A
- SC 3.3.1Error IdentificationLevel A
- SC 3.3.2Labels or InstructionsLevel A
- SC 3.3.3Error SuggestionLevel AA
- SC 3.3.4Error Prevention (Legal, Financial, Data)Level AA
- SC 3.3.7Redundant EntryLevel A
- SC 4.1.2Name, Role, ValueLevel A
- SC 4.1.3Status MessagesLevel AA
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
CP-05
Dialogs, modals, popovers and tooltips
Interaction
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.
What to record
- Trigger and layer type
- Initial focus
- Forward and reverse order
- Close methods
- Return focus
- Role and name
Related success criteria
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
CP-06
Tabs, accordions and disclosure controls
Interaction
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.
What to record
- Trigger properties
- Activation keys
- Focus order
- Tab selection
- Control relationships
Related success criteria
Common failures
- A clickable heading is not keyboard operable
- Collapsed content remains focusable
- Selected tab is not announced
- Activation loses focus
CP-07
Tables, lists and grouped content
Structure & content
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.
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
CP-08
Search, autocomplete, filters and results
Interaction
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.
What to record
- Control properties
- Suggestion behaviour
- Filter states
- Status announcements
- Focus after updates
Related success criteria
- SC 1.3.1Info and RelationshipsLevel A
- SC 1.4.1Use of ColorLevel A
- SC 2.1.1KeyboardLevel A
- SC 2.4.3Focus OrderLevel A
- SC 2.4.6Headings and LabelsLevel AA
- SC 2.4.7Focus VisibleLevel AA
- SC 2.5.3Label in NameLevel A
- SC 3.2.2On InputLevel A
- SC 3.3.2Labels or InstructionsLevel A
- SC 4.1.2Name, Role, ValueLevel A
- SC 4.1.3Status MessagesLevel AA
Common failures
- Suggestions require a mouse
- Active suggestion is not announced
- Filtering moves focus to the page start
- Result updates are silent
CP-09
Images, icons, SVG, charts and canvas
Visual & layout
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.
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
CP-10
Carousels, animation and dynamic updates
Media & motion
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.
What to record
- Moving-content inventory
- Pause result
- Control names
- Hidden focus
- Update announcement
Related success criteria
Common failures
- Pause works only on hover
- Hidden slides remain focusable
- Rotation moves focus
- Toasts are visible but silent
CP-11
Audio, video, captions and media controls
Media & motion
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.
What to record
- Media classification
- Autoplay behaviour
- Control results
- Caption timestamps
- Missing visual alternative
- Live sample
Related success criteria
- SC 1.2.1Audio-only and Video-only (Prerecorded)Level A
- SC 1.2.2Captions (Prerecorded)Level A
- SC 1.2.3Audio Description or Media Alternative (Prerecorded)Level A
- SC 1.2.4Captions (Live)Level AA
- SC 1.2.5Audio Description (Prerecorded)Level AA
- SC 1.4.2Audio ControlLevel A
- SC 2.1.1KeyboardLevel A
- SC 2.2.2Pause, Stop, HideLevel A
- SC 2.4.7Focus VisibleLevel AA
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
CP-12
Pointer, touch, dragging and target size
Interaction
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.
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
CP-13
Authentication, timeouts and multi-step processes
Forms & journeys
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.
What to record
- Step sequence
- Authentication methods
- Timeout controls
- Repeated data
- Error recovery
- Review and submission
Related success criteria
- SC 2.1.1KeyboardLevel A
- SC 2.2.1Timing AdjustableLevel A
- SC 2.4.2Page TitledLevel A
- SC 2.4.3Focus OrderLevel A
- SC 3.3.1Error IdentificationLevel A
- SC 3.3.3Error SuggestionLevel AA
- SC 3.3.4Error Prevention (Legal, Financial, Data)Level AA
- SC 3.3.7Redundant EntryLevel A
- SC 3.3.8Accessible Authentication (Minimum)Level AA
- SC 4.1.3Status MessagesLevel AA
Common failures
- Paste is blocked
- Timeout warning cannot be extended
- Information must be retyped
- Returning to correct data loses progress
- Submission status is silent
CP-14
Responsive layout, zoom, orientation and text spacing
Visual & layout
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-02
Images, icons and visual text
Visual & layout
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.
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.
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.
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.
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.
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.
TC-03
Instructions and colour meaning
Visual & layout
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.
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.
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.
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.
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.
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.
TC-04
Orientation, text resizing, reflow and spacing
Visual & layout
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-05
Text and control contrast
Visual & layout
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.
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.
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.
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.
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.
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.
TC-06
Content shown on hover or focus
Interaction
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.
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.
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.
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.
TC-07
Keyboard access, focus and bypass
Interaction
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-08
Character-key shortcuts
Interaction
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.
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.
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.
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.
TC-10
Pointer, touch, dragging and motion
Interaction
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-11
Form names, instructions and autocomplete
Forms & journeys
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-12
Form errors, unexpected changes and status messages
Forms & journeys
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-13
Timeouts, repeated data and authentication
Forms & journeys
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-14
Automatic audio and moving content
Media & motion
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.
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.
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.
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.
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.
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.
TC-15
Prerecorded audio and video
Media & motion
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TC-16
Live media captions
Media & motion
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.
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.
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.
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.
TC-17
Flashing content
Media & motion
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.
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.
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.
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.