WCAG 2.2 Compliance Checklist for Small Business Websites in 2026

If your small business website was built to WCAG 2.1 standards, it is no longer fully current. WCAG 2.2 became a W3C Recommendation in October 2023, adding nine new success criteria and formally removing one (4.1.1 Parsing). By 2026 it is the version regulators, procurement teams, and plaintiff attorneys reference when they evaluate whether a site is accessible. For a small business, that shift is not academic: the majority of ADA web accessibility demand letters target restaurants, clinics, retailers, and service firms precisely because their sites are easier targets than enterprise properties with dedicated accessibility teams.

The good news is that WCAG 2.2 is backward compatible. Everything you did for 2.1 Level AA still counts, so this is an incremental upgrade rather than a rebuild. This checklist walks through what actually changed, the criteria most likely to trip up a small business site, and a realistic order of operations for reaching and documenting Level AA conformance without hiring a full-time specialist.

Treat the sections below as a working punch list. You do not need to memorize criterion numbers, but you should be able to point to each item and say either "we pass this" or "here is our remediation date."

What Changed From WCAG 2.1 to WCAG 2.2

WCAG 2.2 keeps the same three conformance levels (A, AA, AAA) and the same POUR principles (Perceivable, Operable, Understandable, Robust). Almost every U.S. accessibility obligation, including the DOJ's 2024 Title II rule for state and local governments, targets Level AA, so that remains your goal. The practical delta is nine new criteria, six of which fall at Level A or AA and therefore matter for compliance:

• 2.4.11 Focus Not Obscured (Minimum) — AA: When a component receives keyboard focus, it must not be entirely hidden behind sticky headers, cookie banners, or chat widgets.
• 2.4.12 Focus Not Obscured (Enhanced) — AAA: A stricter version requiring no part of the focused item to be hidden.
• 2.4.13 Focus Appearance — AAA: Specifies minimum size and contrast for the focus indicator itself.
• 2.5.7 Dragging Movements — AA: Any drag action (sliders, map panning, drag-and-drop) needs a single-pointer alternative like tap or click.
• 2.5.8 Target Size (Minimum) — AA: Interactive targets must be at least 24 by 24 CSS pixels, or have adequate spacing around them.
• 3.2.6 Consistent Help — A: If you offer help (phone number, chat, contact link), it must appear in the same relative location across pages.
• 3.3.7 Redundant Entry — A: Do not force users to re-enter information they already provided in the same process (for example, repeating a shipping address at checkout).
• 3.3.8 Accessible Authentication (Minimum) — AA: Login must not depend solely on a cognitive test like remembering a password or solving a puzzle CAPTCHA; allow copy-paste, password managers, or an alternative.
• 3.3.9 Accessible Authentication (Enhanced) — AAA.

The removal of 4.1.1 Parsing reflects that modern browsers handle malformed HTML gracefully; you no longer need to chase every duplicate ID or unclosed tag for conformance, though clean markup still helps assistive technology.

The New WCAG 2.2 Criteria That Bite Small Business Sites First

In real remediation work, a handful of the new criteria account for most small business failures. Prioritize these:

• Target Size (2.5.8): Tiny social icons in footers, closely stacked mobile menu items, and small "x" close buttons on popups frequently fail the 24px rule. Audit every tap target on mobile first.
• Accessible Authentication (3.3.8): If your site uses a puzzle CAPTCHA or blocks password-manager autofill on a customer login or account portal, you likely fail. Switch to reCAPTCHA v3, hCaptcha's accessibility cookie flow, email magic links, or simply allow paste.
• Focus Not Obscured (2.4.11): Sticky headers are everywhere on small business sites. Tab through your pages; if a focused link disappears under the header, add scroll-padding or adjust the sticky offset.
• Dragging Movements (2.5.7): Testimonial carousels and image sliders that only respond to swipe or drag need visible previous/next buttons.
• Redundant Entry (3.3.7): Multi-step booking and checkout forms should pre-fill or offer a "same as" option for repeated fields.

None of these require a redesign. They are targeted CSS, markup, and configuration changes that a competent developer can knock out in a focused sprint. If you would rather hand it off, our WCAG accessibility services team handles this exact scope for small business sites.

