Accessibility is treated by most Indian businesses as either a legal box for large organisations or something to consider later. It's neither. It's a set of practical decisions that make a website usable by more people — including people who aren't disabled at all.
Jayshree Technosoft LLP builds websites and business software, and this is a practical view rather than a compliance lecture.
The obvious group: people with visual, hearing, motor, or cognitive impairments. India has a substantial population here, and most business websites are effectively closed to them.
The less obvious and much larger group:
Older users, who increasingly transact online and struggle with small text and low-contrast design.
Anyone on a bad connection, where images don't load and only text remains — if the text makes sense without the images.
Anyone in bright sunlight, which is a lot of people in India, where low-contrast grey-on-white text becomes unreadable.
Anyone using one hand while doing something else. Small tap targets fail.
Anyone with the sound off, which is most people watching video in public.
Accessibility improvements help all of these simultaneously. That's why the business case doesn't depend on the compliance case.
Adequate colour contrast. Light grey text on white looks refined on a designer's screen and is unreadable on a phone in daylight. This is the single most common accessibility failure on Indian business websites and among the easiest to fix.
Text that can be enlarged. Users increase text size on their devices. Layouts that break when they do exclude those users entirely.
Tap targets big enough to hit. Buttons and links too small or too close together frustrate everyone and defeat people with any motor difficulty.
Descriptive alt text on meaningful images. Screen readers rely on it, search engines use it, and it's what displays when an image fails to load on a slow connection. Three benefits from one small habit.
Forms with proper labels. Placeholder text that disappears when you start typing is a genuine usability failure — users forget what a field was for. Visible labels solve this for everyone.
Meaningful link text. "Click here" tells a screen-reader user nothing when links are read out of context. "Download our price list" works.
Captions on video. Required for deaf users, and used by the large majority of people watching without sound.
Keyboard navigation. Everything usable without a mouse. This matters for motor impairments and it's also how power users work.
Government and public sector procurement in India carries accessibility requirements, and standards for government websites exist and are enforced in tenders. A business that can't meet them is excluded from bidding.
Enterprise buyers ask. Larger organisations increasingly include accessibility in vendor questionnaires, particularly multinationals whose own obligations flow down to suppliers.
International clients have stricter requirements. If you sell software or services to buyers in markets with strong accessibility legislation, their obligations become your requirements.
It overlaps heavily with SEO. Proper heading structure, descriptive link text, alt attributes, and clean semantic markup help screen readers and search engines for the same reasons.
India's disability rights framework establishes obligations around accessibility of services and information, and government websites are subject to specific standards. Requirements and enforcement vary by sector and by whether an organisation is public or private.
This is an area to take proper advice on if you're bidding for government work or operating in a regulated sector — the position is more specific than a blog post can usefully summarise.
For a typical private business, the practical position is that good accessibility is currently more of a commercial and ethical matter than an enforcement one — and that this is likely to tighten rather than loosen.
Considerably less than businesses assume, if it's designed in.
Adequate contrast, readable text sizes, proper labels, alt text, and sensible tap targets cost essentially nothing at design stage. They're decisions rather than features.
Retrofitting is where cost appears — reworking an existing design, adding alt text to hundreds of images, restructuring forms. Which is the usual argument for doing it at build time.
Be cautious of "accessibility overlay" tools that promise instant compliance through a script. They address a narrow set of issues, don't fix underlying problems, and have been criticised by accessibility advocates and users themselves. Real accessibility is in the build, not in a widget.
Three things you can do today without any tools:
Increase your browser's text size substantially and see whether the layout still works.
Try navigating using only the keyboard — can you reach and use everything?
Look at your site on a phone in bright sunlight. If you're squinting, so is everyone else.
Free automated checkers catch technical issues, and they only catch part of the picture — but they're a useful starting point for anything systematic.
Systems your staff use daily face the same considerations. An interface with small text and low contrast is harder for an older employee, harder in a poorly lit workshop, and harder for everyone at the end of a long shift.
This is part of why adoption succeeds or fails — the systems people find comfortable to use get used, and the ones that strain get bypassed.
Jayshree Technosoft LLP builds accessibility considerations into websites and business software from design rather than adding them afterwards — adequate contrast, scalable text, proper labels and structure, keyboard navigation, and alt text as standard practice.
It costs almost nothing at build time, it makes sites work better for everyone, and it keeps clients eligible for contracts that require it.
Building a new site, or unsure whether your current one would meet requirements? Get in touch — and take specific legal advice if you're bidding for government or regulated work.