Website Accessibility for Small Businesses: A Practical WCAG 2.2 Guide

Website accessibility is often treated as a legal compliance checkbox, but it's more usefully understood as good design practice that happens to also reduce legal risk. A site that's genuinely accessible works better for everyone: clearer navigation, better contrast, more forgiving forms. This guide covers what WCAG 2.2 — the current published version of the Web Content Accessibility Guidelines — actually requires, distinguished clearly from broader best practice, so you know which is which.

What WCAG 2.2 actually is, and what it isn't

WCAG (Web Content Accessibility Guidelines) is published by the W3C's Web Accessibility Initiative and organises accessibility requirements into "success criteria" at three conformance levels: A (minimum), AA (the level most commonly required by law and industry standard), and AAA (the highest, rarely required in full). WCAG 2.2 is the current published version, and it added nine new success criteria compared with WCAG 2.1, along with removing one (Parsing, 4.1.1, which became obsolete as modern browsers made it largely redundant).

Most legal accessibility requirements and industry best practice reference WCAG 2.1 or 2.2 Level AA specifically — that's the practical target for most small business websites, not full AAA compliance, which includes some criteria genuinely difficult to meet for many types of content.

It's worth understanding what a "success criterion" actually is, since the term gets used loosely. Each one is a specific, testable statement — not a vague principle — meaning a page either passes or fails it in a way that can be checked, either manually or with automated tooling. This is what distinguishes WCAG from softer accessibility advice: a criterion like 1.4.3 Contrast (Minimum) specifies an exact ratio (4.5:1 for normal text, 3:1 for large text) that can be measured directly with a contrast checker tool, rather than relying on subjective judgement about whether text "looks readable enough."

What's new in WCAG 2.2 specifically

Several of the nine new success criteria in WCAG 2.2 are directly relevant to typical small business websites:

• Focus Not Obscured (Minimum) — Level AA: when an element receives keyboard focus, it must be at least partially visible, not hidden behind a sticky header or cookie banner.
• Dragging Movements — Level AA: any drag-based interaction must have a simple non-drag alternative, relevant if your site uses drag-to-reorder or slider interfaces.
• Target Size (Minimum) — Level AA: clickable targets must meet a minimum size or have sufficient spacing, directly relevant to mobile button and link design.
• Consistent Help — Level A: if help mechanisms (contact info, chat, help links) appear on multiple pages, they must appear in the same relative location each time.
• Redundant Entry — Level A: don't ask users to re-enter information they've already provided in the same session, relevant to multi-step forms.
• Accessible Authentication (Minimum) — Level AA: login processes shouldn't require solving, recalling or transcribing something as the only way to authenticate.

Target Size deserves particular attention for most small business sites, since it directly overlaps with mobile design decisions many businesses already care about for conversion reasons, independent of accessibility. The criterion sets a minimum target size of 24 by 24 CSS pixels for most interactive elements, with specific exceptions (inline text links within a paragraph, for instance, or cases where an equivalent same-sized target is available elsewhere). A cramped mobile navigation menu or a row of tightly packed social icons in a footer are common places this criterion is quietly failed even on otherwise well-designed sites, since these elements are often designed visually first without a specific tap-target-size check applied afterward.

Want an accessibility review of your current site against WCAG 2.2 AA?

Core WCAG requirements that carry over from earlier versions

Beyond what's new in 2.2, the foundational requirements that apply to nearly every small business website include: sufficient colour contrast between text and background, meaningful alt text on informative images, keyboard-navigable interfaces (a visitor should be able to use the entire site without a mouse), properly structured heading levels that don't skip (an H1 followed directly by an H4, for example, breaks the logical structure screen readers rely on), and form fields with clearly associated labels rather than placeholder text alone.

Keyboard navigability is worth testing directly rather than assuming it works, since it's one of the easiest requirements to silently break with a modern JavaScript-heavy interface. A simple manual test: put the mouse aside entirely and try tabbing through the entire page using only the Tab and Enter keys — can every link, button, form field and interactive element be reached and activated this way, and is it always visually clear which element currently has focus? Custom-built dropdown menus, modal dialogs and carousel sliders are the most common places this breaks, since they're often built with visual mouse interaction as the only consideration during development.

Distinguishing an actual requirement from good practice

Not everything commonly recommended for accessibility is a formal WCAG success criterion — some is simply good practice that supports accessibility without being a specific testable requirement. For example, WCAG requires sufficient colour contrast (a specific measurable requirement, Level AA), but "avoid using colour as the only way to convey information" is both a WCAG requirement (1.4.1) and reinforced by broader usability best practice. Conversely, things like "write in plain language" support accessibility broadly but aren't a single specific testable success criterion in the same way contrast ratios are. Understanding this distinction helps you prioritise: meet the testable Level AA criteria first, then layer on broader best practice.