Carry-Over WCAG 2.1 AA Criteria You Still Must Meet

WCAG 2.2 is additive, so the older Level A and AA criteria still form the bulk of your obligation, and they are also where most day-to-day failures live. Do not let the shiny new criteria distract you from the fundamentals:

• Text alternatives (1.1.1): Every meaningful image needs descriptive alt text; decorative images get empty alt attributes so screen readers skip them.
• Color contrast (1.4.3): Body text needs a 4.5:1 ratio against its background; large text needs 3:1. Light gray text on white is the single most common failure.
• Keyboard operability (2.1.1): Every function must work without a mouse, and focus must never get trapped in a widget.
• Visible focus (2.4.7): Never remove focus outlines with outline: none unless you replace them with something equally visible.
• Labels and instructions (3.3.2): Form fields need programmatically associated labels, not just placeholder text.
• Name, role, value (4.1.2): Custom components (dropdowns, modals, tabs) need correct ARIA so assistive tech announces them properly.

If you are commissioning a new build rather than remediating, insist that accessibility is baked into the website development process from the wireframe stage. Retrofitting is always more expensive than building it right the first time.

How to Test Your Site: A Practical Workflow

Automated tools catch roughly 30 to 40 percent of issues; the rest require human testing. Use a layered approach:

• Automated scan: Run a free tool like axe DevTools, WAVE, or Lighthouse's accessibility audit on your top ten pages (home, services, contact, checkout, booking). Fix what it flags, but understand it is only a first pass.
• Keyboard-only test: Unplug your mouse. Tab through every page. Can you reach and activate every link, button, and form field? Does focus stay visible and never get obscured or trapped? This single test surfaces most 2.2 focus and operability issues.
• Screen reader test: Turn on VoiceOver (Mac) or NVDA (Windows, free) and navigate your key flows. Listen for unlabeled buttons, images announced as "image" with no description, and forms that make no sense.
• Mobile target check: On an actual phone, try to tap every small control. Anything that requires precision or a second attempt likely fails 2.5.8.
• Zoom test: Zoom the browser to 200 percent and confirm nothing overlaps, gets cut off, or requires horizontal scrolling.

Document each test with a date and a pass/fail note. That record becomes your evidence of good-faith effort if a complaint ever arrives.

Prioritizing Fixes When You Cannot Do Everything at Once

Most small businesses cannot remediate an entire site in a week. Sequence the work by risk and reach:

• First, fix blockers on money pages. Anything that stops a user from contacting you, booking, or checking out is both a legal risk and lost revenue. Keyboard traps, unlabeled form fields, and inaccessible CAPTCHAs go to the top.
• Second, fix site-wide issues. A contrast problem in your global header or a too-small footer icon affects every page, so a single fix has outsized impact.
• Third, address the new 2.2 criteria. Target size, focus obscuring, and dragging alternatives, in that order of typical prevalence.
• Fourth, handle content-level items. Alt text on blog images, heading structure, and link text can be worked through page by page over time.

Avoid overlay widgets as a shortcut. Third-party "accessibility overlays" that promise instant compliance with one line of JavaScript have been named in a growing number of lawsuits and are widely rejected by the disability community. They do not fix underlying code and can actively interfere with real assistive technology. Fix the source instead.

Documenting Conformance and Staying Compliant Over Time

Accessibility is not a one-time project because your content changes constantly. Build it into operations:

• Publish an accessibility statement that names WCAG 2.2 Level AA as your target, describes how users can report problems, and gives a real contact method. This demonstrates good faith and is expected under most standards.
• Create a VPAT or conformance report if you sell to government, healthcare, or education buyers; they increasingly require it in procurement.
• Train whoever adds content on the basics: alt text, meaningful link text, proper heading order, and not pasting inaccessible tables or color-coded information.
• Re-audit on a schedule and after any major redesign, new plugin, or new form. Put a quarterly accessibility check on the calendar.

WCAG 2.2 compliance for a small business is achievable and, once the initial remediation is done, inexpensive to maintain. Work through this checklist, keep records of your testing, and treat accessibility as an ongoing part of running the site rather than a box to check once. If the scope feels overwhelming, an accessibility-focused audit will give you a prioritized, criterion-by-criterion remediation plan you can execute in stages.