Web accessibility decides whether everyone can use your website: read it, move around it and complete the enquiry form, whether they use a mouse, a keyboard, a screen reader, voice control or a zoomed-in screen. On most business sites the barriers are mundane: pale grey text, unlabelled fields, photos with no description, icon buttons announced as just “button”.
This guide shows how WCAG makes accessibility testable, which barriers to fix first and how to keep them fixed. Like every ingredient of what makes a good website, it works best designed in rather than bolted on.
The short answer
Web accessibility (or website accessibility) means designing and building websites so that people with disabilities can perceive, understand, navigate and interact with them.
- The standard is WCAG, the W3C’s Web Content Accessibility Guidelines. WCAG 2.2 level AA is the sensible target for a business website.
- It rests on four principles: perceivable, operable, understandable and robust (POUR).
- The common failures are basic: low-contrast text, missing alt text, unlabelled fields, empty links and buttons, and no page language.
- It’s cheapest built in, through the palette, components and templates, then kept up by whoever edits the site.
What is web accessibility?
The W3C’s Web Accessibility Initiative (WAI) defines it as websites, tools and technologies designed and developed so that people with disabilities can use them: perceive, understand, navigate and interact with the web, and contribute to it.
That includes people who are blind, partially sighted, deaf or hard of hearing, people with limited movement, speech, cognitive or learning disabilities, and many older people whose abilities change gradually. The World Health Organization estimates that about 1.3 billion people, roughly one in six worldwide, experience significant disability.
They use screen readers, keyboards instead of a mouse, magnification, voice control and captions, and each works only as well as the page is built. The business case for accessibility explains why that reach matters commercially.
The POUR principles: how WCAG makes accessibility testable
The Web Content Accessibility Guidelines turn “make it accessible” into success criteria, grouped under four principles and graded A, AA and AAA. Level AA includes everything at level A and is the level most laws, policies and contracts refer to. The W3C advises against requiring AAA across a whole site, because some content can’t meet it.
| Principle | What it means | Examples of what AA asks |
|---|---|---|
| Perceivable | People can take in the content with the senses they use | Text alternatives for images; captions on video; contrast of 4.5:1 for normal text and 3:1 for large text; layouts that reflow at 320 CSS pixels wide |
| Operable | Every control works, whatever the input device | Full keyboard access; visible focus not fully hidden by sticky headers; a way to pause moving content; targets at least 24 by 24 CSS pixels or well spaced |
| Understandable | Content and behaviour make sense | Page language declared; labels or instructions on fields; errors described in text; consistent navigation |
| Robust | It works with browsers and assistive technology | Controls expose their name, role and state; status messages such as “Message sent” are announced |
Conformance also covers whole processes: if one step of a multi-page form or checkout fails, none of the pages in that process conform. And passing every criterion on paper isn’t the same as being easy to use.
WCAG 2.2 became a W3C Recommendation in October 2023 and is backwards compatible with 2.1 and 2.0. At the time of writing (June 2026), WCAG 3 is still an incomplete draft, years from completion, so 2.2 is the version to build to. WCAG 2.2 explained covers the levels and the nine new criteria.
The barriers that keep turning up on business websites
Each year, WebAIM runs automated tests on the home pages of the top one million websites for its WebAIM Million report. The same six failure types have led the list year after year.
Low-contrast text
Light grey body copy, white text over photos, a pale brand colour on small links. Check it yourself: in Chrome DevTools, inspect some text and click its colour swatch to see the contrast ratio. Body text needs at least 4.5:1. Colour contrast and readable text shows how to adapt a brand palette without losing its character.
Missing alternative text
An image with no alt attribute may be read out as its file name, or skipped. Meaningful images need a short description of what they show or do, and a linked logo should give the company name, not “logo”. Decorative images get an empty alt="" so screen readers pass over them.
Unlabelled form fields
Placeholder text that vanishes as you type isn’t a label. Without a label connected in the code, a screen reader announces something like “edit text” and leaves the user guessing. Here accessibility and conversion meet: accessible forms covers labels, errors and autocomplete.
Empty links and buttons
Icon-only controls are the usual culprits: menu and search icons, carousel arrows, a pop-up’s close “×”. With no text in the code, assistive technology announces just “button” or “link”. Give each an accessible name, through visually hidden text or an aria-label.
Missing page language
The lang attribute tells screen readers which language to pronounce the page in; without it, they fall back to a default that may be wrong. Multilingual sites need the right lang on each language version, and on passages in another language, such as the names in a language switcher. Search your page source for <html lang=.
What automated checkers miss
Tools such as axe, WAVE and Lighthouse find those failures fast, but only part of WCAG can be tested by machine. They can’t judge whether alt text is accurate, whether the focus order makes sense or whether a keyboard user gets trapped in a pop-up. Accessibility audits, checkers and overlays explains what each can tell you.
Why building accessibility in costs less than retrofitting
Accessibility decisions cascade. A brand colour that fails contrast appears on every button; a menu that traps keyboard focus appears on every page. Decide these early and they’re right everywhere. Find them after launch and each fix means reopening signed-off designs, reworking components and retesting, sometimes replacing the theme altogether.
Accessible website design starts before the first page is drawn:
- Brief. Name WCAG 2.2 AA as a requirement in the brief and contract, and ask how it will be tested. It belongs among the questions to ask before hiring a web designer.
- Design. Test the palette for contrast before sign-off, design visible focus states, size tap targets generously, never use colour alone to carry meaning, and keep text out of images.
- Development. Semantic HTML first: real buttons and links work with a keyboard by default, and real headings and labels give screen readers the page’s structure. ARIA fills gaps, and misapplied ARIA makes things worse.
- Content. Descriptive headings, link text that makes sense on its own, accurate alt text, plain language.
- Pre-launch testing. Automated checks on every template, then key journeys with a keyboard, at 200% and 400% zoom, and with a screen reader.
That structure also helps search engines understand your pages, though Google hasn’t confirmed accessibility as a ranking factor in its own right. Accessibility and SEO separates the overlap from the myths.
Legal obligations vary by market
This isn’t legal advice; rules differ by country, sector and organisation. Broadly:
- Public-sector websites in many countries must meet a defined standard, usually based on WCAG.
- In the European Union, the European Accessibility Act has applied since 28 June 2025 to a defined set of products and services, including many online shops, with an exemption for microenterprises providing services.
- Elsewhere, disability and anti-discrimination laws can apply to websites; in the United States, businesses have been sued over inaccessible websites under the Americans with Disabilities Act.
Rules can follow your customers rather than your address, and most of them point back to WCAG level AA, so 2.2 AA is a sensible default. In a regulated sector, ask a lawyer who knows your markets.
Keeping a site accessible after launch
After launch, new barriers usually arrive through everyday editing: text baked into a banner image, an uncaptioned video, a scanned PDF, an untested chat widget. Agree a few habits with everyone who publishes:
A website maintenance checklist is the natural home for the periodic checks.
Publish an accessibility statement
An accessibility statement tells visitors how accessible your site is and what to do when something doesn’t work: the standard you aim for, known problems and workarounds, how to report a barrier and when you’ll reply, and the date of the last review. Keep it honest; claiming conformance you haven’t tested does more damage than listing known issues. The W3C publishes guidance on accessibility statements, including a free generator.
Where to start with an existing website
- Pick your key journeys: the homepage, a main service page and the enquiry form.
- Run an automated checker on each and fix the common failures above.
- Put the mouse away. Can you Tab to every control, see where you are and submit the form?
- Zoom to 400% in a desktop window 1,280 pixels wide. Does the layout reflow without sideways scrolling?
- Listen to it with VoiceOver (built into Macs and iPhones) or NVDA (free for Windows).
- Fix at the source: palette, components and templates first, then content.
Every guide in the accessibility series
| If you need to… | Read |
|---|---|
| Understand the standard | WCAG 2.2 explained |
| Make the case internally | The business case |
| Fix menus and keyboard focus | Accessible navigation |
| Build forms everyone can finish | Accessible forms |
| Choose readable colours and type | Colour contrast |
| Understand the SEO overlap | Accessibility and SEO |
| Test a site or judge an overlay | Audits and overlays |
Accessibility is part of good design, not a separate discipline: the website design guides cover the rest.
Frequently asked questions
Is WCAG 2.1 AA still good enough?
Many laws and contracts still cite WCAG 2.1 level AA, and a site that meets 2.2 AA meets 2.1 AA too. Version 2.2 adds six checks at levels A and AA, on hidden focus, target size, dragging, consistent help, repeated data entry and log-ins, so building to 2.2 covers both.
Does accessibility limit what a website can look like?
Very little. It rules out pale text, text inside images and motion that can’t be paused, but leaves plenty of room for a distinctive brand, especially when it’s part of the design from the first sketch.
Can an accessibility plugin make my website compliant?
Not on its own. The barriers sit in the design, code and content, which a plugin or overlay can’t reliably fix from the outside. Checkers that flag missing alt text are useful reminders, not fixes.
Is web accessibility only for people with disabilities?
No. It’s defined around disability, but the same work helps someone with a broken wrist, a phone in bright sunlight or a video on a silent train, and clear labels help everyone finish a form.
What to do next
Accessibility isn’t a badge you install at the end. It comes from decisions in the brief, the design, the code and every edit after launch, alongside strategy, UX, performance and SEO rather than after them.
Planning a new site? Our website design and development work builds accessibility in from the first design decision, with editor training so your team can keep it that way. If your current site’s problems run through its theme and templates, a website redesign fixes them at the source. Not sure which you need? Talk to us about what your website needs.