A website accessibility audit is the process of testing your site against a defined standard — almost always WCAG 2.2 Level A and AA — to find the specific barriers that stop disabled people from using it. Done well, an audit gives you a prioritised list of real problems and how to fix them, not a vague score. Done badly, it gives you a green checkmark that hides exactly the issues a blind or motor-impaired visitor would hit first.
This guide explains what a real audit covers, where automated scanning ends and manual testing begins, and how to get a useful first result for free. If you are doing this because of the European Accessibility Act, that legal context is covered in the EAA guide; here the focus is the testing itself.
What a website accessibility audit is measuring
Every credible audit is anchored to WCAG 2.2 and its four principles, known by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust. Those principles break down into testable success criteria — things like every image having a text alternative, every form field having a label, and the page working when a visitor zooms to 200% or navigates with the keyboard alone.
In Europe, this baseline is formalised through the harmonised standard EN 301 549, which adopts WCAG 2.2 A and AA as the technical requirement for digital products and services. So when an auditor says they are testing 'against EN 301 549' or 'against the EAA', in practice they are checking the same WCAG success criteria. There is no separate, secret checklist.
An audit produces three useful things: a list of failures mapped to specific criteria, the location of each failure (which page, which element), and a severity ranking so you fix the blockers before the cosmetic issues. A number on its own — '82% accessible' — is a headline, not an audit.
Automated vs manual testing: what each one is for
A complete audit uses both automated and manual testing, because they catch different categories of problem. Treating them as alternatives is the single most common mistake site owners make.
What automated scanning does well
An automated scanner parses your page's HTML and the accessibility tree the browser builds from it, then flags machine-detectable violations. It is fast, repeatable, and ideal for catching the high-volume, low-judgement issues that creep in as a site grows.
- Images with no
altattribute, and icons or buttons with no accessible name - Form inputs with no associated
<label>, so a screen reader announces 'edit text' with no clue what to type - Missing or skipped heading levels, a missing
<h1>, and absent page landmarks like<main> - Empty links, 'click here' link text, and duplicate
idvalues that break ARIA references - Invalid ARIA roles, a missing page language, and disabled pinch-to-zoom on mobile
Why you still need a human
Most of WCAG is about meaning and experience, which software cannot judge. A tool can confirm an image *has* alt text; it cannot tell you the alt text says 'image123.jpg' instead of describing the chart. Manual testing is where the real barriers surface.
- Keyboard operability: can you reach and use every control with Tab and Enter, is the focus ring visible, and does focus ever get trapped in a menu or modal?
- Logical reading and focus order, which a scanner cannot evaluate because it depends on what the content means
- Whether alt text, link text, and labels are actually descriptive and not just present
- Screen-reader experience: does a custom dropdown, carousel, or date picker announce its state and respond as expected?
- Whether captions, error messages, and instructions make sense to someone who cannot see colour or layout cues
What automated scans genuinely cannot catch
Being precise here matters, because over-trusting automation is how sites end up 'passing' while remaining unusable. Independent analyses consistently find that automated tools reliably detect only around a third of accessibility issues; the rest require human judgement.
Colour contrast is the clearest example of the grey zone. WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold) and for UI components and meaningful graphics, under success criteria 1.4.3 and 1.4.11. A scanner can measure contrast where it reads a solid colour value — but it often cannot judge text sitting on a background image, a gradient, or a semi-transparent overlay, where a human has to look at the rendered result. So contrast appears on both the automated and manual side of the line, depending on how the page is built.
Other things no scanner can verify: whether your error messages explain how to fix the problem, whether a video has accurate (not auto-generated) captions, whether content that moves can be paused, and whether a complex transaction like checkout can be completed end-to-end without a mouse. These are exactly the criteria that decide whether a real person can buy from you.
How to run your first audit for free
You do not need a budget or a consultant to get a meaningful first picture. A practical, no-cost first pass looks like this:
- Automated scan. Run your most important pages — home, a product or service page, and your checkout or contact form — through a free scanner. You will get the machine-detectable failures in seconds, ranked by impact.
- Keyboard test. Put your mouse away and Tab through each page top to bottom. If you cannot reach a link, lose track of where focus is, or get stuck, you have found a real, common barrier.
- Contrast and labels spot-check. Check your body text, button text, and any text over images against the 4.5:1 / 3:1 thresholds, and confirm form fields read sensibly.
- Screen-reader sanity check. Turn on VoiceOver (Mac) or NVDA (Windows, free) and listen to one key page. It is uncomfortable at first and extremely revealing.
Work through the findings with a structured list so nothing slips — the accessibility checklist maps common fixes to the criteria they satisfy. Once you have fixed the blocking issues and understand your remaining gaps, document them honestly in an accessibility statement, which is also what services in scope of the EAA are expected to publish.
When a free audit is enough — and when it isn't
For a small brochure site or a simple WordPress or Shopify store, a careful self-audit using free tools plus the manual checks above will catch the large majority of issues that matter. Most accessibility failures are common, repeated, and fixable once you know where they are.
Bring in specialists or testers with disabilities when the stakes or the complexity rise: a custom web application, a multi-step booking or payment flow, content you are legally required to make accessible, or a statement you want to defend publicly. Note too that under the EAA, microenterprises providing services — fewer than 10 staff *and* under €2,000,000 annual turnover — are largely exempt for those services, though making your site accessible still expands your audience and reduces risk. Penalties for in-scope organisations vary by member state and can reach tens of thousands of euros, so the cost of a thorough audit is usually trivial by comparison.