A website accessibility audit tests a site against the Web Content Accessibility Guidelines, the internationally recognised benchmark for digital accessibility, and turns the gaps into a plan you can act on. The recommended target is WCAG 2.2 Level AA, which the Australian Human Rights Commission treats as the benchmark for non-discriminatory digital services under the Disability Discrimination Act. A proper audit hands you three things: findings mapped to specific WCAG criteria, a remediation plan ranked by impact and effort, and a way to verify the fixes actually worked.
TL;DR:
- Automated scans are effective at identifying obvious accessibility issues like missing alt text, contrast problems, and unlabelled form fields, but manual verification remains essential for true compliance.
- Testing a representative sample of pages, including high-traffic templates and critical user flows, provides a reliable basis for measuring overall site accessibility without exhaustive page-by-page checks.
- Accessibility fixes should prioritize high-impact, high-effort issues such as login and checkout forms, with a focus on integrating standards into ongoing development rather than one-time audits.
- Training for developers, designers, and auditors should include practical experience with assistive technologies, component libraries, and WCAG sampling to ensure effective remediation.
- Meeting WCAG 2.2 Level AA is closely linked to better SEO, site speed, and usability for all users, making accessibility a key component of overall website performance.
Table of Contents
- Running a website accessibility audit: automated testing first
- How do you manually test a website for accessibility?
- Scoping the audit: how many pages do you actually need to test?
- Which accessibility audit tools should you actually use?
- Turning audit findings into a remediation plan that gets fixed
- Making accessibility part of the build, not a one-off event
- What does an accessibility audit look like in practice?
- Why user testing with people with disabilities matters
- Setting accessibility goals and success criteria
- Training auditors and developers to actually understand accessibility
- Does accessibility actually improve SEO?
- Where most accessibility audits go wrong
- How Avestaagency approaches accessibility and performance together
- Where to check the standards yourself
- Sources
- FAQ
Running a website accessibility audit: automated testing first
Automated scanners are the fastest way to find the obvious problems. Tools built on rulesets similar to axe-core or WAVE reliably catch missing alt text, insufficient colour contrast, unlabelled form fields, empty links, and broken heading structure. They cannot judge whether an interaction actually makes sense to a screen reader user, which is why automated results should be treated as triage, not a verdict.
A scan run across a template library rather than every single page tells you more, faster. Run it site-wide once to map the scale of the problem, then run targeted spot checks after every release on the templates that changed.
A few things trip teams up when they read scan output for the first time:
- False positives on contrast checks when text sits over a background image or gradient.
- Alt text flagged as "present" even when it says something useless like "image1.jpg".
- ARIA attributes marked valid by the tool but used incorrectly for the actual widget behaviour.
- Dynamic content that loads after the scan finishes, so it never gets tested at all.
Pro Tip: Export scan results into a spreadsheet and group them by WCAG success criterion before you touch a line of code. It stops the same underlying bug from being logged fifteen times as fifteen separate tickets.
Automated tools are essential for scale, but manual verification is what turns a scan into a genuine compliance check rather than a false sense of security.
How do you manually test a website for accessibility?
Manual testing catches what scanners cannot: whether a real person using a keyboard or a screen reader can actually complete a task. Run these checks in order:
- Unplug the mouse. Tab through the entire page. Every interactive element (links, buttons, form fields, custom widgets) needs a visible focus indicator and a logical tab order that matches the visual layout.
- Check for keyboard traps. Modals, date pickers, and custom dropdowns are the usual suspects. If you can't Tab or Escape your way out, that's a hard fail.
- Turn on a screen reader. NVDA on Windows or VoiceOver on macOS are the two most common starting points. Listen for whether headings, landmarks, and form labels are announced in a way that makes sense out of context.
- Test dynamic content specifically. Trigger form errors, loading states, and toast notifications while the screen reader is running. If nothing gets announced, users relying on assistive technology never know what happened.
- Log every finding against a WCAG success criterion, with the exact steps to reproduce it and the assistive technology used.
Screen reader testing takes patience. Listen for whether a button says "submit" or just "button", whether an image carousel announces its position, and whether error messages get read aloud the moment they appear on screen.
Scoping the audit: how many pages do you actually need to test?
You don't need to test every page on the site, and trying to is usually a waste of budget. The WCAG Evaluation Methodology sets out a five-step process: define the scope, explore the site's structure, select a representative sample, evaluate that sample against WCAG, and report the findings with enough detail to be defensible.
Sampling works because most accessibility problems live at the template level, not the individual page level. Fix the header navigation once and you've fixed it across every page that uses it.
A solid sample mixes two approaches:
- Structured sampling covering every distinct page template: homepage, category page, product page, article page, contact form.
- Random sampling of individual pages within high-traffic templates, to catch content-specific issues a template check would miss.
Prioritise checkout flows, login and account creation, contact and enquiry forms, and any page carrying video or audio. These are the journeys where an accessibility failure stops someone from completing a transaction, not just reading content. How you sample also shapes what you can honestly claim afterwards. A conformance statement built on three cherry-picked pages does not hold up under scrutiny; one built on a WCAG-EM-aligned sample does.
Which accessibility audit tools should you actually use?
Different roles need different tools, and buying one scanner and calling it done is a common mistake. The W3C's evaluation tools list is the closest thing to an authoritative directory, and it groups tools into categories worth knowing:
- Browser extensions (for quick, page-by-page checks during design review or QA).
- Site crawlers that scan hundreds of pages and flag patterns at scale.
- CI/CD-integrated tools that run automated checks on every pull request.
- Report generators that translate raw scan data into a document stakeholders can read.
- Assistive-technology emulators, useful for developers who don't have a screen reader set up locally.
A workable audit workflow looks like this: run an automated crawl across the sample, prioritise the output by severity, validate the highest-priority items manually with keyboard and screen reader testing, then compile everything into a single report.
One thing worth checking before you buy anything: is the tool itself accessible? Vendors who can't demonstrate their own dashboard works with a keyboard are a warning sign about how seriously they take the space.
Turning audit findings into a remediation plan that gets fixed
A report full of WCAG citations means nothing to a developer if it doesn't tell them what to fix first. Structure the report around four things:
- An executive summary stating the conformance target, the sample tested, and the overall pass rate by principle (perceivable, operable, understandable, robust).
- A prioritised issue list, ranked by impact multiplied by effort. A missing form label affecting every checkout attempt outranks a decorative icon missing alt text, even though both are technically WCAG failures.
- Acceptance criteria for each fix, written so a developer knows exactly what "done" looks like and a tester can verify it without guessing.
- A regression test list, so the next release doesn't quietly reintroduce the same bug.
Timeline estimates depend heavily on how the codebase is built. A design system with reusable components can fix a contrast issue once and have it propagate everywhere; a page built from one-off custom markup means fixing the same bug dozens of times. Flag which category each finding falls into, because it changes the resourcing conversation with leadership entirely.
Making accessibility part of the build, not a one-off event
Audits done once a year and then filed away don't hold up. The Australian Human Rights Commission's own guidance frames accessibility as an ongoing commitment, not a single project milestone.
Build it into the process instead:
- Set accessibility standards at the component level, so a button or form field only needs fixing once across the whole design system.
- Gate pull requests with automated accessibility checks in CI/CD, failing the build on new critical errors.
- Add accessibility clauses to procurement and vendor contracts, requiring WCAG 2.2 AA conformance and evidence of testing before sign-off. The AS EN 301 549 standard is the reference most government and enterprise contracts point to.
- Schedule a full re-audit every 12 months, with lighter spot checks after every major release.
What does an accessibility audit look like in practice?
A typical agency-run audit moves through scoping, automated scanning, manual verification, and a final report with sign-off criteria. Clients generally want to know three things afterwards: how many defects closed, whether conversions moved, and whether the fixes held up under a follow-up spot check.
The real test of an audit isn't the length of the findings document. It's whether the development team can pick up the report and start fixing things without asking a single clarifying question.
Avestaagency's project work, including case studies on the portfolio, shows how performance and usability fixes tend to move together when a site gets rebuilt properly.
Why user testing with people with disabilities matters
Passing every automated check and every manual keyboard test does not guarantee a site is actually usable. The Human Rights Commission's own guidance makes the point directly: meeting WCAG is necessary but not sufficient for a genuinely good experience.
Real user testing surfaces problems no checklist catches. A screen reader user might technically be able to complete a checkout form that passes every automated rule, but if the flow takes four times longer than it should because of confusing focus jumps, that's a usability failure hiding behind a compliance pass.
Recruit a small panel across different disability types and assistive technologies: screen reader users, people using switch access or voice control, people with low vision using screen magnification, and people with cognitive disabilities who rely on clear, simple layouts. Five to eight participants across varied technology setups will surface most major usability barriers.
Run tasks that mirror real goals: find a product, complete a purchase, contact support, book an appointment. Watch where people hesitate, backtrack, or give up, not just where they technically succeed. Pair this with your WCAG audit rather than replacing one with the other. Automated and manual technical testing tells you where the code fails a rule. User testing tells you where the experience fails a person, even when the code technically passes.
Setting accessibility goals and success criteria
Vague goals like "make the site accessible" don't survive contact with a development backlog. Set a specific conformance target instead: WCAG 2.2 Level AA, across a defined sample of pages, verified by a specific date.
Break that target into measurable success criteria a team can actually track:
- Conformance rate by WCAG principle, tracked before and after remediation.
- Zero critical defects in checkout, login, and enquiry forms, since these carry the highest legal and commercial risk.
- Time-to-fix for newly discovered issues, so accessibility debt doesn't quietly accumulate the way technical debt does.
- Regression rate, meaning how often a previously fixed issue reappears in a later release.
Set the target before the audit starts, not after you see the results. Teams that wait to see how bad the findings are before deciding what "good enough" means tend to negotiate the target downward instead of fixing the actual problem. WCAG 2.2 AA is deliberately the recommended baseline, and it's backwards compatible with earlier WCAG 2.x versions, so meeting it also satisfies older contractual references to WCAG 2.0 or 2.1.
Review progress against these criteria monthly during active remediation, then quarterly once the backlog stabilises. A goal with no review cadence is just a wish.
Training auditors and developers to actually understand accessibility
An audit is only as good as the person running it, and a remediation plan is only as good as the developers implementing it. Both sides need training that goes beyond a one-hour compliance webinar.
Auditors need hands-on practice with at least one screen reader (NVDA is free and widely used for Windows testing), enough familiarity with ARIA to spot when it's misused rather than missing, and a working understanding of WCAG-EM's sampling logic so their conformance statements hold up under scrutiny.
Developers need something more specific: accessible patterns baked into the component library they already use, so doing the right thing is the path of least resistance rather than an extra step they have to remember. Pair that with code review checklists that flag common failures, missing labels, poor focus management, colour used as the only signal, before a pull request merges.
Design teams need training too, and it's often skipped. Contrast ratios, touch target sizing, and error state design all get decided in Figma long before a developer touches the code. A designer who understands WCAG 2.2's target sizing requirements saves the development team from reworking a whole component library later.
The cheapest training exercise is often the most effective: have every team member navigate your own site using only a keyboard for fifteen minutes. Most people who build interfaces have never done it once.
Does accessibility actually improve SEO?
Yes, and the overlap is bigger than most teams expect. Search engines and screen readers rely on the same underlying signals: clear heading structure, descriptive link text, alt text on images, and a logical reading order in the HTML. Fix a page for accessibility and you've usually improved how a search engine crawls and understands it too.
Semantic HTML is the clearest example. A page built with proper heading tags, landmark regions, and list markup helps a screen reader announce structure correctly, and it helps a search engine parse the page's hierarchy the same way. Alt text serves an identical dual purpose: a screen reader user hears a description of the image, and an image search algorithm gets context it otherwise wouldn't have.
Page speed is where the connection surprises people. Accessible sites tend to avoid the bloated, JavaScript-heavy interactive patterns that hurt both screen reader compatibility and load times. A site that's genuinely accessible is very often also a site that's leaner and faster, and site speed remains a factor in both search rankings and conversion rates.
Usability for everyone improves too. Larger touch targets, better contrast, and clearer form labels reduce friction for every visitor, not just those using assistive technology. Treating an accessibility audit purely as a legal or compliance exercise misses the commercial upside sitting right next to it.
Where most accessibility audits go wrong
Accessibility isn't a box you tick once and file away. It's ongoing, and the two most common failure modes sit at opposite ends of the effort spectrum: teams that try to manually test every single page and burn out before they finish, or teams that run one automated scan, see a clean report, and assume the job's done.
Neither works. Representative sampling exists precisely because exhaustive manual testing doesn't scale, and automated tools exist precisely because they can't judge real usability. The teams that get this right treat the audit as the start of a process, not the end of one, and they get leadership to sign off on ongoing budget before the first report even lands. Culture beats compliance checklists every time. A team that understands why a focus order matters will catch problems a checklist never anticipated.
— Armin
How Avestaagency approaches accessibility and performance together
Avestaagency treats an accessibility audit as part of a broader performance conversation, not a separate compliance chore bolted onto a finished website. If your site needs remediation work, that usually touches the same layers Avestaagency already works in: web development to fix markup and component structure, UI/UX design to rework contrast and focus states properly rather than patching them, and performance and SEO auditing to catch the overlap between accessibility fixes and site speed.
Projects handled by senior engineers directly, with no junior hand-offs, tend to receive detailed attention, which matters when the fix involves something as fiddly as correct ARIA usage or keyboard focus management. Agencies often take on a limited number of clients at a time to provide this level of engagement, backed by ongoing support once audit findings are closed out. If you're weighing up whether to fix accessibility issues in-house or bring in a team that's already built the fixes before, start with a look at Avestaagency's services and get a scope for your site.
Where to check the standards yourself
For the source documents rather than a summary of them: the WCAG 2.2 specification sets out every success criterion and conformance level. The WCAG-EM methodology covers sampling and reporting in full. The Australian Human Rights Commission's guidance covers AS EN 301 549 and Digital Service Standard references, and the W3C tools list is the place to start when choosing testing software.
Sources
- Guidelines on equal access to digital goods and services (Australian Human Rights Commission)
- Web Content Accessibility Guidelines (WCAG) 2.2
FAQ
Is WCAG a legal requirement in Australia?
WCAG conformance itself isn't written into legislation by name, but the Disability Discrimination Act prohibits discrimination in the provision of goods and services, including digital ones. The Australian Human Rights Commission recommends WCAG 2.2 Level AA as the practical way to demonstrate you're meeting that obligation.
How can I test the accessibility of a website?
Combine an automated scan to catch obvious technical issues with manual keyboard-only navigation and screen reader testing using NVDA or VoiceOver. Following the WCAG-EM methodology for sampling pages gives you a structured, defensible way to test a whole site without checking every single page.
How do you measure website accessibility?
Measure conformance against WCAG 2.2's success criteria across a representative sample of pages, tracking pass rates by principle: perceivable, operable, understandable, and robust. Ongoing measurement should also track defect closure rate and regression rate over time, not just a single point-in-time score.
Does my website need to be WCAG compliant?
If your site provides goods, services, or information to the public, aligning with WCAG 2.2 Level AA is the recommended way to reduce discrimination risk under Australian law and to make the site usable for a wider range of visitors. It also tends to improve site speed and search visibility as a side effect, since accessible markup and clean semantic HTML serve both goals at once.
What does Avestaagency charge for an accessibility related project?
Pricing depends on the scope of the remediation work involved, whether that's a targeted fix to specific templates or a broader rebuild. Current project pricing is available directly through Avestaagency's services page.