web development
Website Accessibility Checklist: A Practical Founder Pass
Use this website accessibility checklist to find the common barriers in navigation, content, forms, contrast, and responsive behavior before release.
TL;DR — A website accessibility checklist should test real tasks with a keyboard, clear structure, readable contrast, labeled forms, and useful error recovery. Automated scans help, but people must test the journeys that matter.
Website accessibility is whether people can perceive, understand, navigate, and operate your site using different devices and assistive technologies. It is product quality: a blocked checkout, an unlabeled form, or a menu that traps keyboard focus prevents a customer from completing the same work a visual mouse user can complete.
The W3C’s WCAG 2.2 Quick Reference is the source of truth for success criteria and implementation guidance. This checklist is a practical starting pass, not a statement of legal compliance. Regulations and contractual requirements depend on location and context; get appropriate specialist advice for those decisions.
Start with structure and keyboard use
Use a logical heading order that describes the content rather than its styling. Give each page a clear title, identify the main content, and ensure links say where they go. Do not use a click handler on a generic element when a button or link expresses the real action. Native controls bring expected keyboard behavior and semantics.
Unplug the mouse for the most important journeys. Can you reach every interactive element with Tab? Is the visible focus indicator obvious? Does focus move sensibly after opening a modal, submitting a form, or navigating to new content? Can you close overlays with the expected key without losing your place? A keyboard failure is often easy to find and high impact.
Check content, media, and visual design
Provide meaningful text alternatives for informative images. Decorative images should be ignored by assistive technology rather than given a noisy description. Captions and transcripts need to match the purpose of audio and video. Do not rely on color alone to signal an error, status, or required field.
Test text at larger browser zoom and on a narrow viewport. Content should remain readable and usable without horizontal scrolling for ordinary text. Check contrast with the actual foreground and background colors, including disabled-looking text that still needs to be read. The W3C WCAG 2.2 specification explains the testable criteria and why current guidance should be used for new work.
Avoid unexpected motion, auto-playing media, or time limits that a user cannot understand or control. If a session expires for a genuine security reason, give a clear warning and a safe recovery path where possible.
Test forms as real people use them
Every input needs a programmatic label that explains what it collects. Instructions should appear before the user needs them, not only after an error. Validation messages need to explain the problem and what will fix it; “invalid input” is not a useful recovery instruction.
Run the complete form with keyboard only. Trigger empty, incorrectly formatted, and already-used values. Confirm that the error is announced or otherwise discoverable, that focus moves to an understandable place, and that previously entered safe data is preserved. For a hypothetical booking form, “date is invalid” is incomplete; “choose a date after today” gives the person a next action.
Include accessibility in normal acceptance
Do not leave accessibility for a final audit. Put a few relevant checks into the acceptance criteria for every new feature: keyboard path, labels, error recovery, responsive reflow, and the support needed for any new media. This makes accessibility a design input rather than a remediation queue.
Automated tooling can flag missing labels, invalid markup, and some contrast issues. It cannot decide whether alternative text is useful, whether a focus order matches a user’s task, or whether a person understands an error. Pair the scan with task-based user acceptance testing, and include people who use assistive technology whenever you can recruit them ethically and compensate them fairly.
Accessibility and performance often reinforce each other: semantic HTML, focused controls, and less unnecessary interface weight make a site easier to use and easier to maintain. Our web performance guide covers a separate but related quality pass.
Keep a remediation list that can close
Record each issue with the page, user task, barrier, severity, owner, and verification method. Fix the paths that block conversion, support, account access, and core product use first. Re-test the same task after the change; a code change is not proof that the barrier is gone.
The goal is not a one-time checklist ceremony. It is a website where every new release preserves the ability of more people to complete the job they came to do.