WCAG 2.2 for Small Businesses: A Practical Accessibility Guide

Web accessibility used to be treated as a specialist concern for governments and large enterprises. That has changed. WCAG 2.2, published by the W3C in October 2023, is now the reference point for accessible websites, and the European Accessibility Act has applied since June 28, 2025, bringing accessibility requirements to many businesses that sell to consumers in the EU — including online shops. For a small business, the good news is that most of the work is not exotic. It is a set of sound design and development habits that also make your site easier for everyone to use. This guide explains what WCAG 2.2 asks for, what is new, where the law stands and which fixes deliver the most value for the least effort.

Why accessibility matters for a small business#

Disability is common. People with visual, hearing, motor and cognitive impairments use the web every day with screen readers, magnifiers, voice control, switch devices or just the keyboard. Many more experience temporary or situational limitations: a broken wrist, a phone in bright sunlight, a noisy train, a slow connection or simply aging eyes. When your site works for them, it works better for everyone.

There are also direct business reasons:

• More customers. Every form a keyboard user cannot complete or a checkout a screen reader user cannot navigate is lost revenue that never shows up in your analytics.
• Legal risk. Accessibility is now a legal requirement in more places and for more types of business than ever, as we explain below.
• Better SEO and UX. Clear headings, descriptive links, text alternatives and semantic markup help search engines and AI systems understand your pages. Our article on semantic HTML shows how much of this overlap is free.
• Lower maintenance cost. Accessible components built once into a design system are cheaper than retrofitting every page later.

WCAG 2.2 in five minutes#

The Web Content Accessibility Guidelines (WCAG) 2.2 are organized around four principles, often remembered as POUR:

• Perceivable — information can be perceived in more than one way: text alternatives for images, captions for video, sufficient contrast.
• Operable — everything can be operated with a keyboard and other input methods, with enough time and without triggering seizures.
• Understandable — content and interfaces are predictable, readable and help users avoid and correct mistakes.
• Robust — content works reliably with current and future assistive technologies, mainly through correct semantics.

Under these principles sit testable success criteria, each assigned a level: A (minimum), AA (the standard target) and AAA (enhanced). When laws and contracts reference WCAG, they almost always mean Level AA, which includes all A and AA criteria. WCAG versions are backwards compatible: a site that meets 2.2 AA also meets 2.1 AA and 2.0 AA. The one exception to “2.2 only adds” is that 4.1.1 Parsing was removed as obsolete, because modern browsers and assistive technologies no longer depend on it.

What is new in WCAG 2.2#

WCAG 2.2 added nine success criteria, summarized in the W3C’s What’s New in WCAG 2.2 overview. Six of them are at Level A or AA and therefore part of a normal compliance target:

Criterion	Level	What it means in practice
2.4.11 Focus Not Obscured (Minimum)	AA	A focused element must not be completely hidden by sticky headers, cookie banners or chat widgets.
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused element is hidden.
2.4.13 Focus Appearance	AAA	Focus indicators meet minimum size and contrast requirements.
2.5.7 Dragging Movements	AA	Anything done by dragging can also be done with simple clicks or taps.
2.5.8 Target Size (Minimum)	AA	Clickable targets are at least 24 × 24 CSS pixels, or spaced so they do not crowd each other, with some exceptions.
3.2.6 Consistent Help	A	Help options such as contact details or chat appear in the same relative place across pages.
3.3.7 Redundant Entry	A	Do not make people re-type information they already gave in the same process.
3.3.8 Accessible Authentication (Minimum)	AA	Logging in must not depend on memorizing, transcribing or solving puzzles, unless help or an alternative is provided.
3.3.9 Accessible Authentication (Enhanced)	AAA	As above, without the object and personal content recognition exceptions.

2.4.11 Focus Not Obscured (Minimum)#

Keyboard users need to see where they are. Sticky headers are the usual culprit: when someone tabs to a link near the top of the viewport, the browser scrolls it into view directly beneath the header. CSS has a simple fix — tell the browser how much space the sticky header occupies:

html {
  scroll-padding-top: 5rem;   /* at least the height of the sticky header */
}

:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
}

Cookie consent banners and chat bubbles that permanently cover part of the page need the same attention: make sure they can be dismissed and do not sit over focusable content.

2.5.7 Dragging Movements#

Sliders, sortable lists, kanban boards and map panning often rely on dragging, which is difficult or impossible for many people with motor impairments and for some assistive technology users. Provide a single-pointer alternative: plus and minus buttons beside a range slider, “Move up” and “Move down” buttons on sortable items, or a text input for a value. This is about pointer alternatives; keyboard operability is covered separately by 2.1.1 Keyboard.

2.5.8 Target Size (Minimum)#

Interactive targets must be at least 24 by 24 CSS pixels, unless they are spaced so that a 24-pixel circle centered on each does not overlap another target, the same function is available elsewhere, the target is a link inside a sentence, the size is controlled by the browser, or a particular presentation is essential. Small icon buttons, close buttons on pop-ups and tightly packed pagination links are typical failures. The minimum is a floor; for touch interfaces, larger targets around 44 pixels are kinder, as we discuss in our article on UX principles that move conversion rates.

