How to Audit Your Website for Accessibility: A Step-by-Step Process

How to audit your website for accessibility: a step-by-step process

How to Audit Your Website for Accessibility starts with clear scope and simple checks. This guide gives a repeatable process you can follow. It covers standards, automated tools, manual tests, reporting and prioritisation.

Step 1 — Set scope, goals and standards

Define which pages and assets you will test. Decide if you aim for WCAG 2.1 or WCAG 2.2 and which level: A, AA or AAA. Note any business or legal requirements. For UK public sector sites, check the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 for required steps and the accessibility statement.

What to record before testing

• The list of URLs or site sections
• Target WCAG level
• Devices and browsers to test
• Assistive technologies to use
• Stakeholders and deadline

Step 2 — Crawl and inventory

Run a site crawl to collect pages, images, PDFs and other assets. Use your CMS sitemap, a crawler or a manual list. Export the list into a spreadsheet. Flag templates and repeated components such as headers, footers and navigation. Testing templates reduces duplicate work.

Step 3 — Automated testing

Automated tools catch many issues quickly. Use them first to build a baseline. Expect automated tools to find about 20% to 40% of problems. They will not find all issues, especially semantic or usability problems.

Common automated checks

• Colour contrast failures
• Missing alt attributes on images
• Missing form labels
• Broken ARIA attributes
• Missing lang attribute

Recommended tools

• axe or axe Core (browser extension)
• Lighthouse (built into Chrome DevTools)
• WAVE (visual overlay)
• Colour contrast analysers and browser extensions

Step 4 — Manual testing: keyboard and focus

Automated checks miss keyboard and focus behaviour. Run a keyboard-only test across templates and critical user journeys.

Keyboard test script

1. Tab through the page from the first focusable element.
2. Confirm the visible focus indicator appears and is clear on all interactive items.
3. Open and close menus using keyboard only.
4. Use Enter or Space to activate buttons and links.
5. Use Shift+Tab to move focus backwards and check focus order.
6. Complete a form with only the keyboard and submit it.

What to watch for

• Trapped focus in dialogs or components
• Invisible or tiny focus outlines
• Non-interactive elements that receive focus

Step 5 — Manual testing: screen reader checks

Screen reader testing finds semantic and content issues. Test using at least one desktop and one mobile screen reader. Focus on real user journeys such as search, checkout or form completion.

Screen reader checklist

• Page language is announced correctly
• Headings form a logical outline
• Images have correct alternative text
• Form controls have labels and clear error messages
• Landmarks and ARIA roles help navigation
• Dynamic content uses appropriate ARIA live regions

Step 6 — Content checks: text, headings and images

Review content for clarity and accessible alternatives. Check headings, lists and link text. Confirm images, charts and infographics have descriptive alt text or long descriptions where needed.

Content to verify

• Descriptive link text, not “click here”
• Heading hierarchy: H2 then H3 etc
• Meaningful alt attributes on decorative images left empty (alt=“”)
• Accessible captions and transcripts for audio and video

Step 7 — Forms and error handling

Forms are a frequent barrier. Test labels, fieldsets, required fields and validation messages. Ensure errors are programmatically associated with the fields and are keyboard reachable.

Form test points

• Every input has a label or aria-label
• Error messages are linked to inputs with aria-describedby or aria-invalid
• Instructions are placed before fields, not only in placeholder text

Step 8 — ARIA, semantics and landmarks

Use semantic HTML first. Apply WAI-ARIA only when native elements cannot provide the required role or behaviour. Incorrect ARIA can harm accessibility.

Useful checks

• Landmarks exist for main, navigation, complementary and search
• Buttons use <button> not <div role=“button”>
• ARIA attributes match the UI state (aria-expanded, aria-hidden)

Step 9 — Multimedia and documents

Check captions for video and transcripts for audio. For PDFs and other fixed documents, use a tool that inspects tagging and text order. If documents are required to be accessible, include an accessible HTML alternative when possible.

Step 10 — Mobile accessibility

Test on touch devices and small screens. Check touch target sizes, zoom and responsive reflow. Confirm that gestures are not the only way to access content.

Step 11 — Performance, timing and cognitive accessibility

Fast, predictable interfaces help many users. Check timeouts and provide controls when content updates automatically. Use plain language and clear instructions. Provide options to simplify complex pages or reduce distractions.

Step 12 — Document findings and score conformance

Create a clear audit report. For each issue include page or template, WCAG criterion, screenshots, steps to reproduce and suggested fix. Score each issue by severity and provide a compliance summary for stakeholders.

Suggested report fields

• Issue ID
• Page or component
• WCAG reference
• Automated or manual
• Severity
• Suggested remediation
• Status

Prioritise fixes: an impact versus effort approach

Prioritise by user impact and estimated developer effort. Use four bands: High impact low effort, High impact high effort, Low impact low effort, Low impact high effort. Fix High impact low effort items first. Examples: missing alt text is usually low effort and high impact. Complex ARIA widgets may be high effort and high impact.

Priority	Example	Action
High	Images missing alt text on product pages	Fix within sprint, release as patch
Medium	Forms with unclear error associations	Plan in next feature cycle
Low	Minor colour contrast issues in decorative UI	Bundle with design refresh

Retest and continuous checks

After fixes, retest the affected pages. Add automated checks to CI or QA where possible. Schedule periodic manual audits for new features and templates.

Common mistakes to avoid (information gain)

Many audits focus too much on automated results. They miss keyboard behaviour and real user flows. Another mistake is overusing ARIA instead of fixing the HTML. Finally, avoid treating the audit as a one-off. Accessibility needs continuous attention.

Quick audit checklist (printable)

• Document scope, standards and sample pages
• Run automated scans and save results
• Keyboard test main journeys
• Screen reader test templates and forms
• Check colour contrast and responsive reflow
• Inspect PDFs and multimedia for alternatives
• Log issues with WCAG references and remediation
• Prioritise fixes by impact and effort
• Retest and add checks to CI

How long does an accessibility audit take

Time depends on site size and complexity. A small site or a handful of templates can take a few days. A large site or an enterprise product may take several weeks. Allow time for stakeholder reviews and remediation verification.

Final notes on reporting to stakeholders

Keep the report actionable. Use screenshots and short reproduction steps. Give clear priorities and a simple compliance summary for non-technical readers. Offer a remediation plan with estimated effort and owner.

Next steps

Start with a crawl and a quick automated scan. Then run the keyboard script and at least one screen reader test on key pages. Use the prioritisation approach to plan fixes and put automated checks into your QA process.

End of guide.