# Website Accessibility Audit: Check Real Visitor Tasks

> Audit accessibility using real visitor tasks, keyboard navigation, forms and content checks, then prioritise fixes with evidence beyond automated scores.

- URL: https://weaveward.com/blog/website-accessibility-audit-business
- Published: 2026-02-25
- Updated: 2026-10-12
- Category: Web Development
- Tags: accessibility, website-audit, forms
- Author: Weaveward Team

An accessibility audit asks whether people with different abilities and assistive technologies can use a website. For a company profile, that includes understanding services, reviewing work and sending an enquiry. A clean visual design and a high automated score do not establish that those tasks are possible.

Start with representative journeys and the accessibility standard or conformance target agreed for the project. The following approach is practical scoping guidance, not a substitute for a complete conformance evaluation.

## Choose pages by function, not only popularity

Include the homepage, a service detail page, a project detail, an article, the contact form and the error page. Add any unique interactive component such as filtering, a menu, a dialog or an upload control. Shared components can affect many routes, while a rarely visited form may still be essential.

Record the browser, device and assistive technology used in manual testing. This makes a reported problem reproducible and avoids treating one successful test as universal compatibility.

## Complete the journey using a keyboard

Move through the page without a mouse. Check whether the focus indicator is visible, whether the order makes sense and whether every interactive control can be reached and operated. Open and close menus and dialogs, including their dismissal paths.

A hypothetical portfolio filter might be clickable but unreachable by keyboard because it was built as a plain decorative element. Correcting the underlying control can improve semantics and operation together. Adding a click handler alone does not provide the expected keyboard behaviour.

Watch for focus disappearing after a route change or becoming trapped inside an overlay. The visitor should understand where they are and how to continue.

## Test meaning as well as appearance

Review headings as an outline. Their structure should describe the page rather than being chosen only for text size. Check link names outside their surrounding paragraphs; repeated “learn more” links may be unclear without context.

Alternative text should explain the purpose of a meaningful image. A decorative shape can have an empty description. A project screenshot needs a concise explanation of what it demonstrates, while detailed information should also exist in ordinary page text.

Verify readable contrast, text resizing and layouts at narrow widths. Information should not rely only on colour, such as a red field border with no written error.

## Give form errors a usable recovery path

Consider these checks:

| Form state | What the visitor needs |
| --- | --- |
| Before submission | Clear labels, required-field information and useful instructions |
| Invalid field | A specific explanation linked to the relevant control |
| Submission in progress | Understandable status without losing entered information |
| Submission failed | A retry path and truthful outcome |
| Submission saved | A confirmation that assistive technology can perceive |

Test the form with missing values and an unavailable server. A success message that appears visually but is never announced can leave a screen-reader user uncertain about the result.

## Combine tools with manual evidence

Automated checks can find many detectable issues quickly, including missing labels or some contrast problems. They cannot judge whether an image description is useful, a heading explains the page or a task has a confusing recovery path.

Prioritise failures that block essential tasks, then shared component issues and remaining content problems. Document the affected page, steps to reproduce, expected behaviour and observed behaviour. Screenshots or short recordings can support the report, but written steps remain important.

Allow time to test with people who use relevant assistive technologies when the project scope permits. Their experience can reveal confusing interactions beyond a mechanical checklist. Record the scope honestly: a limited review should not be presented as a certification of every page and device.

Retest corrected components and complete the journey again. Accessibility maintenance belongs in content publishing and future feature reviews, because a new image, menu or form can reintroduce barriers even when the previous release was carefully audited.

## Primary references

- [W3C accessibility tutorials](https://www.w3.org/WAI/tutorials/)
- [W3C accessible form notifications](https://www.w3.org/WAI/tutorials/forms/notifications/)

## Related reading

- [UI and UX Principles for Clearer Enquiry Journeys](/blog/ui-ux-design-principles-conversions)
- [Secure Contact Forms: Save Enquiries with Clear Consent](/blog/secure-contact-form-lead-capture)

Explore our [web apps](/services/web-apps) to plan a practical implementation around your team's needs.