3.2.6 Consistent Help#

If you offer help — a phone number, contact link, chat widget or FAQ link — on multiple pages, keep it in the same relative order on each page. People who rely on predictability should not have to hunt for help on every new screen.

The legal landscape in 2026#

The European Accessibility Act#

The European Accessibility Act, Directive (EU) 2019/882, has applied since June 28, 2025. It sets accessibility requirements for a range of products and services offered to consumers in the EU, including e-commerce services, consumer banking, e-books, electronic communications and parts of passenger transport such as ticketing. It is implemented through national laws in each member state, which also set enforcement mechanisms and penalties.

Key points for small businesses:

• Location does not exempt you. A business based outside the EU that sells covered services to EU consumers can fall within scope.
• Microenterprises providing services are exempt. A microenterprise is defined as having fewer than 10 employees and an annual turnover or balance sheet total of no more than 2 million euros. The exemption covers services, not products.
• WCAG is the practical benchmark. Compliance is generally demonstrated through the harmonized European standard EN 301 549, whose web requirements are aligned with WCAG at Level AA.
• An accessibility statement is expected. Service providers must provide information about how their service meets the requirements.

Elsewhere#

In the United States, courts have repeatedly treated business websites as subject to the Americans with Disabilities Act, and in 2024 the Department of Justice adopted WCAG 2.1 AA as the technical standard for state and local government websites under Title II. The UK’s Equality Act 2010 requires service providers to make reasonable adjustments for disabled people. Across all of these, WCAG Level AA is the common technical reference, which is why building to WCAG 2.2 AA is the most future-proof choice.

The fixes with the biggest impact#

You do not need to memorize every success criterion to make a dramatic difference. These issues account for a large share of real-world barriers, and most are cheap to fix.

Text alternatives#

Every meaningful image needs alt text that conveys its purpose in context; decorative images need an empty alt="" so screen readers skip them. Product images should describe what matters to a buyer (“Navy wool overcoat, knee length, with notched lapels”), not “image1.jpg” or “product photo”. Charts need a text summary of the insight and access to the data.

Color contrast#

Body text needs a contrast ratio of at least 4.5:1 against its background; large text (at least 18 point, or 14 point bold — roughly 24 and 18.5 CSS pixels) needs 3:1. Under 1.4.11 Non-text Contrast, icons, input borders, focus indicators and chart elements need 3:1 against adjacent colors. Never use color as the only way to convey meaning, such as red borders alone for errors.

Keyboard access and visible focus#

Unplug your mouse and try to use your site. Every link, button, menu, form control and dialog must be reachable with Tab, operable with Enter or Space, and must show a clearly visible focus indicator. The usual offenders are custom dropdowns built from div elements, mega-menus that only open on hover, modals that do not trap or return focus, and outline: none in a theme’s CSS. Native elements such as <button>, <a href> and <select> give you keyboard support for free.

Structure: headings, landmarks and links#

Screen reader users frequently navigate by headings and landmarks. Use one logical heading hierarchy, wrap regions in <header>, <nav>, <main> and <footer>, and write link text that makes sense out of context — “Download the 2026 price list (PDF)” rather than “click here”.

Zoom, reflow and motion#

Content must remain usable when text is enlarged to 200% and must reflow without horizontal scrolling at a width equivalent to 320 CSS pixels, which is what a 1280-pixel-wide window looks like at 400% zoom. Respect prefers-reduced-motion, and give users a way to pause moving content that runs for more than five seconds. Our Canvas particle animation tutorial shows how to build a decorative animation that does exactly that.

Video and audio#

Pre-recorded video with speech needs accurate captions (auto-generated captions are a starting point, not a finished product), and audio-only content such as podcasts needs a transcript.

Forms, checkouts and logins#

Forms are where accessibility failures cost the most, because they block the actions that matter: enquiries, purchases and sign-ins. Three WCAG 2.2 criteria and several older ones meet here.

Labels, instructions and errors#

Every input needs a visible, programmatically associated label. Errors must be identified in text, linked to the field and explain how to fix the problem:

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="field-error">
  Enter an email address in the format [email protected]
</p>

On submit, move focus to the first invalid field or to an error summary at the top of the form, and announce dynamic messages such as “Added to cart” with a live region so screen reader users know something happened.

3.3.7 Redundant Entry#

If a customer has already entered their shipping address, do not make them type it again as a billing address — offer a “Billing address is the same as shipping” checkbox or pre-fill the fields. The criterion allows exceptions where re-entry is essential, such as confirming a new password, where it is needed for security, or where the earlier information is no longer valid.

3.3.8 Accessible Authentication (Minimum)#

Remembering a password or transcribing a code is a cognitive function test. Logging in must not depend on one unless there is an alternative or a mechanism to help. In practice that means:

