Website Accessibility Checklist
A practical worksheet with 50 selected checks. It is not the complete WCAG standard or a legal compliance determination. References below identify WCAG 2.1 checks, selected WCAG 2.2 additions and optional Level AAA targets. Read each criterion for its full scope and exceptions.
Checkboxes do not create or save an audit record. Keep outcomes, evidence and retests in the downloadable worksheet or your own review system.
Updated October 19, 2026: added tested examples, evidence-record guidance and downloadable worksheets. Version and level labels distinguish the selected checks. Standards references: WCAG 2.1 and WCAG 2.2. Record your test environment, page state and evidence using the keyboard workflow.
This is a structured walk-through. For a fully personalized checklist, use our Checklist Generator tool.
1. Color & contrast (Perceivable)
Record the rendered color pair, text size and page state. Use the underlying contrast ratio when comparing a threshold.
2. Text alternatives & media (Perceivable)
Review the purpose of each image or media item in context; the presence of an attribute alone is not enough.
3. Forms (Perceivable + Understandable)
Test labels, instructions, errors and successful completion as one journey. Keep evidence for each tested state.
4. Links & buttons (Operable)
Record the accessible name, context and action. Check controls in the states visitors actually encounter.
5. Keyboard & focus (Operable)
6. Structure & semantics (Robust)
7. Content & language (Understandable)
8. Motion, timing, and triggers (Operable)
9. Authentication & input (WCAG 2.2)
How to record evidence before checking an item off
Worked records by Grow Wild · October 19, 2026
A checked box is a reminder, not a test report. In our October maintenance work on What Is ADA, we recorded the input, expected behavior and observed output when reviewing our heading tool. We have now tested six contrast pairs as a second example. The downloadable records show what those checks establish and what remains untested.
Download a blank evidence-record template (CSV)
Download three worked example records (CSV)
The examples use synthetic inputs in tools we maintain. They contain no client data and no claim of a completed client audit. Replace the example scope with your own tested page and environment; do not copy its result as evidence for your website.
- Define the test boundary. Record the URL, component, release or date, page state and agreed WCAG version/level. Include relevant states such as an open menu, a validation error or a confirmation screen. A result from one state does not cover the others.
- Record a repeatable method. Note browser/OS versions, viewport, zoom and any assistive technology used. Write the exact steps and inputs. Name the tool, but also describe what you inspected manually.
- Separate expectation from observation. Explain the relevant criterion requirement, then record what happened. Attach the measured value, markup excerpt or screenshot that another reviewer needs. A screenshot alone may not establish the programmatic relationship.
- Choose an honest outcome. Use “not tested” or “needs review” when evidence is missing. Use “not applicable” only with a reason. If you record a pass or failure, tie it to the tested scope and criterion—not every page or an entire standard.
- Keep the fix and retest. Preserve the original observation, note the actual change and revision, then repeat the same steps. Record remaining states or environments separately. A proposed fix is not a retest result.
Worked record: normal-text contrast
Our first sample uses #777777 text on #ffffff. The calculated ratio is about 4.478089:1; the deployed checker shows “Fail” for AA normal text. Changing the sample to #767676 on the same white background gives about 4.542225:1 and “Pass” for that numeric threshold. Both browser results matched our independent calculation.
The record therefore says “numeric threshold met for this input pair,” not “the website passes WCAG.” We did not inspect a client’s rendered text, gradients, opacity or interaction states in this sample. See the six tested pairs and the rounding boundary example for the method and reproducible inputs.
Worked record: a heading observation that stays open
The heading sample “H1 Store → H3 Products” produces one level-jump observation. Its record stays at “needs contextual review.” To assess 1.3.1, inspect whether the actual content relationships are available programmatically or in text. To assess 2.4.6, review whether the heading words describe the topic or purpose. The outline alone answers neither question.
This distinction came from our own heading-tool repair: correcting the parser made its observations more reliable, but did not turn those observations into a conformance judgment. No screen-reader result is claimed by these examples.
Use the WCAG reference filters to find the full criterion, and define representative pages and complete processes with the audit scope builder. The WCAG conformance requirements go beyond this selected checklist. Primary explanations for these examples: contrast, relationships and heading labels.
FAQ
- Is this checklist enough to be ADA compliant?
- No. This is a selected review worksheet, not the complete standard. Define the applicable WCAG version and level, evaluate every applicable criterion and the conformance requirements, and test complete processes. Optional AAA checks are labelled separately. Legal applicability requires a separate assessment.
- How long does it take to remediate a website to WCAG 2.1 AA?
- Estimate the work after reviewing representative templates, complete processes, documents, third-party components and access to the code. Include implementation and retesting separately; page count alone is not a reliable schedule.
- Can I just use an automated scanner?
- Automated scanners identify some programmatically detectable issues. Manual testing is needed for keyboard operation, assistive-technology behavior, focus management and content meaning. A scanner result alone cannot establish conformance.