WCAG 2.2 for Small Business Websites: What Changed and a Practical Checklist

If your website was built or last reviewed a few years ago, it was probably checked against WCAG 2.0 or 2.1. The current version is WCAG 2.2, and it adds a handful of requirements that touch everyday things on a small business site: menus that cover the item you are tabbing to, tiny buttons on phones, login screens and contact forms that make people type the same thing twice.

This guide explains what actually changed, what the federal government's new accessibility rule for public entities does and does not cover, and gives you a practical checklist you can work through with your web person. It is general information, not legal advice.

WCAG 2.2 in one minute

• The Web Content Accessibility Guidelines (WCAG) are written by the World Wide Web Consortium (W3C). Version 2.2 became an official W3C Recommendation on 5 October 2023 (W3C: What’s New in WCAG 2.2).
• In October 2025 the W3C announced that WCAG 2.2 had also been approved as an international standard, ISO/IEC 40500:2025 (W3C announcement).
• WCAG 2.2 adds nine new success criteria. Six of them are at Level A or AA, which is the level most laws, contracts and lawsuits point to.
• One old criterion, 4.1.1 Parsing, was removed because modern browsers and assistive technology made it obsolete.
• The versions build on each other. The W3C designed 2.2 so that a site meeting it also meets the earlier 2.1 and 2.0 requirements, so aiming for 2.2 AA covers the older benchmarks too.

The six new A/AA requirements, in plain English

2.4.11 Focus Not Obscured (Minimum), Level AA

When someone moves through your page with the Tab key, the item they are on must not be completely hidden behind something else. The usual culprits are sticky headers, cookie banners and chat widgets that sit on top of the content. If a keyboard user tabs to a link and it disappears under your fixed header, that fails.

2.5.7 Dragging Movements, Level AA

Anything that requires dragging (sliders, drag-and-drop file uploads, reorderable lists, map panning) needs a simple alternative such as buttons, arrows or a plain file picker. Some people cannot hold a mouse button or a finger down while moving.

2.5.8 Target Size (Minimum), Level AA

Clickable targets should be at least 24 by 24 CSS pixels, or have enough space around them that a 24-pixel circle centered on each one would not overlap the next. There are exceptions, such as links inside a sentence. In practice this hits tiny social icons, close buttons on pop-ups, and footer links crammed together.

3.2.6 Consistent Help, Level A

If you offer help on several pages, such as a phone number, contact link, chat button or FAQ link, put it in the same relative place each time. Visitors who struggle to find things should not have to hunt for it on every page.

3.3.7 Redundant Entry, Level A

Do not make people re-type information they already gave you in the same process. Either fill it in for them or let them pick it (for example, a “billing address same as service address” checkbox). There are exceptions for security and when re-entry is essential.

3.3.8 Accessible Authentication (Minimum), Level AA

Logging in must not depend on a “cognitive function test” such as remembering a password or solving a puzzle, unless there is an alternative or help. Allowing password managers and copy-paste into password fields, offering passkeys or email login links, and avoiding text-transcription CAPTCHAs all help.

The other three new criteria (2.4.12, 2.4.13 and 3.3.9) are Level AAA, which is a higher bar most organizations treat as a goal rather than a requirement. The full list is on the W3C site.

The DOJ rule for public entities, and what it signals

In April 2024 the U.S. Department of Justice issued a rule under Title II of the Americans with Disabilities Act. It requires state and local government websites and mobile apps to meet WCAG 2.1 Level AA. That covers cities, counties, public schools, public colleges, transit agencies and similar bodies.

On 20 April 2026 the DOJ published an interim final rule pushing back the compliance dates by about a year (Federal Register notice). The technical standard did not change. The dates are now:

Who	Compliance date
State and local governments serving a population of 50,000 or more	April 26, 2027
Those serving fewer than 50,000 people, and special district governments	April 26, 2028

The DOJ has also said it may revisit the rule's details in further rulemaking, so check for updates before relying on these dates.

Does this apply to my business?

Not directly. Private businesses open to the public fall under Title III of the ADA, and the Title II rule does not apply to them. The DOJ has not set a specific technical standard for Title III websites, but its web accessibility guidance says businesses open to the public must make their websites accessible, and it points to WCAG as helpful guidance.

The rule still matters to you in three ways:

• It shows what the government considers a reasonable benchmark. When the DOJ picked a standard for public websites, it chose WCAG 2.1 AA. That is a strong hint about what “accessible” means in practice.
• If you sell to public agencies, expect the requirement in contracts. A city that has to meet WCAG 2.1 AA will need its vendors' portals, forms, documents and apps to meet it too.
• Lawsuits and demand letters do not wait for rules. Private website accessibility claims have been filed for years without a Title III technical standard.

A word about “one-line fix” widgets

Be careful with products that promise to make a site compliant automatically. In April 2025 the Federal Trade Commission finalized an order requiring accessiBe to pay $1 million over claims that its AI tool could make any website WCAG-compliant (FTC press release). Automated scanners are useful for finding problems, but real fixes happen in your site's code, content and design.

Practical WCAG 2.2 checklist for a small business site

Work through this with whoever maintains your site. Most items take minutes to test with a keyboard and a phone.

Check	How to test	Typical fix
Keyboard focus is always visible and never hidden	Tab through every page; watch for focus disappearing under sticky headers, banners or chat	Add scroll padding for sticky headers; make banners dismissible and non-overlapping
Tap targets are big enough	Use your site on a phone; look at icons, close buttons and footer links	Make targets at least 24×24 px or add spacing
Nothing requires dragging	Try sliders, uploads, carousels and maps without dragging	Add buttons, arrows or a standard file input
Help is in the same place on every page	Compare the header and footer across pages	Use one shared header/footer with phone and contact link
Forms don't ask twice	Fill out quote, booking and checkout forms	Auto-fill repeated fields or add a “same as” option
Login works with password managers	Try pasting a password; check for puzzle CAPTCHAs	Allow paste, support passkeys or email links, use a non-puzzle bot check
The basics from 2.0/2.1 still pass	Run a free checker (such as WAVE or Lighthouse) and fix what it flags	Alt text, color contrast, form labels, headings, captions

Don't forget the older basics

• Every meaningful image has alt text that says what it shows; decorative images are marked as decorative.
• Text has enough contrast against its background (4.5:1 for normal text at AA).
• Every form field has a visible label, and errors are explained in words, not just red outlines.
• Pages use real headings in order, so screen reader users can skim.
• Videos have captions; PDFs you post are tagged or have an accessible web version.
• The site still works when zoomed to 200% and on a narrow phone screen.

Keep it from slipping

Accessibility is not a one-time project. New pages, a new plugin or a new pop-up can break things that used to pass. A simple routine works for most small businesses:

1. Test every new page or feature with a keyboard and a phone before it goes live.
2. Run an automated scan monthly and fix new issues.
3. Have a person, ideally including someone who uses assistive technology, review key pages at least once a year.
4. Publish an accessibility statement with a way to report problems, and respond quickly when someone does.

If you would like ongoing scanning and fixes handled for you, our sister product ADAReady does website accessibility audits, fixes and monitoring.

How Right On Tech can help

We build and maintain websites for small and mid-size businesses around Los Angeles and the San Fernando Valley, and we test them against WCAG 2.2 AA as part of the work. If you want a second opinion on your current site or a clear list of what to fix first, get in touch or call (818) 456 0303.