WCAG 2.1 AA accessibility audit explained (for SMB websites)

WCAG 2.1 Level AA is the standard your website needs to meet, whatever jurisdiction you operate in. The European Accessibility Act, the Americans with Disabilities Act (Title III, as interpreted in DOJ guidance and case law), the UK Equality Act, the Accessibility for Ontarians with Disabilities Act, and most national accessibility laws all reference WCAG 2.1 AA — sometimes the more recent 2.2 — as the measurable test.

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:

• Missing or empty alt attributes on images
• 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
• Headings out of order (h1 → h3 with no h2)
• Iframes without titles
• ARIA attributes used incorrectly or on the wrong element
• Auto-playing media that cannot be paused

That covers roughly 30–40% of WCAG. The catch is that those issues account for a disproportionate share of real complaints — they are exactly the issues 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.

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. A class action against AudioEye filed in 2024 makes similar arguments. 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 reports every violation with the specific selector and a copy-paste developer fix. Multi-jurisdiction reporting is built in: the same scan generates a report against EAA, ADA, UK Equality Act, and AODA simultaneously, so you do not need separate tooling per market. Run a free scan to see your baseline.

See also: EAA compliance for SMBs: what changes June 2025 · ADA website compliance audit (USA) · What is a website compliance audit?