Website Accessibility Audit Checklist for Business Teams

A website accessibility audit should test whether people can perceive, understand and operate the site using different devices and assistive technologies. Automated tools are useful for repeatable checks, but they cannot judge the quality of alternative text, logical focus order, clear instructions or whether a journey makes sense with a screen reader.

Use the Web Content Accessibility Guidelines (WCAG) 2.2 as the technical reference. For most business websites, WCAG 2.2 Level AA is a practical target, but legal duties vary by country, sector and organisation. Obtain qualified legal advice where compliance conclusions matter.

Define scope before testing

Inventory templates and critical journeys rather than testing only the homepage. Include navigation, search, enquiry forms, authentication, account areas, documents, video, cookie controls, error pages and third-party widgets.

Select representative pages for each component and content type. Give priority to high-traffic, high-value and high-risk tasks. A contact form that cannot be submitted by keyboard matters more than a decorative issue on an archived page.

Record browsers, devices, viewport sizes, assistive technologies and user states used. An audit result without scope is difficult to reproduce.

Establish an accessible foundation

Use valid, semantic HTML. Headings should describe a logical outline, landmarks should identify page regions and interactive elements should use the correct native control wherever possible. A styled <div> is not automatically a button.

Set a meaningful page title and language. Ensure content order in the document matches its visual and reading order. Provide a method to bypass repeated navigation, commonly a visible-on-focus skip link.

ARIA can add necessary semantics, but incorrect ARIA can make an interface worse. Prefer native HTML and test the resulting accessibility tree.

Test keyboard operation

Complete every critical journey using only a keyboard. All controls must receive visible focus in a logical order. There should be no keyboard trap, including inside menus, dialogs, carousels and embedded widgets.

Focus should move predictably when a dialog opens and return appropriately when it closes. Sticky elements must not obscure the focused control. WCAG 2.2 adds criteria related to focus not being obscured and focus appearance; verify both, especially with cookie banners and fixed headers.

Check that custom controls respond to expected keys. Do not make hover the only way to reveal essential content.

Review text, headings and links

Use concise headings that identify sections. Avoid skipping structure for visual size; CSS controls appearance. Link text should explain its destination without relying entirely on surrounding text. Repeated “click here” links are hard to navigate in a links list.

Instructions should not depend only on colour, position or shape. Use plain language, explain abbreviations where needed and keep line spacing and zoom usable without clipping.

At 200% zoom and narrow mobile widths, users should be able to read and operate content without losing controls or requiring two-dimensional scrolling except where intrinsically necessary.

Check images, audio and video

Informative images need alternative text expressing their purpose in context. Decorative images should be ignored by assistive technology. Do not repeat adjacent captions word for word.

Complex diagrams may need a short alternative plus an accessible explanation in nearby text. Video with meaningful speech needs accurate captions; visual information may require audio description or an equivalent transcript. Avoid autoplaying sound.

The Blog’s editorial images should support the article rather than carry essential text. This is one reason AUZtec uses code-generated, branded diagrams with descriptive alt text while keeping the full argument in HTML.

Audit forms and errors

Every input needs a programmatically associated label. Placeholder text is not a label. Group related fields with appropriate structure and state whether a field is required before submission.

Error messages should identify the field, explain the problem and suggest a correction. Move focus or provide a clear summary when submission fails. Preserve valid input so users do not repeat work.

Test validation with screen readers and keyboard navigation. Ensure autocomplete attributes support common personal details where relevant. Review the contact journey defined in the B2B website redesign checklist.

Verify colour and visual behaviour

Measure text and interface contrast using reliable tools. Check default, hover, focus, disabled and error states—not only static mock-ups. Meaning must not depend on colour alone.

Support user preferences such as reduced motion. Pause, stop or hide moving content where required. Avoid flashes that can trigger seizures. When motion communicates state, provide a non-motion equivalent.

Test light/dark modes and high-contrast settings if supported. Glass effects must retain a solid-enough background and clear boundary; aesthetics do not override legibility.

Use automated and manual testing together

Automated checks can catch missing labels, contrast failures, invalid relationships and some naming issues at scale. Run them in development and CI, but expect partial coverage.

Manual checks should include keyboard navigation, zoom/reflow, content review and at least one screen reader appropriate to the platform. User testing with disabled people provides insights that a checklist cannot reproduce.

Prioritise findings responsibly

For each issue record page/component, steps, actual result, expected result, WCAG reference, affected users, severity and recommended fix. Group component-level defects so one design-system change can repair many pages.

Prioritise blockers in critical journeys, widespread template failures and issues affecting several user groups. Distinguish quick content fixes from structural component work. Retest the exact failure and related regression paths.

Prevent accessibility regression

Add semantic and interaction requirements to component acceptance criteria. Include automated checks in CI, keyboard review in feature testing and periodic manual audits. Train editors on headings, links, alternative text and captions.

Accessibility belongs in UI/UX design, engineering and content workflows. A late audit alone creates recurring remediation cost.

Practical audit checklist

• Test every template and critical user journey.
• Verify titles, language, landmarks and heading structure.
• Complete tasks with keyboard only and visible focus.
• Check zoom, reflow and mobile orientation.
• Validate accessible names, labels, instructions and errors.
• Review alternative text, captions and transcripts.
• Measure contrast across all interaction states.
• Test dialogs, menus and dynamic status messages.
• Combine automated scans with manual assistive-technology tests.
• Assign severity, owner, fix and retest evidence.

An accessibility audit is successful when it leads to sustained, verifiable improvement—not when it produces a long report. Pair it with a technical SEO audit where discoverability and rendered structure share the same templates. AUZtec Innovations builds premium websites and web applications with accessibility treated as part of product quality.