WCAG 2.1 AA accessibility audit explained (for SMB websites)

Level AA is the bar your website needs to clear, whatever jurisdiction you operate in. The version is where the regimes diverge, and the difference is not cosmetic. The European Accessibility Act names no WCAG version in its own text; it reaches WCAG 2.1 AA through the harmonised standard EN 301 549. The Americans with Disabilities Act (Title III) names no technical standard at all, so US settlements and case law have worked from 2.0 and later 2.1 AA as a de facto bar. The UK Equality Act 2010 names none either, although UK public-sector bodies have been monitored against WCAG 2.2 AA since October 2024. Ontario’s AODA still explicitly requires WCAG 2.0 AA (O. Reg. 191/11 §14) and has never been amended.

WCAG 2.2 AA is a strict superset of all of those, which is why it is the sensible thing to aim at and why Veracly scans against it. Which version your regulator will actually hold you to is a separate question, mapped jurisdiction by jurisdiction in WCAG 2.1 vs 2.2: which version applies to me?

A WCAG accessibility audit is the structured check that tells you how far your site is from that bar. This article explains what an audit actually does, the difference between scanning and manual review, and the five fixes that close the gap on most SMB sites.

The four WCAG principles

Every success criterion in WCAG falls under one of four principles, POUR.

• Perceivable. Users must be able to perceive the content. Text alternatives for images, captions for video, sufficient colour contrast, content that works at 200% zoom.
• Operable. Users must be able to operate the interface. Keyboard navigation, no time limits that can’t be extended, no flashes that trigger seizures, clear focus states.
• Understandable. Content and operation must be understandable. Page language is declared, navigation is consistent, errors are explained in plain language.
• Robust. Content must be robust enough for assistive technologies. Valid HTML, correct ARIA usage, status messages exposed to screen readers.

What an automated scan actually catches

A scan running axe-core (the same engine used by Deque, Microsoft, and Google’s own accessibility tools) reliably detects:

• Images with no alt attribute at all. An empty alt="" passes, because no machine can tell a decorative image from a meaningful one
• Insufficient colour contrast (text vs. background)
• Missing form labels or labels not associated with inputs
• Buttons and links with no accessible name
• Page missing a lang attribute
• Empty headings, and paragraphs styled to look like headings
• Iframes without titles
• ARIA attributes used incorrectly or on the wrong element
• Auto-playing media that cannot be paused

That is the machine-testable slice, and it is smaller than vendors imply: roughly a third of WCAG success criteria can be tested by machine at all, which is why our own report lists 29 criteria as manual-review and score-neutral. The catch that makes the slice worth running is that those issues account for a disproportionate share of real complaints — they are exactly what a screen-reader user hits in the first 30 seconds on your site.

What only manual review catches

A scanner cannot tell you whether your content is understandable. It cannot tell you whether your alt text describes the image well; only that alt text exists. It cannot tell you whether keyboard tab order makes sense; only that elements are reachable. It cannot test screen-reader announcements for content that depends on focus, live regions, or modal management.

Heading order belongs in this bucket too. axe-core can see that you jumped from an h1 to an h3, but that is a best-practice signal rather than a failure of any success criterion, so Veracly does not score it against any jurisdiction. Whether your heading structure actually describes the page is a human judgement, and no scanner makes it.

For full WCAG conformance, you need both. The realistic SMB pattern is: weekly automated scans to catch regressions, plus a one-time manual review (internal or consultant) for the issues automation misses.

The five fixes that move the needle

On most SMB sites, the same five issues account for the majority of automated violations. Fix these and the report looks dramatically different.

1. Colour contrast. Body text against background must be at least 4.5:1; large text 3:1. Most brand colour palettes have at least one combination that fails. Run every text/background pair through a contrast checker and adjust hex values; do not introduce a separate “accessibility theme.”
2. Form labels. Every <input>, <select>, <textarea> needs a <label for="..."> with matching id. Placeholder text is not a label. Aria-label is acceptable when a visible label is undesired.
3. Alt text on every meaningful image. Decorative images get alt=""; informative ones get a description; functional ones (logos that link, icon buttons) describe the action, not the image.
4. Visible focus state. Most CSS resets remove the default focus ring. Add it back. Keyboard users need to see where focus is.
5. Landmark structure and heading order. One <h1> per page; headings descend without skipping levels; <header> <nav> <main> <footer> wrap the right regions. Screen-reader users navigate by headings and landmarks.

What an audit report should give you

A useful WCAG audit report does three things:

1. Lists every violation against the specific WCAG success criterion it breaks (e.g. “1.4.3 Contrast (Minimum)”), not just “low contrast.”
2. Shows the specific element and CSS selector, copy-paste, not a screenshot you have to translate to code.
3. Provides a developer fix, not a description of the problem. “Set color: #1a1a1a” is useful; “Improve contrast” is not.

If a scanner’s report stops at the description, the fix takes a developer 10x longer than it needs to.

The accessibility-overlay trap

Overlay vendors, accessiBe, AudioEye, UserWay, EqualWeb, sell a one-line JavaScript snippet that promises to make your site WCAG compliant. The FTC fined accessiBe USD 1 million in January 2025 for misleading marketing about exactly this claim. The reasoning is consistent: overlays cannot read intent, they cannot know which buttons should announce what, which images are decorative, what tab order makes sense, so they guess, and frequently guess wrong.

For lawsuit avoidance, overlays are worse than nothing. The plaintiff bar in the US has specifically begun targeting overlay-using sites because the failure mode is so predictable.

How Veracly approaches WCAG

Veracly runs axe-core against your real DOM and scores it against the WCAG 2.2 AA superset, the 2.0, 2.1 and 2.2 A/AA rule sets run together. Every definite violation is reported with the specific CSS selector: up to three failing elements per issue on a free scan, five on a paid one.

We deliberately do not report the results axe marks needs review, because a maybe is not a finding. That decision has a real cost and you should know about it: text sitting over a photograph, a gradient, or a semi-transparent panel usually lands in that bucket rather than being called a contrast failure, so it will not appear in your report even though a human reviewer would flag it. Seven further axe-core rules score zero on purpose: four sit on criteria we have already declared manual-review, so scoring them would contradict our own disclosure, and three are already covered by an equivalent custom rule that would otherwise double-penalise the same page.

Multi-jurisdiction reporting is built in: one scan grades against every rule pack in scope for the countries you sell into, the EAA, the ADA, the UK Equality Act and, when Canada is in scope, AODA. A free scan covers one page and takes the single market you declare on the form, so it will not produce all four cards. Written developer fixes are generated on paid scans only; a free scan explains its top three findings and no more. Run a free scan to see your baseline.

See also: WCAG 2.1 vs 2.2: which applies to you? · EAA compliance for SMBs: what changes June 2025 · ADA website compliance audit (USA) · What is a website compliance audit?