For most Indian product teams, accessibility arrives as a question in an enterprise procurement pack: does your product conform to WCAG 2.2 AA, and can you provide a conformance report. It is at that moment - deal in progress, months of work required - that teams discover accessibility is a design constraint rather than a feature, and that retrofitting it into a mature interface is among the more expensive corrections in software.
Understanding why it appears in the questionnaire helps. Large buyers in the US, UK and EU carry their own legal obligations, and those obligations flow to their suppliers. Public sector buyers are usually bound directly. The European Accessibility Act extends similar requirements to a range of private-sector digital services. Your buyer is not being idealistic; they are managing their own exposure, which is why it is rarely negotiable.
The good news is that most of the requirement is unglamorous and cheap if done early. Every interactive element reachable and operable by keyboard alone. Visible focus indicators. Form inputs with real labels, not placeholder text pretending to be labels. Text contrast meeting the ratio. Images with alternative text - and genuinely decorative images marked as decorative, with an empty alt attribute, so screen readers skip them. Headings in a sensible hierarchy. Errors announced rather than only coloured red.
The expensive parts are the custom widgets: a bespoke dropdown, modal, date picker or data grid built from generic elements has none of the keyboard behaviour or screen reader semantics the native equivalent gives free. This is where using an accessible component library - React Aria, Radix and similar - saves more time than any other single decision, because the hard behaviour is already correct.
For testing, automated tools catch perhaps a third of issues and are still worth running in CI on every pull request, because they catch regressions cheaply. The rest needs a person: navigate a core journey with the keyboard only, then with a screen reader. Both are free and available on any machine, and half an hour on your main flow finds more than a week of reading guidelines.
What procurement usually wants is documentation - an accessibility conformance report describing how the product meets each criterion, including where it does not. Being honest about gaps with a remediation date is generally acceptable; claiming full conformance that a buyer's own test disproves is not, and is a considerably worse position than admitting the gap. Build the report once, keep it current, and it stops being a fire drill on every deal.
