Practical guide 6 min read
A website accessibility checklist helps a team find barriers that prevent people from reading information, navigating or completing a task. Begin with a real journey: find a service, compare the information, open the enquiry form and correct an error. Record what happens at each step rather than relying only on screenshots or an automated score.
This is a practical first review for business websites. It does not establish WCAG conformance or replace a complete evaluation involving appropriate technical expertise and users with disabilities. The W3C WAI Easy Checks explains why a page can pass preliminary checks and still contain accessibility barriers.
Choose the pages and journeys to test
Select representative templates and interactive states: homepage, service page, article, contact form, mobile menu and any booking or checkout flow. Include an open accordion, a form error and a confirmation state. A shared component defect may affect many pages; a single passing page does not verify the whole site.
Write down the page URL, browser, operating system, screen size, zoom level, date and reviewer. Record which tasks and assistive technologies were checked and which remain untested. Use staging and authorised test details when a submission could create an order, send a message or alter a real account.
1. Follow the journey using a keyboard
- Begin at the top of the page and use Tab to move forward and Shift+Tab to move back.
- Check that you can identify the focused control and that sticky headers, banners or floating widgets do not cover it.
- Open navigation and interactive controls using the keys appropriate to their control type. Buttons normally respond to Enter or Space; links normally respond to Enter.
- Continue through the task. Look for skipped controls, unexpected jumps, unreachable actions or places where focus becomes trapped.
- For a dialog, test its close action and the focus destination after closing. Record whether the next step remains understandable.
A control looking clickable does not establish keyboard support. Test the next key after an action: opening a panel successfully can still leave the keyboard user in the wrong part of the page.
Verified Agal example: on 14 October 2026, a selected Help Centre route opened the requested answer, but the next Tab key returned to an earlier video button. The handler was changed to focus the requested summary, and the selected route was retested. This own-site example verifies that route; it does not establish coverage for every page or screen reader. The launch checklist records the example and its limits.
2. Enlarge text and check the reading layout
Increase browser zoom and review the same task, including navigation, prices, labels and error messages. Check whether content overlaps, disappears or becomes hidden inside fixed-height cards. On a narrow layout, confirm that a floating contact button does not cover the form’s last field or submit control.
Inspect tables and other wide content separately. A locally scrollable table may need an understandable label and keyboard access; a whole page unexpectedly scrolling sideways can make ordinary reading difficult. Record the exact zoom and layout where the problem appears so it can be reproduced.
3. Review page titles, headings and links
The browser title should distinguish the page and explain its purpose. Headings should describe real sections and follow an understandable structure. Enlarging or bolding a paragraph does not make it a heading for assistive technology.
Read important link names with their context. Several identical “Read more” labels can be ambiguous when they lead to different resources. Give meaningful destinations clear names, and check that an icon-only button has a usable accessible name. Screen-reader review should also check how names, roles and states are announced.
4. Judge image alternatives by purpose
For an informative image, ask what a person needs to understand without seeing it. A diagram may need an explanation in the surrounding content. A functional image needs to convey the action or destination. Decorative imagery should not add unnecessary narration.
An automated tool can detect a missing alt attribute, but it cannot reliably decide whether the words fit the image’s purpose. Review the image in context. Avoid replacing useful alternatives with repeated service keywords or filenames.
5. Test forms, errors and completion feedback
Check that every field has a persistent, understandable label and that required information and format instructions are available before entry. Placeholder text disappears while typing and should not carry the entire instruction.
- Reach and complete fields using a keyboard. Confirm the reading and focus order follow the task.
- Leave a required field empty or use an invalid format in an authorised test. Find the error and check that it explains how to correct the value.
- Confirm that labels and errors can be associated with the affected controls, including in the selected screen-reader checks.
- Correct the error and check that appropriate previously entered values remain available.
- Check that successful completion is discoverable and explains the next step.
A visible success message, a saved entry and delivery to the team’s inbox are separate observations. Use the form-delivery evidence workflow to verify receipt. Keep names, phone numbers, email addresses and message content out of analytics events.
6. Check contrast, movement and media
Measure text contrast against the background actually behind it, including text over photos and changing carousel slides. Inspect hover, focus, selected, disabled and error states where relevant. Colour should have supporting text, shape or another cue when it communicates required information.
Check whether moving content can be paused or controlled and whether motion preferences are respected. For videos, review captions for accuracy and timing, the player’s keyboard controls, and alternatives for important information communicated visually. A caption switch being present does not prove the captions are useful.
7. Combine tools with human evaluation
Run an automated checker on the representative pages and states, then inspect each result in context. It can identify some markup or contrast problems while missing unclear instructions, misleading image alternatives or an unusable sequence of actions.
Plan appropriate screen-reader, keyboard and user evaluation for important journeys. Name the tools, versions, pages and states tested. A clean scanner result is useful evidence for its covered rules, not proof that all visitors can complete the task. W3C’s evaluation resources explain the wider evaluation process.
Use a findings worksheet and retest the journey
Copy these fields into your issue tracker: URL and component; user task; environment; steps to reproduce; expected behaviour; observed behaviour; supporting evidence; affected users or tasks; priority; owner; proposed correction; retest date and result.
Illustrative record: contact page, enquiry task, keyboard at a recorded zoom level. Tab reaches the submit button, but a sticky banner covers it. Expected: the focused action remains visible and usable. Record the screenshot and key sequence, assign the component fix, then repeat the full enquiry route after the change. This is a fictional example, not a client result.
Prioritise barriers that block essential tasks. After correcting a shared menu, form or dialog, check representative places where that component is reused. Keep unresolved limitations and untested areas visible in the handover.
Connect the review to the website project
Put accessibility expectations, review responsibilities and acceptance checks in the website design brief. Keep general publication, ownership and measurement checks in the business website launch checklist. For multiple languages and markets, also review the international website design checklist.
Share observed barriers, affected URLs and required workflows when discussing our web design and development service. Send the review findings for a scoped website discussion; the required work and evaluation coverage should be agreed before implementation.
Related Blogs
