Website Accessibility: A UK Small-Business Guide to WCAG 2.2

Nearly 95% of the web fails basic accessibility checks. If your small business runs a WordPress or Shopify site, yours is likely among them — and UK law says that matters. Website accessibility is not a niche concern for government departments or large corporates. It is a legal obligation under the Equality Act 2010, a practical requirement under WCAG 2.2, and a genuine commercial advantage for any business that gets it right.

This guide explains what website accessibility actually means, what the law requires of UK businesses, which errors cause the vast majority of failures, and what you can do about it — without enterprise budgets or specialist jargon.

What Is Website Accessibility?

Website accessibility means designing and building websites so that people with disabilities can perceive, understand, navigate, and interact with them. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments who cannot use a mouse, and people with cognitive disabilities who need clear, predictable interfaces.

The governing standard is the Web Content Accessibility Guidelines (WCAG), maintained by the World Wide Web Consortium (W3C). WCAG 2.2, published as a W3C Recommendation in October 2023 and updated in December 2024, is now the current W3C Recommendation (also referenced under ISO/IEC 40500:2025). It contains 86 success criteria across 13 guidelines, organised into three conformance levels:

• Level A (32 criteria) — addresses fundamental barriers that prevent access entirely.
• Level AA (56 cumulative criteria) — covers the most significant barriers. This is the level required by virtually every accessibility law worldwide.
• Level AAA (86 cumulative criteria) — aspirational. The W3C explicitly does not recommend it as a blanket requirement.

Level AA is the target for UK businesses. It is the benchmark courts and regulators accept, and it is the standard we build to at Lightly Salted.

What about WCAG 3.0? It is still years away. According to the Accessibility Guidelines Working Group co-chair, the target for a final Recommendation is the end of 2029, with WCAG 2 remaining in force for several years after that. WCAG 2.2 Level AA is the standard for the foreseeable future.

Why It Matters in the UK — the Legal Picture

Two distinct legal frameworks govern web accessibility in the United Kingdom, and every Lightly Salted client falls under at least one.

The Equality Act 2010

The Equality Act applies to both public and private sector organisations. It prohibits disability discrimination and imposes an anticipatory duty to make “reasonable adjustments” so that disabled people are not excluded from accessing services. Websites are explicitly considered a provision of services.

The duty is anticipatory — organisations must proactively consider disabled users’ needs rather than waiting for a complaint. While the Act does not specify a technical standard, WCAG 2.1 Level AA is the de facto benchmark that courts and regulators accept.

Enforcement is real. The RNIB took action against the airline BMIbaby, resulting in the airline making its website accessible. In 2023, a settlement of £3,000 was awarded to Stephen Campbell, a blind man unable to use his screen reader on a Health and Social Care Northern Ireland recruitment website.

The Public Sector Bodies Accessibility Regulations 2018

For public sector organisations, the obligations are more specific. Following a 2022 post-Brexit amendment, these regulations now reference the latest published version of WCAG — meaning they currently require WCAG 2.2 Level AA conformance. GOV.UK guidance states plainly: “You must meet the guidance on the WCAG 2.2 AA standard.”

The Government Digital Service (GDS) monitors compliance by auditing hundreds of public sector websites annually. Unresolved failures are escalated to the Equality and Human Rights Commission for enforcement.

The bottom line: if you run a website that serves customers in the UK, accessibility is not optional.

How Bad Is the Web Today?

The WebAIM Million 2025 report tested one million home pages against WCAG 2.2 Level A and AA criteria. The results are stark: 94.8% of pages failed basic conformance checks, averaging 51 detectable errors per page.

For Lightly Salted’s clients, the sector breakdown is telling. Shopping and e-commerce was the worst-performing category at 71.2 errors per page. WordPress sites (roughly 24% of the sample) averaged 50.0 errors per page — slightly below the overall average, but performance varied dramatically by page builder. Shopify sites averaged 69.6 errors per page, a full 36.6% above the overall average.

These numbers capture only what automated tools detect — an estimated 30–40% of all WCAG issues — so the true failure rate is higher still. For UK small businesses, that is both a legal liability and a commercial differentiator. A compliant, usable website stands out from the overwhelming majority that are not.

The Six Errors That Cause 96% of Failures

