Website Accessibility: A Practical WCAG 2.2 Guide for Business Websites

Most business websites fail basic accessibility checks, and the failures are rarely exotic. They are gray text on a white background, images without descriptions, form fields without labels, and buttons that a screen reader announces as "button" with no name. Each one is small. Together they lock out a meaningful share of your visitors, and they are usually cheap to fix once somebody looks.

This guide explains what website accessibility means in practice, what the current standard (WCAG 2.2) asks for, which failures appear most often, how the law looks in the US and UK, and how to audit and fix your own site in a sensible order. It is written for marketing leads, product owners, and founders who need to brief a developer, not for accessibility specialists.

What is website accessibility, and what standard should you follow?

Website accessibility means building a site that people with disabilities can perceive, operate, and understand, including people who use screen readers, keyboard-only navigation, voice control, magnification, or captions. The standard almost everyone points to is the Web Content Accessibility Guidelines (WCAG). The current version, WCAG 2.2, became a W3C Recommendation on 12 December 2024.

WCAG is organized around four principles: content must be perceivable, operable, and understandable, and it must work with current and future assistive technology. It defines three conformance levels, A, AA, and AAA. Level AA is the practical target for most commercial sites, and it is the level the UK government requires of public sector websites. WCAG 2.2 is backwards compatible, so content that meets 2.2 also meets 2.0 and 2.1.

How common are accessibility failures on real websites?

Very common. In its February 2026 analysis of the top one million home pages, the independent WebAIM Million report found detectable WCAG 2 failures on 95.9% of them, up from 94.8% the year before. The average page had 56.1 detectable errors, up 10.1% from 51 in 2025. Automated checks only catch part of the problem, so the real picture is worse than those numbers.

The same report shows that a handful of issue types account for most of the damage. As a share of home pages, WebAIM found:

• Low contrast text: 83.9%

• Missing alternative text on images: 53.1%

• Missing form input labels: 51%

• Empty links: 46.3%

• Empty buttons: 30.6%

• Missing document language: 13.5%

These six categories are the best place to start. They are well defined, easy to test, and fixing them removes the bulk of the detectable errors on a typical business site.

Why does accessibility matter beyond compliance?

Accessibility and general usability overlap heavily. Readable contrast helps someone on a phone in sunlight. Clear labels help everyone fill in a form faster. Keyboard support helps people with a broken trackpad as much as people who never use a mouse. Fixing these issues tends to lift conversion on forms, checkouts, and enquiry flows, because the same friction that stops a disabled user also slows everyone else down.

There is a search angle too. Descriptive alt text, a logical heading structure, meaningful link text, and a declared page language are all signals that help search engines and AI answer engines understand a page. Accessibility work and SEO services share a lot of groundwork, which is why we usually plan them together.

What does the law say in the US and the UK?

Note that Invisio Solutions is a digital agency, not a law firm, and this section is general context rather than legal advice. Confirm your obligations with a qualified lawyer.

United States

The US Department of Justice states in its web accessibility guidance that the Americans with Disabilities Act applies to the online offerings of businesses open to the public. It also says it has no regulation setting detailed technical standards for those businesses, and that they have flexibility in how they comply. The guidance points to WCAG and the Section 508 Standards as helpful references. In practice, WCAG 2.1 or 2.2 Level AA is the benchmark most organizations and their lawyers use.

United Kingdom

The GOV.UK guidance on accessibility requirements says public sector websites and apps must meet WCAG 2.2 AA and publish an accessibility statement. For private companies, the same guidance notes that all UK service providers have a legal duty to make reasonable adjustments under the Equality Act 2010, and the Equality and Human Rights Commission can enforce it. There is no separate private sector WCAG mandate on that page, but WCAG 2.2 AA is the sensible yardstick.

Selling into the EU

If you sell online to customers in the European Union, check the European Accessibility Act. The European Commission's overview lists e-commerce among the covered services. Whether and how it applies to your business depends on where you operate and what you sell, so take advice before assuming either way.

What changed in WCAG 2.2?

WCAG 2.2 added nine success criteria and removed one (4.1.1 Parsing). Several are Level AA, which means they matter for most commercial sites. The ones to brief your team on are:

• Focus Not Obscured (Minimum), 2.4.11: a keyboard-focused element must not be fully hidden by sticky headers, cookie banners, or chat widgets.

• Dragging Movements, 2.5.7: anything that works by dragging, such as a slider, also needs a simple single-pointer alternative.

• Target Size (Minimum), 2.5.8: tap and click targets need enough size or spacing to be hit reliably.

• Accessible Authentication (Minimum), 3.3.8: login flows should not depend on a cognitive test, such as remembering or transcribing a password, without an alternative like paste support or a password manager.

• Consistent Help, 3.2.6 (Level A): if help options such as contact details or chat appear on multiple pages, they should sit in a consistent place.

• Redundant Entry, 3.3.7 (Level A): do not make people retype information they already gave in the same process.

The sticky header and cookie banner problem is worth checking first. It is common, it is easy to introduce during a redesign, and automated tools rarely catch it.

How do you fix the six most common accessibility failures?

Low contrast text

WCAG Level AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Check your brand palette against those numbers before the design is built, not after. Light gray body copy, pale placeholder text, and white text over photographs are the usual offenders. Fixing contrast is a design decision, which is why our UI/UX design process tests the palette at the style-guide stage.

Missing alternative text

Every informative image needs a short description of what it conveys, and decorative images need an empty alt attribute so screen readers skip them. Write alt text for the purpose of the image on that page, not a keyword list. A product photo needs the product and key detail; a chart needs its main takeaway; a logo link needs the destination.

Missing form labels

