Website accessibility (a11y) means building a site that people with visual, hearing, motor and cognitive disabilities can perceive, navigate and use, including with assistive technology such as screen readers, voice control and keyboard-only navigation. The benchmark almost every law and procurement policy points to is the Web Content Accessibility Guidelines (WCAG), and WCAG 2.2 Level AA is the sensible target for a business site in 2026. Meeting it reduces legal risk, but more importantly it makes the site work for more of the people you want to reach.
Why does website accessibility matter for a business?
Accessibility is sometimes treated as a legal checkbox to tick before launch, but that framing undersells it. Accessible design is usually better design: clearer structure, stronger contrast, predictable navigation and forms that explain themselves. Those qualities help everyone, including people on a phone in bright sunlight, older visitors, and anyone using a keyboard instead of a mouse.
There is also a direct commercial angle. If a customer cannot complete your contact form with a screen reader, or cannot reach the checkout button with a keyboard, that is a lost lead or sale, however good the rest of the site looks. And because search engines and AI assistants read the same semantic structure that assistive technology relies on, a well-structured, accessible page is also easier for machines to understand.
Which accessibility laws apply to websites?
The legal landscape varies by country and changes over time, so treat this section as orientation rather than legal advice. What is consistent is the direction: accessibility is moving from a best practice to an enforceable expectation, and most frameworks use WCAG as the technical yardstick.
- United States: Title III of the Americans with Disabilities Act (ADA) covers businesses open to the public, and courts have repeatedly applied it to websites. Section 508 of the Rehabilitation Act sets requirements for federal agencies and the technology they buy, and the Department of Justice has issued rules under Title II that set WCAG-based requirements for state and local government websites.
- European Union: The European Accessibility Act has applied since 28 June 2025 and covers many consumer-facing digital products and services, including e-commerce, for businesses selling into EU member states. Public sector sites were already covered by the Web Accessibility Directive, and the harmonised standard EN 301 549 incorporates WCAG.
- Canada and the UK: Ontario’s AODA, the federal Accessible Canada Act and the UK Equality Act 2010 all create obligations that are commonly met by following WCAG.
If you sell across borders, the simplest strategy is to build to WCAG 2.2 AA everywhere rather than tracking the minimum for each jurisdiction. For specific obligations, especially if you have received a demand letter, speak to a lawyer who works in this area.
What does WCAG 2.2 AA actually require?
WCAG is organised around four principles: content must be perceivable, operable, understandable and robust (often abbreviated POUR). Each principle contains testable success criteria at levels A, AA and AAA. Level AA is the level laws and contracts usually reference.
WCAG 2.2 became a W3C Recommendation in October 2023. It kept almost everything from WCAG 2.1 and added criteria that matter for everyday business sites:
- Focus Not Obscured (Minimum): a sticky header, cookie banner or chat widget must not completely hide the element that has keyboard focus.
- Target Size (Minimum): interactive targets should be at least 24 by 24 CSS pixels, or have enough spacing around them.
- Dragging Movements: anything that requires dragging, such as a slider, needs a single-pointer alternative.
- Consistent Help: if you offer help such as a phone number or chat link, it should appear in the same place across pages.
- Redundant Entry: users should not be asked to re-enter information they already provided in the same process.
- Accessible Authentication (Minimum): logins should not depend on memorising or transcribing codes unless an alternative such as paste or a password manager works.
Practical steps that cover the most ground
You do not need to memorise every success criterion to make real progress. A short list of fundamentals resolves many of the issues commonly found on small business sites.
Structure and content
- Use a logical heading order (H1, then H2, then H3) so screen reader users can scan the page by headings.
- Use real HTML elements: buttons for actions, links for navigation, lists for lists and tables for tabular data.
- Write descriptive alt text for meaningful images, and use an empty alt attribute for purely decorative ones.
- Make link text meaningful on its own, for example “View our pricing guide” rather than “Read more”.
- Provide captions for video and transcripts for audio content.
Visual design
- Meet contrast minimums: 4.5:1 for normal text, and 3:1 for large text and essential interface elements such as input borders and icons.
- Never rely on color alone to convey meaning; pair a red error border with an icon or text.
- Keep a clearly visible focus indicator on every interactive element, and never remove outlines without replacing them.
- Make sure the layout still works when text is resized or the page is zoomed.
Interaction and forms
- Every function must be reachable and usable with a keyboard, in a sensible order, with no keyboard traps.
- Every form field needs a visible, programmatically associated label; placeholder text is not a label.
- Error messages should say what went wrong and how to fix it, and be announced to assistive technology.
- Menus, modals and accordions should follow established ARIA patterns, and modals should manage focus correctly.
How do you test a website for accessibility?
Good testing combines automated tools with manual checks, because automated scanners only detect part of the problem. They are excellent at spotting missing alt attributes or low contrast, but they cannot judge whether alt text is accurate or whether a custom dropdown is usable with a screen reader.
| Method | Tools | What it catches well | Limitations |
|---|---|---|---|
| Automated scan | axe DevTools, WAVE, Lighthouse | Missing labels, contrast failures, empty links, invalid ARIA | Cannot judge meaning, usability or logical order |
| Keyboard testing | Tab, Shift+Tab, Enter, Space and Esc | Focus order, traps, hidden focus, unreachable controls | Needs a human and a checklist |
| Screen reader testing | NVDA or JAWS on Windows, VoiceOver on Apple devices, TalkBack on Android | Announcements, labels, reading order, dynamic updates | Takes practice to use efficiently |
| User testing | Sessions with people who use assistive technology | Real-world barriers nobody anticipated | Requires planning and budget |
A practical rhythm is to run an automated scan on every template, do a full keyboard pass on key journeys (navigation, contact form, checkout or booking), and spot-check those journeys with a screen reader. Record each finding against the relevant WCAG criterion so fixes can be prioritised and verified.
Common accessibility mistakes to avoid
- Relying on an overlay widget. Toolbar overlays that promise instant compliance do not fix the underlying code, and many disabled users find they interfere with the assistive technology they already use. Fix the site itself.
- Treating it as a one-time audit. Accessibility erodes as new pages, plugins and content are added by people who were not involved in the original build.
- Inaccessible third-party components. Booking widgets, chat tools, embedded maps and cookie banners are frequent sources of failures. Test them before you commit.
- Custom controls without semantics. A styled div that behaves like a button is invisible to a keyboard user unless it is built properly.
- PDFs as the only format. Information locked in untagged PDFs is often unreadable with a screen reader; publish it as an HTML page as well.
How do you keep a site accessible over time?
The sites that stay accessible are the ones where it is built into the process rather than bolted on. That means accessible components in your design system, accessibility checks in content publishing guidelines, automated tests in the development pipeline, and a periodic manual review of key journeys.
It also helps to publish an accessibility statement that explains your target standard, known limitations and a way for users to report problems. That gives people a route to tell you about barriers before they become complaints, and it signals that you take the issue seriously.
When a site is redesigned or migrated, include accessibility in the acceptance criteria from the start. Retrofitting after launch is almost always slower and more expensive than building it in.
Accessibility is one of the areas covered by our free website audit, in which our team reviews your site’s public pages and replies with the main issues and what we would fix first.
Frequently asked questions
Is WCAG compliance legally required for my business website?
It depends on where you operate and who you serve. Some laws do not name WCAG directly but are routinely interpreted or enforced against it, while others, such as the EU framework and US government rules, reference it explicitly. Building to WCAG 2.2 AA is the most defensible position for most businesses.
Can an accessibility plugin or overlay make my site compliant?
No single plugin can make a site compliant. Some WordPress plugins help with specific tasks, such as flagging missing alt text, but real compliance comes from accessible themes, components, content and testing.
How long does it take to make an existing site accessible?
It varies with the size of the site and how it was built. A site on a solid, semantic theme may need a few focused fixes, while one built from heavily customised page-builder layouts may need template-level rework. An audit of representative templates is the fastest way to get a realistic scope.
If you would like help auditing or remediating your site, our front-end development team builds accessibility into templates and components, and our UI/UX design services cover accessible design systems from the first wireframe. You can also contact us for an accessibility review of your current site.
