A useful website accessibility checklist starts with the tasks people must complete. Make sure visitors can navigate with a keyboard, understand the page structure, read the text, operate forms and recognise errors. Then review images, links, colour, zoom and mobile layouts. Automated scanners can reveal some problems, but they cannot decide whether every label, alternative description or interaction makes sense.

This order matters for a small business. A minor decorative issue is rarely as urgent as a menu that traps keyboard users or an enquiry form that does not explain why it failed. The checklist below helps you find the biggest barriers first and gives a developer a clearer repair brief.

What should a website accessibility checklist cover?

Use Web Content Accessibility Guidelines (WCAG) 2.2 as the technical reference. WCAG groups accessibility under four principles: content should be perceivable, operable, understandable and robust. The practical checks in this article translate those principles into common website tasks.

This is a first review, not a certification or legal assessment. W3C also explains that evaluation tools cannot check every accessibility requirement. A serious assessment combines automated testing, human review, keyboard testing and feedback from people with disabilities.

1. Can every important task be completed with a keyboard?

Put the mouse aside and use the Tab key to move through the page. Use Shift+Tab to move backwards, Enter to activate links and Space where appropriate for controls. Check the menu, search, forms, cookie controls, accordions, pop-ups and checkout or booking steps.

The focus indicator should always be visible. It might be an outline, border or background change, but it must be clear enough to follow. The order should match the visual and logical order of the page. W3C’s guidance on focus order explains why keyboard navigation needs to preserve meaning and operation.

Record anything that cannot be reached, cannot be activated or traps focus inside a component. Also look for sticky banners that cover the focused item. These are high-priority defects because they can block an entire task.

2. Does the page have a meaningful structure?

A visitor should be able to understand the page without relying only on font size or visual position. Use one descriptive page heading, then organise sections with H2 and H3 headings in a logical hierarchy. Lists should be real lists, tables should represent tabular information and buttons should be coded as buttons.

Do not choose a heading level because it looks attractive. Style the correct element with CSS. To review a page, read only its headings in order. If the resulting outline is confusing, the full page will probably be harder to scan too.

3. Do images communicate the same information in text?

Informative images need alternative text that describes their purpose in context. A product photo might identify the product and relevant view; a chart needs the insight that the chart communicates. Decorative flourishes generally need an empty alt attribute so a screen reader can skip them.

Avoid starting every description with “image of”. Do not repeat a nearby caption, and do not pack SEO keywords into alt text. The goal is an equivalent, concise explanation. If an image contains a large amount of important text, place that information in normal page copy as well.

4. Are forms labelled and errors easy to fix?

Place a visible label next to every input. Placeholder text is not a reliable replacement: it disappears when someone types and often has weak contrast. Instructions should appear before they are needed, especially for date formats, password rules or required document types.

Submit the form with missing or invalid information. A good error message identifies the affected field, explains the problem and tells the visitor what to do next. Colour can reinforce an error, but should not be the only signal. Keep the user’s valid entries instead of forcing them to start again.

5. Is text readable without depending on colour alone?

Check text against its actual background, including text placed over photographs, gradients and disabled-looking controls. The WCAG contrast guidance explains the relevant requirements and exceptions. Test normal text, large text, links, buttons, form borders and focus indicators rather than checking only body copy.

Information should not depend on colour alone. Add labels, icons, patterns or text where status matters. For example, a pricing comparison should not use only green and red cells to mean “included” and “not included”.

Let visitors enlarge text and adjust spacing without losing content or controls. Avoid images of text when ordinary HTML text can do the job. Real text adapts better to zoom, user preferences, translation and different screen sizes.

6. Do links and buttons say what will happen?

Read link text without the surrounding paragraph. Repeated links called “click here” or “learn more” become ambiguous when assistive technology presents them as a list. Prefer specific labels such as “View website development services” or “Read the maintenance checklist”. W3C’s explanation of link purpose provides the underlying rationale.

Use links for navigation and buttons for actions. Indicate unusual behaviour, such as opening a PDF or starting a download, when it could surprise the visitor. If several cards lead to different destinations, each accessible name should identify the relevant service, product or article.

7. Does the layout still work when zoomed and on mobile?

Test important pages at increased browser zoom and on a narrow viewport. Visitors should be able to read and operate the page without content overlapping, disappearing or requiring excessive two-dimensional scrolling. Pay attention to navigation, data tables, comparison sections, chat buttons and cookie banners.

A responsive layout can still be inaccessible. A form that fits the screen may have an illogical reading order, and a mobile menu may open visually while keyboard focus remains behind it. Test behaviour, not just appearance.

8. Are audio, video and motion under the visitor’s control?

Provide captions for meaningful spoken video content and a transcript when it helps people access or review the information. Audio descriptions may be needed when essential information appears only visually. Avoid autoplaying audio.

How should a small business prioritise accessibility fixes?

Turn the review into a repair queue instead of a long undifferentiated list:

1. Fix blockers first: keyboard traps, unreachable controls, missing form labels, inaccessible menus and errors that stop checkout or enquiry submission.
2. Repair repeated components: the site header, footer, navigation, form pattern and reusable cards. One component-level fix can improve many pages.
3. Address high-traffic journeys: homepage, service pages, contact, booking, cart, checkout and account access.
4. Improve content patterns: headings, alternative text, link wording, captions and instructions.
5. Add regression checks: include accessibility in design review, development testing and content publishing so the same defects do not return.

Give each issue a page URL, a short reproduction step, the affected user task, an owner and a retest result. “Menu cannot be opened with Enter on the services page” is far more useful than “navigation accessibility issue”.

A practical monthly testing routine

Choose a representative sample: the homepage, one service page, one article, the contact form and any booking or purchase flow. Run an automated scan for quick signals, then complete a manual keyboard pass. Zoom the page, inspect headings and labels, submit forms with errors, and test on a phone.

When should you involve a web developer?

Content editors can often improve headings, link labels, captions and image alternatives. Developer support is usually needed for menu behaviour, focus management, modal dialogs, custom forms, interactive widgets, templates and design-system components.

If you are planning a rebuild, accessibility should be part of the brief, component design and acceptance testing—not a patch added at launch. Ishu Technology’s website and digital services cover custom web work alongside WordPress and e-commerce development. To discuss an accessibility-focused improvement plan for your business website, send your project details through the verified contact page.

Frequently asked questions

Can an automated tool prove that a website is accessible?

No. Automated tools can identify some code-level issues, but many checks require human judgement and task testing. Use automation as one part of a wider review.

Should every image have descriptive alt text?

No. Informative images need a useful text alternative. Purely decorative images should normally have empty alternative text so they can be skipped.

Is accessibility only for screen-reader users?

No. Accessible design supports people who navigate by keyboard, enlarge text, need captions, have low vision, experience colour-vision differences, use voice control or benefit from clearer structure and instructions.

What is the best page to test first?

Start with the page and flow most connected to a business goal, such as the contact form, booking journey or checkout. Then test shared components and high-traffic pages.

Does passing a checklist mean the site conforms to WCAG?

Not necessarily. A checklist is a useful first review. Conformance claims require a defined scope, appropriate evaluation methods and evidence against the relevant WCAG success criteria.