Website Accessibility Audit: Scope, Tests and Evidence

What Is a Website Accessibility Audit

A website accessibility audit tests whether disabled people can complete representative tasks and records failures against applicable WCAG success criteria. The result is technical evidence for remediation. It is not an automatic legal-compliance decision.

The audit examines everything from colour contrast and keyboard navigation to screen reader compatibility and form labelling. The result is a report detailing accessibility barriers and how to remove them.

Why Accessibility Matters

Accessibility isn't just about compliance — it's about reaching more users and building a better website for everyone:

• User access: Barriers can prevent people from reading content, navigating controls, completing forms or understanding feedback.
• Legal duties: Duties vary by jurisdiction, entity, product and date. Use regulator guidance and qualified legal advice for the organisation's scope.
• Search overlap: Semantic HTML and text alternatives can also help machines understand content, but accessibility conformance does not guarantee rankings.
• Better UX for everyone: Accessibility improvements like clear navigation, readable fonts, and keyboard support benefit all users, not just those with disabilities.
• Brand reputation: Demonstrating commitment to accessibility builds trust and positions your brand as inclusive and responsible.

WCAG Standards Explained

WCAG 2.1 is organised around four principles (POUR):

• Perceivable: Users must be able to perceive the content. This covers text alternatives for images, captions for video, sufficient colour contrast, and content that can be presented in different ways.
• Operable: Users must be able to operate the interface. This covers keyboard accessibility, enough time to read content, no seizure-inducing content, and clear navigation.
• Understandable: Users must be able to understand the content and interface. This covers readable text, predictable navigation, and help with input errors.
• Robust: Content must be robust enough to work with assistive technologies. This covers clean HTML, proper ARIA attributes, and compatibility with screen readers.

There are three conformance levels: A (minimum), AA (standard target for most organisations), and AAA (highest). Most legal requirements and best practices target WCAG 2.1 Level AA.

Key Areas to Check

• Colour contrast: Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Use tools like WebAIM's Contrast Checker.
• Keyboard navigation: Every interactive element (links, buttons, forms, menus) must be operable with keyboard alone. Tab order should be logical.
• Image alt text: Every meaningful image needs descriptive alt text. Decorative images should have empty alt attributes (alt="").
• Form labels: Each input needs an accessible name and any instructions or errors must be associated in a way assistive technology can determine. Prefer a visible label where the control needs one.
• Heading structure: Use headings to identify sections and express their hierarchy. Inspect the resulting outline instead of using heading elements for visual styling.
• Link purpose: Users must be able to determine a link's purpose from its text or the context permitted by the applicable WCAG criterion.
• Video and audio: Videos need captions. Audio content needs transcripts. Auto-playing media must have controls to pause.
• Focus indicators: Keyboard focus must be visible on all interactive elements. Don't remove the browser's default focus outline without providing an alternative.

Common Accessibility Issues

WebAIM's annual Million study tracks automatically detectable patterns on home pages. Its percentages change each year and do not measure complete WCAG conformance. Use the current report for prevalence and check these recurring categories:

1. Low-contrast text: Recalculate the contrast from rendered foreground and background colours, including states and images.
2. Missing alternative text: Determine the image's purpose before deciding whether it needs descriptive or empty alternative text.
3. Unlabelled form controls: Inspect each control's computed accessible name and visible instructions.
4. Empty links and buttons: Verify the accessible name and purpose in context, including icon-only controls.
5. Missing document language: Check the page language and changes in language where applicable.
6. ARIA errors: Validate names, roles, values, states and relationships, then test custom interactions with a keyboard and screen reader.

Accessibility Audit Tools

• axe DevTools: Browser extension that scans pages for WCAG violations. Free version catches most common issues. The industry standard for automated testing.
• WAVE: Web-based tool from WebAIM that visually overlays accessibility issues on your page. Excellent for understanding issues in context.
• Lighthouse: Built into Chrome DevTools. Includes an accessibility audit that checks against a subset of WCAG criteria. Good starting point.
• Pa11y: Open-source command-line tool for automated accessibility testing. Great for CI/CD integration.
• Colour Contrast Analyser: Desktop tool for checking colour contrast ratios. Includes an eyedropper for picking colours from any application.
• Screen readers: Test agreed browser and screen-reader combinations such as NVDA on Windows, VoiceOver on Apple platforms or TalkBack on Android. Select combinations from the audience and conformance scope.

Manual Testing

Automated rules evaluate only patterns that can be determined by their engine and page state. Validate those results and manually test applicable criteria and complete tasks:

• Keyboard-only navigation: Put your mouse away. Can you reach every link, button, and form field using Tab? Can you activate them with Enter or Space? Can you navigate menus?
• Screen reader testing: Turn on a screen reader and navigate your site. Does the content make sense when read aloud? Are images described? Are form fields labelled?
• Zoom testing: Zoom to 200% and 400%. Does the layout still work? Is content still readable? Does anything overflow or overlap?
• Motion sensitivity: Does your site have animations that can't be paused? Check that prefers-reduced-motion is respected.

Legal Requirements

Web accessibility is increasingly required by law:

• US: The DOJ Title II rule sets WCAG 2.1 AA requirements and dates for state and local governments. Title III coverage for private websites depends on current law and jurisdiction.
• EU: The European Accessibility Act applies from 28 June 2025 to specified products and services, with exemptions and national enforcement rules.
• UK: Public-sector accessibility regulations and the Equality Act have different scopes. Check the current GOV.UK guidance for the organisation.
• Other jurisdictions: Identify the applicable law and incorporated technical standard before calling a WCAG result a compliance result.

Start with W3C's WCAG 2.2 Recommendation and its evaluation guidance. Use our accessibility tools guide to choose evidence and confirm any professional audit scope before assuming particular accessibility tests are included.