A website accessibility checklist helps you find things that can stop people from using your site. Some visitors use a keyboard. Some enlarge text. Others use software that reads the page aloud. Your main tasks need to work in more than one way.
Start with one important task and keep a record of where it fails. You can use the steps below yourself, then give the findings to the person who manages the site.
The short answer
- Test a whole task, from finding a service to receiving form feedback.
- Check keyboard use, clear labels, zoom and measured text contrast.
- Record each barrier and retest it. A short checklist is not an accessibility certification.
How this guide was made
This first review follows W3C WAI guidance, with contrast and reflow details from WCAG 2.2. The task script and issue log are suggested tools, not results from a tested site. They do not establish full WCAG conformance or legal compliance.
Sources checked .
Choose a real task to check
Choose a task such as finding a service and asking for a quote. Check the full route, since a readable homepage can still lead to an unusable form.
This first review can reveal barriers. It cannot certify the whole site or cover every disability. W3C makes that limit clear in its introductory checks. Some findings need a developer and deeper review.
Source for this section: [1] W3C introductory accessibility checks
Follow one complete enquiry task
Use this suggested script with test details you control. Agree where the test message will go before sending it.
- Start at the homepage and put the mouse aside.
- Use Tab to reach the menu, then open a service page.
- Find the enquiry link and reach each field.
- Leave one required field empty and try to submit.
- Find the error, correct it and submit the test.
- Find the result message and confirm that the intended staff member can find the enquiry.
Try the page with a keyboard
Use Tab to move forward and Shift with Tab to move back. Keep notes of the exact control and step that fails.
Source for this section: [1] W3C introductory accessibility checks
Find the current focus
Look for a visible mark around the link or control you have reached. It should stay visible against the page background. If it disappears, record the last item you could identify.
Leave every control
You should be able to move away from fields, menus and other controls. A trap that stops you reaching the enquiry button blocks the task and needs prompt attention.
Check titles, headings and links
Open each important page and read its main heading. Can you tell what the page is for? Then scan the smaller headings. They should help a visitor find a useful answer without reading every line.
Look at link names too. Several links that all say Click here give little help when read on their own. A name such as View our cleaning services tells people where the link leads.
Ask the person building the site to check the heading structure in the page code. Large bold text can look like a heading without being marked as one. A visual review alone will not find that difference.
Source for this section: [1] W3C introductory accessibility checks
Check images, text and zoom
Use the same service and contact pages for the next checks. Save the settings used so another person can repeat them.
Enlarge text and check reflow
Enlarge text and look for clipped words or hidden actions. Ask your developer to check content at the equivalent of 320 CSS pixels wide. One common desktop check is 400 percent zoom from a viewport 1280 CSS pixels wide.
Most content should remain usable without scrolling in two directions. Content that needs a two dimensional layout, such as some data tables, has exceptions. Review the full rule before calling a table a failure.
Source for this section: [4] W3C WCAG 2.2 reflow guidance
Check contrast with a tool
For WCAG AA, ordinary text generally needs a contrast ratio of at least 4.5:1. Large text has a 3:1 threshold, with size rules defined in the standard. A heading is not large text just because it looks bold.
Measure the actual text and background colors, including button states. Do not round a failed ratio up to pass. Ask the reviewer to explain any claimed exception.
Source for this section: [3] W3C WCAG 2.2 contrast requirements
Review image meaning
An informative image needs a text alternative that conveys its useful meaning. Decoration normally needs an empty alternative. Ask what a visitor would miss if the image could not be seen.
Source for this section: [1] W3C introductory accessibility checks
Check labels and form feedback
Each form field needs a clear label that stays available as someone types. The W3C Forms Tutorial also calls for useful instructions and feedback. A person should know what to enter and how to fix a mistake.
Leave a required field blank. The error should name the field and help you fix it. After success, the page should explain what happened. A visible message is one check; ask a competent reviewer to check that assistive technology can detect it too.
Use test details that do not expose customer information. Confirm delivery through your normal inquiry system, then follow your process for removing test entries. This turns the review into a check of the whole task.
Source for this section: [2] W3C guide to accessible forms
Write a fix request someone can use
These are fictional examples of issue records. They show the level of detail to collect, not results from a test of your site.
This priority method is our planning aid, not a W3C severity scale. Fix a blocked task before a small visual detail that does not prevent use. Keep both in the log so the less urgent issue is not forgotten.
- Page address and date.
- Device or tool used.
- Action tried and expected result.
- What actually happened.
- Person responsible and result of the next check.
| Log field | Fictional issue example |
|---|---|
| Priority | High, the enquiry cannot be sent with a keyboard |
| Page and setup | Contact page, desktop keyboard, date to record |
| Steps | Open menu, tab through links, try to reach the form |
| Expected result | Focus reaches the enquiry fields |
| Actual result | Focus stays inside the menu |
| Owner | Named developer, to assign |
| Retest | Pending, repeat the same task after the fix |
Know when to get a deeper review
Automatic tools can flag some issues. They cannot tell you everything about how a person uses the site. A good score should not replace the task checks or a careful review.
When possible, include people with disabilities in testing important tasks. Pay for their time and agree on what they will review. Use their findings to guide fixes without treating one person as the voice of every visitor.
Start by removing barriers that block contact, booking or access to key facts. Keep the issue log and check each fix. That gives your next review a clear record of what is still open.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview