Free Tool
Pre-VPAT checklist (WCAG 2.1 AA).
Walk your product through the success criteria most likely to derail a VPAT. Answers save in your browser only — nothing is sent to us.
Progress: 0 of 19 answered
Supports 0 · Partial 0 · Fails 0 · N/A 0
This checklist is a pre-flight screen, not a substitute for testing or contracted conformance documentation. When you are ready to define an evaluation scope, see our audit services.
1. Perceivable
Information and UI components must be presentable in ways users can perceive.
WCAG 1.1.1 · Level A
Non-text content
Does every image, icon, and non-text element have a meaningful text alternative (or be marked decorative)?
Empty alt='' is correct for purely decorative images. Avoid 'image of …'.
WCAG 1.3.1 · Level A
Info and relationships
Are headings, lists, tables, and form labels conveyed in markup — not just by visual styling?
Use <h1>–<h6>, <label for>, <ul>/<ol>, and proper <th scope>.
WCAG 1.3.5 · Level AA
Identify input purpose
Do common input fields (name, email, address) use the correct autocomplete tokens?
Use autocomplete='email', 'given-name', 'street-address', etc.
WCAG 1.4.3 · Level AA
Contrast (minimum)
Does normal text have at least 4.5:1 contrast against its background (3:1 for large text)?
Test the worst case: text over hero images, hover states, disabled buttons.
WCAG 1.4.10 · Level AA
Reflow
Does content reflow without horizontal scrolling at 320 CSS pixels wide?
Test by setting the viewport to 320px or zooming to 400% on a 1280px window.
WCAG 1.4.11 · Level AA
Non-text contrast
Do UI components (buttons, inputs, focus rings) and meaningful graphics have at least 3:1 contrast?
Includes input borders, toggle states, and chart elements that convey meaning.
2. Operable
UI components and navigation must be operable.
WCAG 2.1.1 · Level A
Keyboard
Can every interactive control be reached and operated with the keyboard alone?
Tab order should be logical. No keyboard traps. Custom widgets need key handlers.
WCAG 2.4.3 · Level A
Focus order
Does focus move in an order that preserves meaning and operability?
Visual order and DOM order should match unless explicitly handled.
WCAG 2.4.4 · Level A
Link purpose (in context)
Can the purpose of each link be determined from the link text plus its programmatic context?
Avoid 'click here' and bare 'read more' links repeated on a page.
WCAG 2.4.6 · Level AA
Headings and labels
Do headings and labels describe topic or purpose?
A user scanning headings should understand the page structure.
WCAG 2.4.7 · Level AA
Focus visible
Is the keyboard focus indicator clearly visible on every focusable control?
Don't suppress :focus styles without providing an alternative.
WCAG 2.5.3 · Level A
Label in name
Does the accessible name of each control start with the visible label text?
Helps voice-control users say what they see.
3. Understandable
Information and operation of UI must be understandable.
WCAG 3.1.1 · Level A
Language of page
Is the page's primary language declared on <html lang='…'>?
Required for screen-reader pronunciation.
WCAG 3.2.2 · Level A
On input
Does interacting with a control avoid causing an unexpected context change?
Don't auto-submit forms on field change without warning.
WCAG 3.3.1 · Level A
Error identification
Are form errors identified in text (not color alone) and associated with the field?
Use aria-describedby to tie messages to inputs.
WCAG 3.3.2 · Level A
Labels or instructions
Does every input have a programmatically associated label or instruction?
<label for>, aria-label, or aria-labelledby — never just a placeholder.
WCAG 3.3.3 · Level AA
Error suggestion
When the system detects a likely user error, are suggestions for correction provided?
'Email should include @' is better than 'Invalid'.
4. Robust
Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
WCAG 4.1.2 · Level A
Name, role, value
Does every custom widget expose a correct accessible name, role, and current state?
Prefer native elements. If using ARIA, follow the ARIA Authoring Practices.
WCAG 4.1.3 · Level AA
Status messages
Are status messages (success toasts, validation errors) announced to assistive tech without moving focus?
Use role='status' or aria-live='polite'.
Need evidence-backed testing or ACR support?
Request a scoped engagement. ACR authoring, review, and sign-off are included only when contracted.