Web Accessibility (WCAG 2.2) Guide for Business Websites
An accessible website is one that people with visual, hearing, motor and cognitive disabilities can use as easily as anyone else. WCAG accessibility refers to meeting the Web Content Accessibility Guidelines, the international standard published by the World Wide Web Consortium (W3C). For businesses, it matters for three reasons: legal exposure, a larger addressable market and better usability and SEO for every visitor.
This guide explains what WCAG 2.2 requires in plain English, what changed from WCAG 2.1, which laws reference it, and how to audit and fix a business website without stalling your roadmap.
What Is WCAG?
WCAG is a set of testable success criteria that define how to make web content accessible, organized into three conformance levels: A, AA and AAA. The current version, WCAG 2.2, became a W3C Recommendation in October 2023 and builds on WCAG 2.0 (2008) and 2.1 (2018). Because each version is backward-compatible, a site that meets WCAG 2.2 also meets the earlier versions.
The guidelines are grouped under four principles, often remembered as POUR:
- Perceivable: users can perceive content, for example through text alternatives for images, captions for video and sufficient color contrast.
- Operable: users can operate the interface, including by keyboard only, with enough time and without content that could trigger seizures.
- Understandable: content and interactions are predictable, readable and help users avoid and fix mistakes.
- Robust: content works reliably with browsers and assistive technologies such as screen readers.
Level AA is the target that most laws, contracts and procurement policies reference, and it is the level we recommend for business websites.
What Is New in WCAG 2.2?
WCAG 2.2 added nine success criteria focused on users with cognitive, motor and low-vision needs, and removed the obsolete 4.1.1 Parsing criterion. The W3C summarizes them on its What’s New in WCAG 2.2 page. The six at Level A and AA are the ones most businesses need to act on:
| Criterion | Level | What it means in practice |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, cookie banners or chat widgets must not completely hide the element that has keyboard focus. |
| 2.5.7 Dragging Movements | AA | Anything done by dragging (sliders, reordering, maps) must also work with simple clicks or taps. |
| 2.5.8 Target Size (Minimum) | AA | Clickable targets should be at least 24 by 24 CSS pixels, or have enough spacing, with some exceptions. |
| 3.2.6 Consistent Help | A | Help options such as contact links or chat appear in the same place across pages. |
| 3.3.7 Redundant Entry | A | Do not make users re-enter information they already provided in the same process, unless necessary. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login must not rely on a cognitive test such as memorizing or transcribing, unless an alternative is offered. Allow password managers and paste. |
Which Laws Require WCAG Accessibility?
Many accessibility laws do not mention WCAG by name in their main text, but regulators, courts and technical standards use WCAG 2.1 or 2.2 AA as the practical benchmark. Key examples:
- United States: The Americans with Disabilities Act (ADA) covers businesses open to the public, and courts have applied it to websites; a large volume of web accessibility lawsuits is filed each year. Federal agencies must follow Section 508, which references WCAG 2.0 AA, and the Department of Justice has adopted WCAG 2.1 AA as the technical standard for state and local government websites under ADA Title II.
- European Union: The European Accessibility Act has applied since 28 June 2025 to many consumer-facing products and services, including e-commerce, banking services and e-books. Its harmonized standard, EN 301 549, maps to WCAG 2.1 AA for web content.
- United Kingdom: The Equality Act 2010 requires reasonable adjustments for disabled people, and public sector bodies must meet accessibility regulations that use WCAG as the benchmark and publish an accessibility statement.
- Elsewhere: Canada (including Ontario’s AODA), Australia and many other jurisdictions have similar requirements or rely on WCAG in procurement.
This is general information, not legal advice. If you sell into regulated markets, confirm your obligations with a qualified adviser.
The Business Case Beyond Compliance
Accessibility improvements usually improve conversion and SEO for all users, not only people with disabilities. Clear headings, descriptive links, captions and alt text help search engines understand your pages. Larger tap targets and readable contrast help everyone on a phone in bright sunlight. Forms with clear labels and error messages reduce checkout abandonment. Many enterprise and public sector buyers also require an accessibility conformance report before signing a contract.
The Most Common Accessibility Failures
Most WCAG failures on business websites come from a small set of recurring issues that are relatively cheap to fix:
- Low color contrast. Normal text needs a contrast ratio of at least 4.5:1 against its background, and large text and key interface components at least 3:1.
- Missing or poor alt text on informative images, and decorative images that are not hidden from screen readers.
- Form fields without labels, and error messages that rely only on color.
- Keyboard traps and invisible focus. Menus, modals and carousels that cannot be used or closed with a keyboard, or focus outlines removed by CSS.
- Broken heading structure, such as skipping levels or using headings only for visual styling.
- Vague link text such as “read more” or “click here” repeated many times.
- Video without captions and audio without transcripts.
- Custom components without proper roles and states, for example a styled div acting as a button.
How to Audit and Fix Your Website: Step by Step
A reliable accessibility program combines automated tools, manual testing and design-system fixes so problems do not return. Here is the process we follow:
- Define scope and target. Agree on WCAG 2.2 AA and list key templates and user journeys: home, product or service pages, search, forms, checkout, login and account.
- Run automated scans. Tools such as axe DevTools, WAVE and Lighthouse catch issues like missing alt text, contrast and missing labels. Automated tools find only a portion of problems, so this is a starting point.
- Test manually. Navigate every key journey using only a keyboard, then with a screen reader such as NVDA or JAWS on Windows and VoiceOver on macOS and iOS. Check zoom to 200% and 400% reflow on a narrow screen.
- Prioritize by impact. Fix blockers on critical journeys first (checkout, contact forms, login), then sitewide template issues, then individual pages.
- Fix at the source. Update shared components and your design system so every page inherits the fix, and add accessibility checks to design reviews in Figma.
- Prevent regressions. Add automated accessibility tests to your CI pipeline and include accessibility in your definition of done.
- Publish an accessibility statement describing your conformance target, known limitations and how users can report problems.
If you are planning a rebuild anyway, include accessibility in the brief from the start; our website redesign checklist shows how to combine it with SEO migration.
Why Overlays Are Not a Fix
Accessibility overlay widgets that promise one-line-of-code compliance do not make a site conform to WCAG. They cannot reliably fix underlying problems such as unlabeled forms or inaccessible custom components, and disability advocates and many accessibility professionals have criticized them for interfering with users’ own assistive technology. Investing in fixing the code is the dependable route.
What Does WCAG Remediation Cost?
Costs depend on site size, technology and how many issues are in shared components. As indicative ranges at blended offshore and onshore rates:
- Audit of a small business website (10–30 templates and pages): about $1,500–$5,000.
- Remediation of a typical marketing or WordPress site: about $3,000–$15,000.
- Audit and remediation of a large e-commerce site or web app: about $15,000–$60,000+.
Building accessibility into a new site from the start typically adds far less than retrofitting later. Your final quote depends on scope.
Frequently Asked Questions
What WCAG level should my business website meet?
Aim for WCAG 2.2 Level AA. It is the level referenced by most laws and procurement rules, and meeting 2.2 AA also satisfies 2.1 AA and 2.0 AA. Level AAA is rarely required for an entire site.
Is WCAG accessibility a legal requirement for private businesses?
It depends on where you operate and what you sell. In the US, the ADA has been applied to business websites by courts; in the EU, the European Accessibility Act covers many consumer services; in the UK, the Equality Act 2010 applies. Check your obligations with a legal adviser.
Can automated tools make my site WCAG compliant?
No. Automated scanners catch only some issues. Keyboard and screen reader testing by people who understand WCAG is essential to confirm conformance.
How long does it take to make a website accessible?
A small site can often be audited and fixed in two to six weeks. Larger sites and web apps may need a phased plan over several months, starting with the most important user journeys.
Make Your Website Accessible
Sigmato designs and builds accessible business websites, WordPress sites and web apps, and can audit and remediate existing sites against WCAG 2.2 AA. Tell us about your site and we will propose a practical plan.
Sources and References