This distinction also matters for setting realistic expectations with a developer or agency: "make the site WCAG 2.2 AA compliant" is a scoped, testable engagement with a defined endpoint, whereas "make the site more accessible" is open-ended and harder to verify as complete. Where budget genuinely allows only a partial pass, prioritising the formally testable Level AA criteria first — since these are the ones most likely to be referenced in any legal or contractual accessibility requirement — is generally the more defensible approach than spreading effort thinly across both formal criteria and broader best practice simultaneously.

Common accessibility gaps found on small business websites

• Low-contrast text, especially light grey text on white backgrounds, common in minimalist design trends.
• Missing or unhelpful alt text on images, particularly on ecommerce product photos.
• Forms with placeholder text instead of real labels, which disappear once a user starts typing and aren't reliably read by screen readers.
• Small tap targets on mobile — buttons and links spaced too closely together for accurate touch interaction.
• Video content with no captions, excluding visitors who are deaf or hard of hearing, or simply browsing with sound off.
• Auto-playing carousels and sliders with no pause control, which can be genuinely disorienting for visitors with certain cognitive or attention-related conditions, and are also a formal WCAG requirement (2.2.2 Pause, Stop, Hide) when content moves or updates automatically.

A practical way to start finding these on your own site, before commissioning a full professional audit, is running an automated scanning tool (several free browser extensions exist, built on the open-source axe-core engine that many professional auditors also use as a starting point) against your key pages. It's worth being clear-eyed about the limits of automated tooling, though — industry estimates generally suggest automated tools reliably catch only around a third to half of WCAG issues, since many criteria (like whether alt text is genuinely meaningful, or whether keyboard navigation order makes logical sense) require human judgement that a script can't fully replicate. Automated scanning is a good first pass, not a substitute for a manual review, particularly for anything customer-facing and business-critical like a checkout or booking flow.

Why this matters beyond legal compliance

Accessibility improvements consistently improve the experience for all visitors, not just those with disabilities. Clear heading structure helps every visitor scan content faster. Sufficient contrast helps anyone using a phone in bright sunlight. Larger tap targets reduce mis-taps for everyone, not just users with motor impairments. Treating accessibility as a usability investment rather than purely a compliance cost tends to produce better outcomes than treating it as a checkbox exercise.

There's also a business-continuity argument worth naming directly, particularly for businesses operating across the UK, EU, US and Canada: legal exposure around website accessibility has grown steadily, with a rising volume of demand letters and litigation in several jurisdictions, particularly the US under the Americans with Disabilities Act, even though the ADA itself doesn't currently specify a technical web standard directly. Aiming for genuine WCAG 2.2 AA conformance — not as a defensive legal exercise alone, but as a real usability standard — is currently the most broadly recognised and defensible position across jurisdictions, since it's the standard most courts, regulators and accessibility statements reference when a technical benchmark is needed.

A practical starting checklist for small business sites

Let us audit your site against WCAG 2.2 AA and give you a prioritised, practical fix list.

Frequently Asked Questions

What is WCAG 2.2 and does my small business website need to comply?

WCAG 2.2 is the current published version of the Web Content Accessibility Guidelines, published by the W3C's Web Accessibility Initiative. Whether formal legal compliance applies depends on your jurisdiction and business type, but Level AA conformance is widely regarded as reasonable practice for any commercial website, independent of specific legal requirements.

What's new in WCAG 2.2 compared with earlier versions?

WCAG 2.2 added nine new success criteria compared with WCAG 2.1, including requirements around keyboard focus visibility, minimum touch target size, consistent placement of help mechanisms, and not requiring users to re-enter information already provided in the same session. One older criterion, Parsing, was removed as obsolete.

What accessibility level should a small business website aim for?

Level AA is the practical target most legal requirements and industry standards reference, rather than full Level AAA compliance, which includes some criteria that are genuinely difficult to meet for certain types of content and aren't broadly required.

What are the most common accessibility problems on small business websites?

Low-contrast text, missing or unhelpful image alt text, forms using placeholder text instead of real labels, small or closely-spaced tap targets on mobile, and video content without captions are among the most frequently found issues on small business sites. Accessible, real form labels also support well-structured quote and contact forms more broadly, since a form that's easy for a screen reader to parse is usually also easier for a sighted visitor to complete quickly.

Does improving accessibility help visitors without disabilities too?

Yes. Clear heading structure helps all visitors scan content faster, sufficient contrast helps anyone viewing a screen in bright light, and larger tap targets reduce accidental mis-taps for every mobile user, not only those with motor impairments. These same principles overlap significantly with a solid homepage structure, since clarity and ease of navigation benefit every visitor regardless of ability.