• Never block paste in password or verification code fields, and use the correct autocomplete values (username, current-password, new-password, one-time-code) so password managers and browsers can fill them.
• Offer alternatives such as email magic links, passkeys or sign-in with an existing account.
• Be careful with CAPTCHAs. At Level AA, tests based on recognizing objects or on content the user provided are permitted, but puzzles, distorted text and arithmetic challenges are not acceptable without an alternative. Invisible, risk-based bot protection avoids the problem altogether.

<label for="password">Password</label>
<input id="password" name="password" type="password"
       autocomplete="current-password">
<!-- No onpaste="return false", no "retype your password" field on login -->

On WordPress and WooCommerce, check that security plugins and checkout customizations do not quietly break these rules — our WordPress security hardening checklist shows how to strengthen logins without making them harder to use.

How to test without an expensive audit#

A formal audit by accessibility specialists is valuable for complex sites and high-risk services, but you can find and fix the majority of serious issues yourself with a short, repeatable routine.

1. Automated scan. Run a browser extension such as axe DevTools or WAVE, or the accessibility section of Lighthouse, on your key templates: home, category, product, cart, checkout, contact and a blog post. Fix everything they flag, but remember they detect only some failures.
2. Keyboard pass. Complete your most important journey — enquiry, purchase or sign-up — using only the keyboard. Note anything you cannot reach, cannot see focus on or cannot escape.
3. Zoom and reflow. Zoom to 200% and 400% in a desktop browser and confirm nothing is cut off, overlapping or requiring sideways scrolling.
4. Screen reader spot check. Use VoiceOver on macOS or iOS, or the free NVDA on Windows. Navigate by headings, list the links and complete a form. Listen for unlabeled buttons and confusing announcements.
5. Content review. Check alt text quality, link wording, heading order, captions and plain language. No tool can judge whether an alt text is actually helpful.

Why overlays are not a shortcut#

Accessibility overlay widgets promise one-line compliance by adding a toolbar or automatically “fixing” pages with JavaScript. They are tempting for a small business, but they cannot repair the underlying problems: they cannot write meaningful alt text, restructure a confusing checkout, make a custom widget keyboard-operable or caption your videos. Many disabled users report that overlays interfere with the screen readers and settings they already rely on, and installing one does not shield a business from complaints or legal claims. The budget is better spent fixing your templates, which permanently improves every page built on them.

Making accessibility stick#

Accessibility is a process, not a project. The businesses that stay accessible build it into how they work:

• Accessible components first. Buttons, form fields, menus, modals and tabs built once, correctly, and reused everywhere.
• Editor guidance. A one-page guide for whoever adds content: how to write alt text, use headings, name links and caption video.
• An accessibility statement. Describe the standard you aim for, known limitations and how people can report problems or get information in another format, as we do on our own accessibility statement.
• A feedback route that works. An email address or form that someone actually monitors, with a commitment to respond.
• Accessible data and media. Charts with text summaries and data tables, as covered in our guide to data visualization on the web.

Start where your customers act#

If accessibility feels overwhelming, start with the journeys that matter most to your business — the contact form, the product page, the checkout, the login — and make them work by keyboard, at high zoom and with a screen reader. Then build those fixes into your templates so every future page inherits them. Progress beats perfection.

Accessibility is part of how we design and build, not an afterthought bolted on at the end. If you are planning a new site, our WordPress Website Development service includes accessible templates and editor guidance, and our Website Care & Maintenance Plan keeps an eye on accessibility as your content evolves. Contact us to talk through where your site stands today.

Frequently asked questions

Which WCAG level should a small business website aim for?

Aim for WCAG 2.2 Level AA. It is the level referenced by most laws, procurement rules and standards, including EN 301 549 in Europe, and it covers the issues that most affect real users. Level AAA is not expected for entire sites, although individual AAA criteria are worth adopting where practical.

Does the European Accessibility Act apply to my business?

It can apply to businesses inside or outside the EU that offer covered products or services, such as e-commerce, to consumers in the EU. Microenterprises providing services, meaning fewer than 10 employees and no more than 2 million euros in annual turnover or balance sheet total, are exempt from the service requirements. Check your specific situation with a legal professional.

Can an accessibility overlay or plugin make my site compliant?

No tool can make an inaccessible site compliant on its own. Overlays cannot reliably fix missing labels, poor structure, keyboard traps or inaccessible checkouts, and many disabled users find they interfere with the assistive technology they already use. Fixing the underlying code and content is the only dependable route.

How much of accessibility testing can be automated?

Automated checkers are valuable for catching issues like missing alternative text, low contrast and missing form labels, but they can only detect a portion of WCAG failures. Keyboard testing, zoom and reflow checks, screen reader spot checks and human judgment about content quality are still required.

What changed between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 added nine success criteria, covering focus visibility, dragging alternatives, minimum target size, consistent help, redundant entry and accessible authentication, and removed the obsolete 4.1.1 Parsing criterion. Content that meets WCAG 2.2 also meets WCAG 2.1 and 2.0.