How We Run an Accessibility Audit, Start to Finish

Most audit providers do not explain their process in detail. You send a brief, receive a quote, wait a few weeks, and get a PDF. We think you should know exactly what happens between those steps, because understanding the process helps you get more value from it.

Here is how we run an accessibility audit at Livana, from first conversation to final verification.

Phase 1: Scoping

Every audit starts with understanding your site and your users. We meet with your team to discuss: what the product does, who uses it, which user flows are critical to the business, and what accessibility work (if any) has been done previously.

We identify the page sample together. For a 50-page site, we do not test all 50 pages. We select a representative sample covering every distinct page template, every critical user flow, and any pages your team suspects might have issues. A typical sample for a medium site is 15-25 pages.

We agree on scope: which WCAG version and conformance level (almost always WCAG 2.2 AA), which assistive technologies to test with, and which browsers and devices to include. We set a timeline and confirm deliverables.

This phase usually takes one or two calls and a few days of back and forth. Getting the scope right matters. An audit of the wrong pages wastes everyone's time.

Phase 2: Automated scanning with Lumi

Before any human touches the site, we run a full automated scan using Lumi. This runs five accessibility engines simultaneously: axe-core, HTML_CodeSniffer, keyboard tests, proprietary checks, and AI visual analysis.

The scan produces a baseline score and identifies every issue that machines can catch: missing alt text, colour contrast failures, broken ARIA attributes, empty links, missing form labels, heading hierarchy problems, and duplicate IDs.

We do this first for two reasons. It catches the low-hanging fruit so our auditors can focus their time on the harder issues. And it gives us a quantitative baseline to compare against after remediation.

The scan results go directly into Lumi as the first batch of findings. Your team can start fixing these immediately, before the manual audit is complete.

Phase 3: Manual testing

This is where the real work happens. A trained auditor works through every page in the sample and every user flow in the scope, using assistive technology the way your users do.

Keyboard testing. We navigate the entire site using only the keyboard. We check that every interactive element is reachable, that focus order is logical, that focus indicators are visible, and that there are no keyboard traps. We test custom widgets, modals, dropdowns, and any interactive component.

Screen reader testing. We test with NVDA on Chrome (Windows), JAWS on Edge (Windows), and VoiceOver on Safari (macOS). Each screen reader handles ARIA and HTML differently, so issues that appear in one may not appear in another. We listen to the full experience: page structure announcements, form interactions, error messages, dynamic content updates, and navigation landmarks.

Voice control testing. We verify that all interactive elements can be activated by voice commands, that visible labels match accessible names, and that the site works with Dragon NaturallySpeaking.

Cognitive accessibility review. We assess reading level, information density, consistency of navigation and help mechanisms, error recovery, and whether timeouts are reasonable. This is the most subjective part of the audit and draws heavily on auditor experience.

Magnification and reflow testing. We test at 200% and 400% zoom to verify that content reflows correctly, that no information is lost, and that horizontal scrolling is not required at 320px viewport width.

Manual testing typically takes five to ten business days depending on scope. Each finding is documented with: the WCAG success criterion it fails, the severity (critical, major, minor), a description of the issue, steps to reproduce, a screenshot or screen reader output recording, and recommended remediation.

Phase 4: Findings delivered as tickets in Lumi

This is where we differ from most auditors. We do not hand you a 200-page PDF and wish you luck.

Every finding from the manual audit is entered into Lumi as a structured ticket. Each ticket includes the WCAG criterion, severity, page URL, description, evidence, and remediation guidance. Tickets are tagged by component and by WCAG principle, so your team can filter and prioritise.

The automated scan findings from Phase 2 are already there. The manual findings join them. Your entire accessibility backlog lives in one place, alongside your baseline score and progress tracking.

We have seen too many audits where a detailed PDF report goes into a shared drive and nothing changes. Delivering findings as tickets removes the translation step. Your developers can pick up a ticket, understand the issue, and fix it without needing to cross-reference a document.

Phase 5: Remediation support

After delivering findings, we do not disappear. We make ourselves available for questions as your team works through the backlog.

This is not a separate consulting engagement. It is part of the audit. Developers often need clarification on ARIA patterns, help choosing between implementation approaches, or a second opinion on whether a fix actually resolves the issue. We are there for that.

For clients who want hands-on remediation, we offer a separate engagement where our developers make the fixes directly. But most teams prefer to fix issues themselves with our guidance, which builds internal capability.

Phase 6: Verification re-scan

Once your team has addressed the findings, we re-test. This is not a full repeat of the audit. We specifically verify that each reported issue has been resolved and that the fixes have not introduced new problems.

We re-run the Lumi automated scan to update your baseline score and manually verify a sample of the fixed issues. Any remaining or new issues are documented as new tickets.

The re-test typically takes 20-30% of the time of the original audit. It gives you confidence that the work is done and provides evidence of conformance if you need it for regulatory, procurement, or legal purposes.

Why this process matters

The difference between a good audit and a checkbox exercise comes down to what happens after the report. Findings that sit in a PDF do not make your site more accessible. Findings that arrive as prioritised, actionable tickets in a tool your team already uses have a much better chance of getting fixed.

That is why we built the audit process around Lumi. The scanning tool and the audit methodology work together. Automated monitoring catches regressions between audits. Annual manual audits catch the issues automation cannot. The cycle is continuous, not one-off.

If you are considering an audit, get in touch. We will scope it properly, test it thoroughly, and deliver findings your team can actually act on.