Accessibility is now a sales requirement

Accessibility used to arrive in a project as a moral argument, which meant it was the first thing cut when the timeline tightened. That has changed. It now arrives in procurement documents, enterprise vendor questionnaires and tender requirements — and a failed checklist item loses the deal regardless of how good the work is.

For Indian studios and product teams selling to export clients, this is a commercial issue with a design solution.

Why it is showing up in your sales process

Three forces, converging.

Regulation in your buyer’s market. European accessibility rules now apply to a broad set of digital products and services sold there. American public-sector and education buyers have had requirements for years. Your buyer inherits the obligation and passes it to you.

Enterprise procurement. Large companies ask suppliers to document conformance because their own compliance depends on it. The document is often more important than perfection — but you cannot produce one from nothing.

Public tenders. Government and quasi-government work in several markets requires a stated standard. No statement, no bid.

None of this requires you to be flawless. It requires you to know where you stand and to say so credibly.

The work that fixes most of it

In our experience, the majority of real-world failures come from the same short list. Fix these and a site moves from indefensible to broadly conformant.

1. Colour contrast. Light grey text on white is the single most common failure, and it comes from designers working on excellent screens. Text needs a contrast ratio of at least 4.5 to 1 against its background. Large text can go to 3 to 1. Check it with a tool, not with your eyes.

2. Keyboard operability. Every interactive element must be reachable and usable with a keyboard alone, in a sensible order, with a visible focus indicator. Removing focus outlines because they look untidy is a failure — style them instead.

3. Real semantics. A div with a click handler is not a button. Use buttons for actions, links for navigation, proper headings in order, labels tied to inputs, and lists for lists. Most accessibility work is simply using the correct element.

4. Images and icons. Meaningful images need alternative text describing their purpose. Decorative images need empty alt text so screen readers skip them. Icon-only buttons need an accessible name — this one is missed constantly.

5. Forms that explain themselves. Visible labels, not placeholder text. Errors identified in text, not by colour alone. Error messages associated with the field they belong to. This has the largest usability payoff of anything on the list, for every user.

6. Motion respect. Honour the reduced-motion preference. Animation is part of good design — our own site leans on it — and it should switch off for people who ask it to.

7. Announced dynamic changes. When content updates without a page load — a filter applied, an item added to cart, a validation failure — screen reader users need it announced. Live regions handle this and are usually a small change.

What to test with

Automated tools catch perhaps a third of issues. Run them anyway because they are free, then do the manual pass that finds the rest.

The manual pass is thirty minutes: unplug your mouse and complete your main flow with the keyboard alone. Then run the same flow with the screen reader built into your operating system. You will find more in that half hour than in any report.

Test on a real phone at reduced brightness too. Contrast problems that are subtle on a desktop monitor are obvious outdoors on a mid-range phone — which is where much of your Indian audience actually is.

What to document

Procurement wants a document, so produce one before you are asked.

A short conformance statement covering: which standard and level you target, which parts of the product were evaluated, what conforms, what does not, and your remediation timeline for the gaps. Honest and specific beats optimistic and vague — buyers check, and a false claim is far worse than a disclosed gap.

Keep it dated and revise it when you ship fixes. It is the same discipline as the handover pack described in what happens after we ship: the document exists so somebody else can trust the work.

Why overlays do not work

A script that promises to make any site compliant overnight cannot repair markup it did not write. It cannot decide what an image means or fix an illogical heading structure. The accessibility community rejects them broadly, and their presence has featured in complaints rather than deflecting them.

Spend the same money on fixing the seven items above and you get a genuinely better product.

The cheap version: build it in

Retrofitting costs real money. Building it in costs almost nothing — a contrast check during design, correct elements during build, a keyboard pass before ship.

Add it to your definition of done and it stops being a project. This is exactly the kind of rule that belongs in the project rules file, where it applies to every task rather than being remembered occasionally.

The commercial framing

Everything on that list also helps users who are not disabled. Better contrast helps everyone reading on a phone in sunlight. Keyboard operability helps power users. Clear form errors reduce abandoned checkouts and support tickets — measurably, in the same way the fixes in the conversion post do.

You can make the ethical argument, and it is a good one. But if you need the budget approved this quarter, the argument that works is that a procurement checklist is standing between you and a signed contract.

Need a conformance statement and a remediation plan before a tender deadline? That is a scoped sprint, and it is usually faster than the deadline you are worried about.