Accessibility: the legal case and the commercial one

The website accessibility business case is simple: an inaccessible site loses customers, invites legal action, and costs far more to retrofit than to build right from the start. An accessible site widens your market, reduces legal exposure, and lowers long-term maintenance. This article explains how to weigh both arguments and where to begin.

Key Takeaways

• Accessibility failures are usually invisible to a sighted developer but immediately obvious to a screen reader user or keyboard-only visitor.
• The legal risk is real and rising: demand letters, procurement rejections, and regulator complaints now target ordinary business sites, not just government portals.
• The commercial case is the stronger one in most boardrooms: accessible sites convert more visitors, rank better, and cost less to maintain.
• Retrofitting an existing site is far more expensive than building accessibly, but a phased fix programme still beats doing nothing.
• Automated checks catch maybe a third of real problems; manual keyboard and screen reader testing is where the truth shows up.
• Accessibility is an ongoing operational discipline, not a one-off project with a finish line.

What does accessibility actually cover in a live website?

Accessibility means a real person using a screen reader, keyboard, voice control, or a magnifier can complete the same tasks as anyone else. In practice that covers semantic HTML, labelled form fields, alt text, visible focus, colour contrast, captions, and respecting reduced-motion preferences. It is not a plugin you install; it is a property of how the site is built and maintained.

The WCAG 2.1 success criteria remain the reference point most regulators and procurement teams cite. They are organised around four principles: content must be perceivable, operable, understandable, and robust. A site fails when a button has no accessible name, a form input has no label, a colour alone conveys meaning, or a keyboard user gets trapped in a carousel. These are not edge cases; they are the daily experience of roughly a billion people worldwide.

Why does inaccessibility fail silently until it is expensive?

An inaccessible site fails quietly because the people it excludes do not complain to you. They just leave, or never arrive. A screen reader user hitting an unlabelled form field does not file a bug report; they abandon the basket. By the time the problem surfaces — in a demand letter, a lost tender, or a support ticket — the fix is structural, not cosmetic.

This is the core reason the website accessibility business case is hard to make after launch. The cost has already been incurred in lost sales you never measured. A common mistake we see is treating accessibility as a final polish step. It is more like plumbing: you notice it only when it fails, and fixing it after the walls are closed costs several times more than doing it during construction.

What is the legal case, and who does it actually bite?

The legal case is no longer confined to government sites. In the United States, ADA Title III claims against private businesses have become routine, and in the European Union the European Accessibility Act now applies to many e-commerce and service sites. Procurement in both public and corporate sectors increasingly demands a VPAT or equivalent conformance statement before a vendor is even shortlisted.

What you face in practice is not a criminal fine but a demand letter, a settlement negotiation, and a court-ordered remediation deadline. The cost of the settlement is often the smallest part. The forced remediation, legal fees, and the public record of the complaint are what hurt. In Nepal the regulatory pressure is lighter, but if you sell to EU, UK, US or Australian customers, their rules follow the transaction. The WCAG 2.1 quick reference is the practical checklist most settlements reference.

When do you actually need a formal accessibility programme?

You need a formal programme when your site serves the public, takes payments, or competes for contracts where accessibility is a stated requirement. You do not need one for a private internal tool used by a small, known team with no disabled members — though even then, an injury or a new hire can change that overnight. The trigger is not size; it is exposure.

In practice, the moment to act is before a redesign, not after. If the site is already live and moderately busy, a phased audit and remediation programme is the honest next step. If the site is old, page-builder-heavy, and scheduled for replacement anyway, folding accessibility into the rebuild beats retrofitting twice. Our team can help you assess which path fits before you commit budget to either.

How do you build the commercial case with real numbers?

The commercial case rests on three measurable outcomes. First, accessible sites convert a larger share of the same traffic because fewer people are blocked at the basket or the contact form. Second, semantic, well-structured pages tend to perform better in search because they are easier for crawlers to parse. Third, a component-based accessible build costs less to extend, since fixes apply once in a template rather than page by page.