The WebAIM Million 2025 report reveals that the same six error types have dominated for five consecutive years, collectively accounting for 96% of all 50.9 million detected errors. Every one of them is fixable.

1. Low Contrast Text — Found on 79.1% of Pages

Text that lacks sufficient contrast against its background is the single most common accessibility failure. WCAG 1.4.3 (Level AA) requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Light grey text on a white background, trendy as it may look, fails users with low vision and increases cognitive strain for everyone.

The fix: Check every text colour, hover state, placeholder, and form border with the WebAIM Contrast Checker or TPGi Colour Contrast Analyser. View pages in greyscale to confirm information is never conveyed by colour alone.

2. Missing Alternative Text — Found on 55.5% of Pages

When an image lacks alt text, screen reader users hear nothing or, worse, the file name. The WebAIM report found that 18.5% of all images had no alt text whatsoever. Meaningful images need descriptive alt text; decorative images need an empty alt="" attribute so screen readers skip them.

The fix: Audit every image on every template. Write concise, descriptive alt text that conveys the image’s purpose, not just its appearance. This also benefits SEO — search engines use alt text to understand image content.

3. Missing Form Input Labels — Found on 48.2% of Pages

A form field without a visible, programmatically associated <label> is unusable for screen reader users. They cannot tell what information the field expects. The GOV.UK Design System provides the gold standard: every input gets a visible label with a for attribute matching the input’s id, plus hint text associated via aria-describedby.

The fix: Check every form on your site — contact forms, search boxes, newsletter sign-ups, checkout fields. Each input must have a visible <label>. Placeholder text alone does not count.

4. Empty Links — Found on 45.4% of Pages

Links with no discernible text — often icon links or image links without alt text — leave screen reader users stranded. They hear “link” but have no idea where it leads.

The fix: Ensure every link contains readable text, whether visible or provided via an aria-label attribute. Social media icon links are a common offender.

5. Empty Buttons — Found on 29.6% of Pages

The same problem as empty links, applied to buttons. A magnifying glass icon used as a search button, with no text or aria-label, is invisible to assistive technology.

The fix: Add descriptive text or an aria-label to every button. “Search”, “Submit”, “Close menu” — keep it clear and specific.

6. Missing Document Language — Found on 15.8% of Pages

Without a lang attribute on the <html> element, screen readers cannot select the correct pronunciation rules. A British English page read with French pronunciation is unintelligible.

The fix: Add lang="en-GB" to the opening <html> tag. This is a one-line fix in your theme template.

Here is a challenge: run a WAVE scan on your own home page right now. Count how many of these six errors appear. The results may surprise you.

What’s New in WCAG 2.2 You Need to Know

WCAG 2.2 added nine new success criteria and removed one (SC 4.1.1 Parsing, now obsolete). Six of the nine affect Level AA conformance — the level required by law. Here are the ones that matter most for small business websites:

2.4.11 Focus Not Obscured (Minimum), AA — When a user tabs to an interactive element, it must not be entirely hidden behind sticky headers, cookie banners, or chat widgets. If your site has a persistent navigation bar or a cookie consent pop-up, check that focused elements remain visible beneath them.

2.5.7 Dragging Movements, AA — Any functionality that requires dragging (sliders, reorderable lists) must also work with a single pointer action. This protects users with motor impairments who cannot perform drag gestures.

2.5.8 Target Size (Minimum), AA — Touch and click targets must be at least 24×24 CSS pixels or have sufficient spacing. Tiny links crammed together in a footer fail this criterion.

3.2.6 Consistent Help, A — If your site provides a help mechanism (contact link, chat widget, FAQ link), it must appear in the same relative position across pages.

3.3.7 Redundant Entry, A — Information a user has already entered in a form must be auto-populated or selectable if needed again. Multi-step checkout forms that ask for the same address twice fail this.

3.3.8 Accessible Authentication (Minimum), AA — Login processes must not rely on cognitive function tests (like remembering a password with no paste support) unless alternatives exist. CAPTCHAs have been the number-one frustration for screen reader users for 14 consecutive years.

Mobile Accessibility — Making Sure Your Site Works on Every Device

If you need a website that works on mobile — and every business does — accessibility and mobile-friendliness are deeply intertwined. Screen reader usage on mobile devices is substantial: 91.3% of screen reader users report using a screen reader on a mobile device, with iOS VoiceOver dominant at 70.6%.