Every input needs a visible label that is programmatically associated with it. Placeholder text is not a label, because it disappears when someone starts typing and is poorly supported by assistive technology. Error messages should say which field failed and how to fix it. A red border alone tells a screen reader user nothing.

Empty links and empty buttons

An icon-only button, such as a search magnifier, a hamburger menu, or a social icon, needs an accessible name. Without one, a screen reader announces only "link" or "button". Add visually hidden text or an aria-label. Avoid vague link text such as "click here" or "read more" repeated across a page.

Missing document language

Set the lang attribute on the html element, for example lang="en-GB" or lang="en-US". It is a one-line fix that tells screen readers which pronunciation rules to use, and it is missing on 13.5% of home pages in the WebAIM data.

Does adding ARIA or an accessibility plugin fix the problem?

Not by itself. ARIA is a set of attributes that can improve the experience for assistive technology when used correctly, but it is not a shortcut. In the WebAIM Million, home pages that used ARIA averaged 59.1 detected errors, compared with 42 on pages without it. WebAIM notes that ARIA may not be the direct cause, because those pages are also more complex, but the finding is a clear warning against adding it blindly. The first rule is to use the correct native HTML element, a real button or a real link, before reaching for ARIA.

The same applies to plugins and widgets that promise one-click compliance. A tool can help you find problems or add a text-size control, but it cannot fix a design with poor contrast, an unlabeled form, or a keyboard trap. Treat any quick fix as a supplement to proper code and design, not a replacement.

How do you test your website for accessibility?

Use a mix of automated and manual checks, because automated tools catch only a portion of the issues. A sensible order is:

1. Run an automated scan on your highest-traffic templates with a free tool such as WAVE, axe DevTools, or the Lighthouse accessibility audit in Chrome. This catches the contrast, label, alt text, and empty-link problems quickly.

2. Tab through the page with only a keyboard. You should always see where focus is, reach every link and control, operate menus and modals, and never get trapped. Check that sticky elements do not cover the focused item.

3. Zoom to 200% and 400% and check that content reflows without horizontal scrolling or overlapping text.

4. Try a screen reader such as NVDA on Windows, VoiceOver on Mac and iOS, or TalkBack on Android. Listen to your navigation, a form, and a product or service page.

5. Review media. Videos need captions, audio needs a transcript, and nothing should autoplay with sound.

6. Test the critical journeys end to end: enquiry form, checkout, login, and booking. A single inaccessible step can block the whole flow.

7. Involve disabled users where you can. Even a small round of user testing finds problems that no tool will flag.

If you want a specialist review, our technical SEO services audit includes the structural and markup issues that overlap with accessibility, such as heading order, link text, and language declarations.

Where does accessibility break on WordPress, Webflow, and online stores?

WordPress

Themes and page builders are the main variable. Some produce clean semantic markup; others wrap everything in nested divs and replace native controls with scripted ones. Plugins for sliders, pop-ups, and mega menus are frequent sources of keyboard traps. Choose themes that advertise accessibility support and test each plugin you add. Our WordPress development team checks keyboard and focus behavior as part of QA.

Webflow

Webflow lets you set heading levels, alt text, ARIA attributes, and landmarks directly, but it does not decide them for you. Common issues include heading levels chosen for size rather than structure, custom interactions that trap focus, and embeds with no labels. See how we approach this in our Webflow development services.

Online stores

Stores concentrate the hardest patterns: product galleries, variant selectors, filters, quantity steppers, and multi-step checkouts. Each needs keyboard support, clear labels, and announced error states. Because checkout is where a blocked user costs you a sale directly, it deserves the most testing. This is built in from the start in our ecommerce website development work.

Should you fix accessibility during a redesign or build?

Yes. Accessibility is cheapest when it is a requirement from the first wireframe: contrast ratios are set in the palette, focus styles are part of the component library, and heading structure is defined in the templates. Retrofitting the same fixes into a finished site means reopening signed-off work.

A redesign is also the moment accessibility regresses most often, because new visuals, sticky elements, and animations arrive without a checklist. Our website redesign services and web development work set WCAG 2.2 AA as a target at the brief stage. The same applies if you are choosing between a template and a bespoke site, so read our comparison of custom website development vs template and ask any vendor how they handle accessibility.

What does a realistic accessibility roadmap look like?

8. Week 1: Baseline. Scan your top ten templates, tab through them, and list issues by severity and template.

9. Week 2: Quick wins. Fix contrast tokens, set the page language, label forms, name icon-only buttons, and add missing alt text.

10. Week 3: Structure and keyboard. Correct heading order, fix focus visibility, remove keyboard traps, and make sure sticky elements do not hide focused items.

11. Week 4: Critical journeys and media. Test checkout or enquiry flows with a screen reader, add captions and transcripts, and publish an accessibility statement with a contact route for feedback.

12. Ongoing: add accessibility checks to your release process, so each new page and feature meets the standard before it ships.

The timeline depends on the size and condition of the site, but most small to mid-sized business websites can clear the major failures within a month. Larger platforms with custom components take longer.

The most common accessibility mistakes

• Relying on an automated score and assuming a pass means the site is accessible.

• Choosing a brand palette that fails contrast and then trying to patch it page by page.

• Using placeholder text instead of real form labels.

• Adding ARIA attributes without first using the correct native element.

• Installing an accessibility widget instead of fixing the underlying code and design.

• Never testing with a keyboard or a screen reader.

• Treating accessibility as a one-time project instead of a standing requirement in the release process.

Find out where your website stands

Website accessibility is easiest to fix when you know exactly which templates, components, and journeys fail. Invisio Solutions can review your site against WCAG 2.2 AA, rank the issues by impact, and brief your developers or fix them for you.

Contact Invisio Solutions to talk through an accessibility review, or see how our custom website development team builds accessibility into new sites.