The strongest number you can bring to a boardroom is the size of the excluded audience, not a compliance percentage. Roughly 15 percent of the world's population lives with some form of disability. The practical question is simpler: how much of your traffic abandons the site at a specific step? If analytics show a checkout drop-off you cannot explain, accessibility is one of the first places to look. You cannot fix what you have not measured.

How do you start an accessibility audit and remediation?

A credible audit combines automated scanning with manual keyboard and screen reader testing. Automated tools catch missing alt text, contrast failures and unlabelled inputs. They miss the things that actually break a journey: focus order that jumps, a menu that opens but never closes, a form that submits but silently drops errors. Manual testing is where real production defects show up.

Here is a safe, ordered sequence we use when taking over an existing site:

1. Run an automated scan — axe DevTools or Lighthouse — to get a baseline of mechanical failures. This is a read-only operation; it changes nothing on the site.
2. Walk the site with only a keyboard. Try to reach every link, button and form field, and check the focus indicator is visible at every step.
3. Run a screen reader pass with NVDA on Windows or VoiceOver on macOS. Listen for unlabelled buttons, missing headings, and announcements that make no sense out of context.
4. Group findings by impact: items that block a transaction, items that annoy but do not block, and cosmetic issues. Fix in that order.
5. Fix in templates and components first, not individual pages. A heading fix in the page template repairs every page that uses it.
6. Re-run the same three checks after each batch of fixes, and record the before-and-after so the change is visible to the person paying for it.

For a concrete example of good markup, a labelled input looks like this:

<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

<button type="submit">Subscribe</button>

The label is explicitly tied to the input with for and id, and the button has real text. A screen reader announces "Email address, edit text" instead of just "edit text". That single change removes a common source of abandoned forms.

How do you verify accessibility work is actually working?

Verification is not the same as running a scanner and seeing a green score. It means a disabled user can complete a real task without help. The only honest test is a scripted journey: find a product, add it to the basket, check out, and read the confirmation. Run that journey with a keyboard, then with a screen reader, and note where each one stalls.

Regression is the bigger risk after the initial pass. A developer adds a new carousel, a marketer uploads an image without alt text, a plugin update changes focus behaviour — and the site silently degrades again. The fix is to make the basic checks part of the release routine, not a quarterly audit. A short checklist that runs in CI or before each deploy keeps the cost flat instead of spiked.

What failure modes show up after go-live, and how do you debug them?

The most common post-launch failures are keyboard traps, missing focus indicators, and dynamically injected content that a screen reader never learns about. A keyboard trap usually comes from a modal or a menu that opens on hover or click but has no way to close it without a mouse. A missing focus indicator means a sighted keyboard user literally cannot see where they are.

Dynamic content is the subtle one. If a search results list updates without announcing the change, a screen reader user sees stale data and thinks the search failed. The debugging order is simple: reproduce with a keyboard first, because if it fails there it fails for everyone who cannot use a mouse. Then reproduce with a screen reader. Then inspect the DOM for missing aria-live regions, missing labels, or focus being set on an element that is not focusable.

What does accessibility cost to implement and keep running?

The cost drivers are the age and structure of the current site, the number of templates involved, and whether your team already owns the code. A clean component-based build can reach a defensible level of accessibility with modest effort. A page-builder site with dozens of hand-assembled pages is the expensive case, because there is no single place to fix a recurring pattern.

Operationally, the ongoing cost is mostly discipline, not tooling. Automated scanners are free or cheap. The real spend is engineer and designer time to test manually, fix templates, and document patterns so the next person does not reintroduce the same fault. That is why accessibility belongs in the definition of done, not in a separate project. Once it is part of the routine, the marginal cost per release drops sharply.

What security considerations come with accessibility fixes?

