Most arguments for web accessibility lead with the law or with doing the right thing. Both matter. But website budgets are decided on customers, revenue and risk, and the business case for web accessibility is strong on all three. Here is that case, in a form you can take to a finance director or a sceptical board.
An accessible website is one people can use whatever their abilities, devices or circumstances: with a keyboard or a screen reader, zoomed in, or on a phone in bright sunlight. The usual benchmark is level AA of the W3C’s Web Content Accessibility Guidelines (WCAG) 2.2, which our practical guide to web accessibility explains. This article is about why it’s worth paying for.
The business case for web accessibility, in brief
- Reach. The World Health Organization estimates that 1.3 billion people, about 1 in 6 worldwide, experience significant disability, and anyone can hit a temporary or situational limit: an injury, glare on a screen, a noisy room.
- Conversions. Barriers cluster on the path to an enquiry: menus, buttons, forms, CAPTCHAs and cookie banners. Removing them usually reduces friction for every visitor.
- Quality. The same work tends to improve mobile usability, code quality and the page structure search engines rely on.
- Sales. Many public-sector buyers and larger organisations ask about accessibility before they buy.
- Risk. Complaints and legal claims are real in many markets, and cheaper to prevent than to defend.
- Cost. Building accessibility in from the start costs less than retrofitting it after launch.
Your audience is wider than you think
Permanent, temporary and situational
Inclusive design treats disability as a mismatch between a person and their environment, not a fixed trait of a small group. Microsoft’s Inclusive Design toolkit popularised the “persona spectrum”: the same need can be permanent, temporary or situational. Someone with one arm, someone with a broken wrist and a parent holding a baby all need to use your site one-handed.
| Need | Permanent | Temporary | Situational | What helps on a website |
|---|---|---|---|---|
| Seeing | Blindness or low vision | Dilated pupils after an eye test | Bright sunlight on a phone screen | Strong contrast, resizable text, screen reader support |
| Hearing | Deafness | An ear infection | A noisy train or open-plan office | Captions and transcripts |
| Using hands | One arm, or limited dexterity | A broken wrist | Holding a child or a coffee | Large tap targets, full keyboard access |
| Understanding | Dyslexia, or a learning disability | Concussion, or medication that affects focus | Reading in a second language, or under stress | Plain language, clear structure, forgiving forms |
So “our customers aren’t disabled” is never the whole story: every audience includes people coping with situational disabilities right now, and designing for them is what inclusive UX means in practice.
An ageing audience
Age brings changes in eyesight, hearing, dexterity and memory that many people wouldn’t call a disability, and the WHO expects 1 in 6 people worldwide to be aged 60 or over by 2030. If your buyers include senior decision-makers, retirees or patients, small grey text and fiddly controls get in the way of the people you most want to reach.
The kerb-cut effect
Kerb cuts were designed for wheelchair users and are used daily by people with prams and suitcases. Websites work the same way: captions help anyone watching with the sound off, and clear headings help everyone skimming on a phone. That spill-over is the heart of the commercial case.
Where accessibility barriers cost you enquiries
Barriers tend to sit between a visitor arriving and getting in touch, exactly where you can least afford them. Walk the path in order.
Cookie banners and pop-ups
Many visitors meet a consent banner or pop-up first. If a keyboard can’t reach it, if it can’t be closed without a mouse, or if its “Reject” option is pale grey text, some visitors never reach your content at all. And a sticky banner that entirely hides the element with keyboard focus fails Focus Not Obscured (Minimum), a level AA criterion new in WCAG 2.2.
Check it yourself. Open your homepage in a private window, put the mouse aside and press Tab. Can you reach and dismiss the banner? Does Escape close any pop-up?
Navigation that only works with a mouse
Menus that open only on hover, menu buttons that can’t receive keyboard focus, focus outlines removed for looking untidy. Each locks out keyboard and switch users, and hover menus are awkward on touchscreens too.
Check it yourself. Tab through your main menu: you should always see where you are and reach every link. Then tap each item with your thumb. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for most targets at level AA; comfortable ones are larger. See accessible navigation for more.
Calls to action people can’t see
Pale grey text on white, white text on a light brand colour, a “ghost” button with a hairline border. WCAG 2.2 asks for a contrast ratio of at least 4.5:1 for normal text, and 3:1 for large text and for the visual parts people rely on to identify controls, such as form field borders. Buttons that fail are hard to read with low vision, or outdoors at noon.
Check it yourself. Run your button colours through a contrast checker, including hover and focus states, then read your key pages on your phone outdoors.
Forms that turn people away
Forms are where accessibility and conversion meet most directly. The usual barriers: placeholder text instead of labels, so the hint vanishes once someone types; errors shown only in red; a form that clears itself after a failed submission; phone fields that reject reasonable formats. Each also trips up people rushing on a small screen. How to design accessible forms covers the fixes.
Check it yourself. Submit your enquiry form empty, then with a deliberate mistake. Is each error explained in words, next to the field, with your other answers still in place?
CAPTCHAs and time limits
Image puzzles are a barrier for blind visitors and a chore for everyone else; the W3C’s note on the inaccessibility of CAPTCHA covers the problems and the alternatives. Time limits cause similar trouble: a booking form that expires while someone looks up a detail, and throws their answers away. WCAG asks that people can turn off, adjust or extend most time limits.
Check it yourself. List every point where a visitor must prove they’re human or beat a clock. Would a quieter defence, such as a honeypot field hidden from people and screen readers alike, or server-side spam filtering, do the job?
Accessibility and conversion rates: why fixes help everyone
There’s no reliable universal figure for how much accessibility lifts conversion rates, so distrust anyone who quotes one without a source. What you can rely on is the mechanism: most fixes remove friction that everyone meets to some degree, which is why the benefits of web accessibility reach well beyond disabled visitors.
| Fix | Essential for | Also helps |
|---|---|---|
| Visible labels above form fields | Screen reader users, people with memory difficulties | Anyone checking their answers before sending |
| Strong contrast on text and buttons | People with low vision | Phone users in sunlight, older eyes |
| Plain language | People with dyslexia or cognitive disabilities | Second-language readers, busy skimmers |
| Descriptive headings and link text | Screen reader users | Skimmers, search engines, AI tools |
Not every fix will move a conversion metric. A skip link, which spares keyboard users tabbing through the menu on every page, is there because people need it; the case doesn’t depend on every fix paying for itself.
There’s a search angle too. Accessibility isn’t a confirmed ranking factor in its own right, but meaningful headings, descriptive links and alt text also help search engines and AI tools understand a page; accessibility and SEO covers where the two overlap. And the thinking is the same as conversion rate optimisation: find the friction on the path to an enquiry, then remove it.
The rest of the case: buyers, risk and cost
Buyers ask about it
Many public bodies buy against accessibility standards, such as EN 301 549 in the European Union and Section 508 for US federal agencies, both built on WCAG. Larger organisations often set their own supplier policies too. If you sell software or a portal their people will use, expect to be asked for an Accessibility Conformance Report, often in the VPAT format. Even when you sell a service, a site that fails basic checks gives a procurement team a reason to hesitate.
Complaint and legal risk
Many countries have laws that reach websites, directly or through broader equality and consumer rules. In the US, websites have been the subject of many lawsuits under the Americans with Disabilities Act. In the EU, the European Accessibility Act has applied since 28 June 2025 to a range of consumer-facing services, including e-commerce and consumer banking, with an exemption for microenterprises that provide services. What applies depends on where your customers are, not just where you’re based, so take legal advice for the markets you serve.
Either way, the strongest protection is a site that genuinely works, not a statement claiming it does. An overlay plug-in won’t, on its own, make an inaccessible site conform. Our guide to accessibility audits, automated checkers and overlays explains what each can and can’t tell you.
Building it in costs less than retrofitting
Accessibility is cheapest as a decision, not a repair. Choosing a brand palette that passes contrast takes minutes at the design stage; changing brand colours after launch means reworking every page and graphic that uses them.
| Stage | Built in | Retrofitted |
|---|---|---|
| Strategy | WCAG 2.2 AA written into the brief | Found after a complaint or a failed tender |
| Design | Contrast-tested colours, visible focus styles, readable type | Colours and components reworked site-wide |
| Build | Semantic HTML and tested components | Menus, modals and forms rebuilt one by one |
| Content | Headings, alt text, link text and captions written as you go | Every page and PDF reviewed and rewritten |
| Ongoing care | New pages and plugins checked before they go live | Problems reported by users |
That’s why accessibility belongs in the whole project, not a line item at the end: strategy, UX, design, development, content and care all touch it.
How to make the case inside your organisation
- Walk your most valuable path. Go from your top landing page to a completed enquiry using only a keyboard, then zoomed to 200%, then on a phone outdoors. Screen-record what breaks; a short video often persuades more than a statistic.
- Try a screen reader. VoiceOver on Apple devices, TalkBack on Android or the free NVDA on Windows. Ten minutes on your own form is revealing.
- Use your own numbers. Check where people leave the enquiry path and, if you track them, compare form starts with submissions. Then value the enquiries at stake with the method in how to calculate website ROI.
- Check who’s asking. Tender documents, supplier questionnaires, customer complaints and the markets you sell into.
- Split quick wins from structural work. Contrast, labels and alt text are often quick. Inaccessible menus, modals or page templates may need rebuilding.
- Make it a standard, not a project. Put WCAG 2.2 AA in briefs and acceptance criteria, and check new pages before they publish.
What to do next
Accessibility isn’t only a moral or legal question. It’s part of what makes a website work: more people can use it, fewer give up before getting in touch, and fewer buyers find a reason to say no. And it costs least when it’s in the first brief.
When we plan and build a new website, accessibility is part of the first decisions: colour, type, components, forms and content. If barriers are baked into your current site’s structure, a website redesign is often a cleaner fix than patching page by page. And if you’d like to talk through what your own site needs, get in touch.