How can you make your website mobile-friendly in a way that also serves disabled users? Start here:

Touch targets matter. WCAG 2.2’s new SC 2.5.8 requires interactive targets to be at least 24×24 CSS pixels. On a mobile screen, small buttons and closely packed links are not just annoying — they are an accessibility barrier for users with motor impairments.

Responsive layouts must not break at narrow widths. WCAG 1.4.10 (Reflow, Level AA) requires content to be usable at 320 CSS pixels wide without horizontal scrolling. Test every page at this width.

Do not disable pinch-to-zoom. Setting maximum-scale=1 in the viewport meta tag prevents users with low vision from enlarging content. Remove it.

Test with a mobile screen reader. VoiceOver on iOS and TalkBack on Android are free and built in. Swipe through your site to verify that headings, buttons, and links are announced correctly and that nothing is skipped or mislabelled.

Mobile performance and accessibility overlap significantly. A fast, well-structured site benefits everyone — including search engines. For more on performance, see our guide on why Google PageSpeed matters and how we optimise it.

What WordPress and Shopify Owners Should Actually Do

The research points to clear, platform-specific actions.

WordPress

Start with the right foundation. Choose a theme tagged “Accessibility Ready” from the WordPress theme directory, or use a proven option like Kadence or GeneratePress. Your choice of page builder matters enormously: Divi sites averaged just 27.6 errors per page (45.9% below average), while wpBakery sites averaged 63.5 errors (24.6% above average).

Audit every plugin before deployment. Third-party code is the most common source of accessibility regressions. Overlay plugins that promise one-click compliance address only 20–30% of WCAG criteria and cannot fix source code issues.

Integrate automated testing. Install the Equalize Digital Accessibility Checker plugin to surface errors directly in the editor. Run axe DevTools or WAVE on every page during development.

For ongoing WordPress hosting and maintenance, accessibility should be part of every update cycle — not a one-off audit.

Shopify

Begin with Dawn, the flagship OS 2.0 theme, which provides the strongest accessibility baseline among Shopify themes. Even so, expect 30–50 hours of manual remediation for full WCAG 2.2 AA conformance.

Audit every app. The Shopify App Store does not review apps for accessibility. Every third-party app you install — reviews widgets, pop-ups, chat tools — can introduce new barriers.

For Both Platforms

Test with keyboard-only navigation. Tab through every page. Can you reach every link, button, and form field? Is the focus indicator visible? Can you open and close modals with Escape? Is the tab order logical?

Test with a screen reader. Use NVDA (free, Windows) or VoiceOver (built-in, macOS/iOS) to verify heading structure, form labels, landmark regions, and dynamic content announcements. The top browser and screen reader combinations to test are JAWS with Chrome, NVDA with Chrome, NVDA with Firefox, and VoiceOver with Safari.

Avoid accessibility overlay widgets. NNGroup research confirms they add little value for screen reader users. There is no shortcut to genuine accessibility.

Publishing an Accessibility Statement

Public sector organisations are required under the 2018 Regulations to publish an accessibility statement. For private sector businesses, it is strongly recommended as a demonstration of good faith under the Equality Act.

A compliant accessibility statement should include:

• The level of WCAG conformance the site targets (typically AA).
• Known non-compliances and a timeline for fixing them.
• Contact details so users can report accessibility problems.
• Details of the enforcement procedure (EHRC in England, Scotland, and Wales; ECNI in Northern Ireland).

A disproportionate burden exemption exists for public sector bodies, but it requires a genuine cost-benefit assessment — lack of time or knowledge does not qualify.

We recommend including an accessibility statement on every site as standard. It signals commitment, sets expectations, and provides a clear channel for feedback.

How Lightly Salted Approaches Website Accessibility

We build accessibility in from the brief, not patch it in at launch. Every web design project starts with an accessibility-ready foundation — semantic HTML, logical heading hierarchies, colour contrast checks, keyboard navigation testing, and screen reader verification. It is part of our process, not an optional extra.

This matters because retro-fitting accessibility is slower, more expensive, and less reliable than building it correctly from the start. It is also a reflection of what it means to be a values-driven agency — bespoke over template, sustainable by design, transparent in everything we do.

Building a new site, or worried yours falls short on website accessibility? Talk to Lightly Salted about an accessibility-led build or audit.