Accessibility and security rarely conflict, but they can when a fix introduces a new script or a third-party overlay. Overlay widgets that promise one-click compliance are a known risk: they inject JavaScript into every page, often load from a vendor you do not control, and can break focus and keyboard behaviour. They also create a false sense of compliance while the underlying markup remains inaccessible.

The safer path is to fix the source. If you must use a third-party component for captions or a consent banner, treat it like any dependency: check what it loads, keep it updated, and test it with a keyboard before it reaches production. Accessibility work should not expand your attack surface. Where we have seen problems, it is usually because a well-meaning fix introduced a script that later became a supply-chain risk.

What are the most common mistakes teams make?

The first mistake is relying on automated scores as proof of accessibility. A Lighthouse score of 100 does not mean a disabled user can complete a purchase. The second is treating accessibility as a one-off project and then letting it drift. The third is retrofitting a page-builder site page by page instead of fixing the underlying templates. Each of these feels cheaper in the moment and costs more over a year.

Another mistake is hiding the problem from the people who sign off the budget. If the team knows the checkout form is inaccessible but does not say so, the first time leadership hears about it is from a customer or a lawyer. A short written note with the specific barrier and the estimated fix is far better than silence. Our team can help you produce that assessment honestly, including what you can safely defer.

A concrete scenario: the retail site that lost a tender

A Kathmandu-based clothing brand sells to customers in the UK and Australia. Their site is attractive, built on a page builder, and converts well on mobile. They bid for a corporate bulk-order contract and are asked for a VPAT. They do not have one, so they commission a quick audit. The audit finds unlabelled form fields, a colour-only size selector, and a checkout flow that traps keyboard users.

The fix takes three weeks of focused work: labels on every input, a text alternative for the size selector, keyboard handling on the basket drawer, and alt text on the product images. The tender deadline passes, but they keep the fixes. Six months later the same buyer returns, and this time the brand passes the accessibility check. The commercial lesson is not that accessibility wins every deal; it is that being disqualified for a fixable reason is the most expensive way to lose.

Alternatives compared: retrofit, rebuild, or do nothing

There are three honest paths. Retrofitting the current site is right when the code is reasonably clean and the templates are few. Rebuilding is right when the site is old, page-builder-heavy, or already planned for replacement — folding accessibility into the rebuild costs far less than doing it twice. Doing nothing is a decision too, and it carries a compounding cost in lost sales and rising legal exposure.

Path	Best when	Cost driver	Risk
Retrofit in place	Clean code, few templates, moderate issues	Engineer time per template	Low if phased
Rebuild accessibly	Old or page-builder-heavy site, planned replacement	Full project budget	Medium, but one-off
Do nothing	Almost never, except a site due for retirement	Compounding lost revenue	High and rising

For most sites we see, the right answer is a phased retrofit: fix the blockers first, then the templates, then the content workflow. It spreads the cost, shows measurable progress, and keeps the site live while the work happens. A full rebuild only makes sense when the existing structure is beyond repair or the business already needs new functionality.

The website accessibility business case is not really about compliance. It is about not paying twice — once in lost customers you never saw, and again in a forced remediation you could have avoided. The legal argument gets attention; the commercial argument gets budget. Build the case around revenue and reach, keep the legal risk as the supporting point, and start with a keyboard walk of your own checkout. That single test will tell you more than any audit report.

If you want help assessing where your current site stands, or folding accessibility into a rebuild without a rewrite, our team can help you plan the work. We also handle ongoing website maintenance and website redesigns where accessibility is built in from the first wireframe, not bolted on after launch. See our portfolio for examples of sites we have taken from audit to accessible release.

People also search for

• What does a web development quote actually cover?
• Is it worth rebuilding an inaccessible website?
• Does a cheap website cost more later?
• What should I check before taking over a website?
• Custom website or WordPress for accessibility?
• What is a staging environment for testing changes?
• Who owns the code when we commission a website?
• How long does a website rebuild take?