The language we use to describe a problem shapes the solutions we build for it. When organisations speak of accessibility as a "feature," they have already encoded a particular relationship between the default design and the people for whom that design doesn't work. The feature is an addition to something that already exists. It is optional until required. It is planned after the core product is complete. It is assigned to a team working in parallel to the main development effort, usually with fewer resources and less seniority.
This linguistic and organisational framing produces a predictable outcome: accessibility that is inadequate, perpetually incomplete, and experienced by the people it is meant to serve as exactly what it is — an afterthought.
I have watched this play out in AI systems designed for education, for healthcare, for employment, and for public services. The main interface is built. The core functionality is tested. The launch date approaches. And then — as a final item in the project plan, or in response to a complaint, or because a regulatory requirement has arrived — accessibility is addressed. By then, the fundamental architecture of the system has been determined. Retrofitting accessibility into a design that was not built for it produces something technically compliant and practically unusable.
"When we treat accessibility as a feature to be added after the core product is built, we guarantee that it will be inadequate. The only way to build AI that serves every mind is to start by designing for those who are currently excluded."
The population affected by inaccessible AI is not small. The World Health Organization estimates that 1.3 billion people — approximately one in six of the global population — live with some form of significant disability.1 In India alone, the figure is 26.8 million, though this almost certainly undercounts the true prevalence.2
These are not people at the periphery of AI's intended users. They are students in classrooms where AI tutoring systems are being deployed. They are workers in workplaces where AI performance management systems are running. They are patients in healthcare settings where AI diagnostic tools are informing clinical decisions. They are citizens whose government services are being delivered through AI-powered interfaces. They are, in every meaningful sense, among the primary affected populations of AI deployment — and AI systems are systematically designed without them.
The consequences of this exclusion are not mild inconveniences. A visually impaired student who cannot use the AI learning system her school has deployed falls behind students who can. A worker with speech impairment who cannot interact with a voice-first AI interface is evaluated on a performance metric he cannot meet. A person with cognitive disabilities who encounters an AI interface that assumes linear, uninterrupted attention is excluded from services he is entitled to access.
The Universal Design for Learning framework, developed by CAST over three decades of research and practice, articulates a principle that applies directly to AI: accessibility built into the architecture from the beginning produces better outcomes for all learners, not only those with disabilities.3 The curb cut effect — the observation that features designed for wheelchair users (lowered kerbs, ramps, smooth surfaces) are consistently used by and benefit a much broader population (parents with prams, cyclists, delivery workers, travellers with luggage) — has been documented across physical design, digital design, and educational design.4
In AI design specifically, this means that systems built with screen reader compatibility from day one are better structured for all users. Systems designed for voice interaction at variable speeds and with speech recognition that handles atypical speech patterns produce better speech recognition for everyone. Systems designed for cognitive accessibility — clear, predictable, low-ambiguity interactions — are easier to use for every person encountering them under stress or time pressure.
When we designed the AI curriculum for the post-Grade 10 cohort at Asha Kirana School, we built the Track A (Blind & Low-Vision) curriculum entirely from voice-first principles — not as a modified version of a sighted curriculum, but as its own architecture. The Web Speech API narrated every lesson on demand. The interface required no visual navigation. It ran on low-cost Android phones and worked offline. When we observed students using it, something unexpected happened: the students who had the most prior experience with technology engaged differently with the voice-first interface than with the visual one. They moved through it faster. They retained more. The design constraint of building for blindness had produced a better learning experience — not a compromised one.
The Social Model of Disability, developed by disability scholars and activists from the 1970s onwards — associated particularly with the work of Michael Oliver and later Tom Shakespeare — makes a foundational distinction: between impairment (a difference in bodily or cognitive function) and disability (the exclusion produced when the environment fails to accommodate that difference).5 On this account, disability is not an inherent property of a person. It is a relationship between a person and an environment that was not designed for them.
Applied to AI, the Social Model has a specific and demanding implication: when an AI system excludes a person with a visual impairment, a hearing impairment, a cognitive difference, or a motor disability, the problem is not the person's impairment. The problem is the system's design. The person is not failing to meet the system's requirements. The system is failing to meet the person's needs.
This reframing matters enormously for how we think about AI development. If accessibility is a person's problem — a deficit to be accommodated in a product designed for others — then accessibility features are add-ons, necessary but secondary. If accessibility is a design problem — a gap between the system's architecture and the full range of people the system is meant to serve — then inaccessibility is a design failure, with the same status as any other design failure: something to be fixed, not accommodated.
What would it mean to treat accessibility as a standard rather than a feature in AI development? At minimum, it would mean three things.
First, accessibility requirements — including WCAG 2.1 AA compliance, screen reader compatibility, voice interface parity, cognitive accessibility guidelines, and support for assistive technologies — would be specified as requirements before design begins, not after. They would be part of the definition of what constitutes a successful system, not a list of modifications to be applied to a system already considered complete.
Second, people with disabilities would be included in design research, user testing, and evaluation throughout the development process — not invited to provide feedback on a finished product. Co-design with disabled communities produces different systems than consultation after the fact. The knowledge of what accessibility requires in practice is held by the people who navigate inaccessible environments every day; it cannot be adequately substituted by compliance checklists or proxy testing.6
Third, organisations deploying AI systems would be accountable for accessibility not at launch but over time — as the system changes, as the population it serves changes, and as the understanding of what accessibility requires continues to develop. Accessibility is not a state that a system achieves and then maintains without effort. It is a practice.
"The knowledge of what accessibility requires is held by the people who navigate inaccessible environments every day. It cannot be adequately substituted by compliance checklists."
In India — the context where much of my field work has taken place — the policy gap is structural. Government-funded educational platforms, including Diksha, SWAYAM, and PM eVidya, do not currently mandate WCAG 2.1 compliance. The PMKVY (Pradhan Mantri Kaushal Vikas Yojana) skilling framework does not include an AI Qualification Pack designed for persons with disabilities. The national teacher training infrastructure does not include modules on accessible AI delivery.
This is not a gap in aspiration — the RPwD Act 2016 and NEP 2020 both commit to inclusive education. It is a gap between commitment and implementation architecture. The systems that would make the commitment real do not yet exist. Building them is one of the clearest policy priorities of the current moment in Indian AI development.
And it is urgent. The AI systems being designed today for Indian classrooms, workplaces, and public services will shape the life outcomes of hundreds of millions of people for decades. The accessibility decisions embedded in their design — or absent from it — are not minor technical choices. They are decisions about who is included in the future that AI is building.
Accessibility is not a feature. It is a standard. And a standard applies from the beginning, or it does not apply at all.