The Revolution That Left Us Out: Disability, AI, and the Incomplete Conversation About Humanity

 

While the 'Revolution' digitizes the horizon for the elite, the rest of us are still waiting for the pavement under our feet to be fixed.

A recent article in The Hindu, titled "Keeping Humanity at the Centre of the AI Revolution," [Click here for link to the article] raises questions that matter. It asks whether the rapid advance of artificial intelligence systems is moving faster than our collective ability to govern them. It is concerned with the risks of automation displacing labour, with the concentration of technological power in a small number of corporate actors, and with the erosion of human agency in decisions that shape livelihoods and social participation. These are serious concerns. They deserve serious examination.

But the article says a great deal about humanity and very little about a substantial part of it.

Disability does not appear in that conversation. Not once. And that absence is not a minor editorial oversight. It is symptomatic of a much older pattern: disability is admitted into the AI ethics discourse only when someone specifically demands its inclusion. It does not arrive on its own. It has to be carried in, repeatedly, by the same people who bear its exclusion.

This article is that demand.

What the Conversation Is Getting Right, and What It Is Missing

The concern with human-centred AI is not new. Researchers, civil society organisations, and several governments have spent years arguing that artificial intelligence must be designed with people in mind rather than profits or efficiency metrics. The Hindu article reflects this concern well. It draws attention to the fact that AI systems, however sophisticated, are built upon choices made by people. Those choices carry values. Those values carry biases. And those biases reproduce the social conditions that shaped them in the first place.

This is an important argument. It is also, in the disability rights community, an argument we have been making for the better part of a decade.

The AI Now Institute's foundational 2019 report, "Disability, Bias, and AI," made exactly this case. It documented how artificial intelligence systems, when trained on data that underrepresents disabled people, produce outputs that treat non-disabled behaviour as the universal standard. The systems are not neutral. They are calibrated to a particular body, a particular mode of speech, a particular speed of response, a particular pattern of interaction. When disabled users fall outside those calibrations, they are not accommodated. They are rejected.

That report was published six years ago. Mainstream AI ethics commentary in India is still not routinely engaging with it.

The Hindu article's conversation about humanity is, in this sense, a conversation about a subset of humanity. It addresses displacement of labour, questions of democratic accountability, the ethics of automation in public services. All of this is important. But when disability is absent from the frame, what emerges is an incomplete picture of who stands to be most harmed, and therefore an incomplete framework for remedy.

Technoableism Is Not a Technical Problem. It Is a Political One.

The word technoableism was put into sustained analytical use by Ashley Shew, a disability studies scholar and engineer at Virginia Tech, whose 2020 work in IEEE Technology and Society Magazine named the ideology that drives much of what passes for progressive AI design. Technoableism is the assumption that disability is a problem requiring technological elimination. It is the belief that the goal of assistive or accessible technology is to make the disabled person function more like a non-disabled person. It frames difference as defect, and positions the non-disabled body as the ideal towards which all technological development ought to strive.

This ideology does not announce itself. It arrives quietly, encoded into design decisions that no one has bothered to question.

Consider how this operates across the AI development pipeline. When training data for voice recognition systems is assembled, the overwhelming majority of voice samples are from speakers without speech disabilities. The system learns what a voice is supposed to sound like. When a person with cerebral palsy, amyotrophic lateral sclerosis, or a stammer interacts with that system, the system fails. Not because the technology is inherently incapable. Because the people who built it did not think to include the full range of human speech in their model of what a human voice sounds like.

This is Selection Bias. It is also a straightforward act of exclusion. It is not accidental. It is the consequence of disabled people being absent from the design room, the data team, the product meeting, and the ethics board.

The same logic applies to hiring systems that flag disabled communication styles as indicators of low confidence or low performance. It applies to facial recognition systems that fail to accurately identify people with atypical facial features or expressions. It applies to content moderation systems that flag disability-related language as offensive without distinguishing between slurs and community self-identification. It applies to large language models that, when asked to generate disability-related content, produce outputs that are clinical, condescending, and rooted in medical deficit models rather than disability rights perspectives.

Research published in 2025 by Panda, Agarwal, and Patel, introducing the AccessEval benchmarking framework, confirmed that disability bias in large language models is systemic rather than incidental. These are not edge cases. They are structural outcomes.

India's AI Moment and the Disability Rights Framework It Is Ignoring

The Hindu article is written in an Indian context, addressing an Indian readership, at a moment when India is making significant policy commitments around artificial intelligence. The India AI Impact Summit, NITI Aayog's AI governance guidelines, and the government's broader rhetoric about an "AI for All" future all claim a vision of inclusive technological development.

That vision does not hold up to scrutiny when examined from a disability rights standpoint.

India has 2.74 crore persons with disabilities according to the 2011 Census. The true figure is considerably higher by most independent estimates, given systemic undercounting. These individuals are spread across urban and rural geographies, across caste and class divisions, and across 21 categories of disability formally recognised under the Rights of Persons with Disabilities Act 2016. They are also among the most dependent upon digital public infrastructure for access to services, entitlements, information, and economic participation.

Yet NITI Aayog's AI governance documents, as I have argued previously on this platform and in an open letter to the Ministry of Electronics and Information Technology, treat disability as a sectoral afterthought rather than a structural dimension of all AI systems. The guidelines speak of inclusion in general terms. They do not mandate disability-inclusive data collection. They do not require accessibility impact assessments for AI systems deployed in public services. They do not integrate the RPwD Act 2016 into their governance framework. They do not reference the Supreme Court's landmark judgment in Rajive Raturi v. Union of India, which in November 2024 established accessibility as an ex-ante constitutional duty rather than a discretionary accommodation.

The Raturi judgment is significant precisely because it forecloses the kind of argument that AI governance currently makes by implication: that accessibility will be addressed eventually, after the core system is built. The Supreme Court held that accessibility is not a post-hoc retrofitting exercise. It is a baseline requirement that must be built into new infrastructure from the start. That principle applies with full force to AI systems, which are new infrastructure. If it applies to ramps and lifts, it applies to hiring algorithms and speech interfaces.

India's position under the United Nations Convention on the Rights of Persons with Disabilities reinforces this obligation. Article 4(1)(d) of the UNCRPD requires state parties to refrain from engaging in any act or practice that is inconsistent with the Convention, and to ensure that public authorities and institutions act in conformity with it. Article 9 requires accessible information and communication technology as a matter of right. These are not aspirational norms. India ratified the UNCRPD in 2007. The obligations are binding.

When The Hindu publishes a substantive opinion piece about keeping humanity at the centre of the AI revolution, and does not engage with these legal frameworks or the constituencies they protect, it participates in the same pattern of omission that characterises the policy it is critiquing. The critique of AI governance cannot exempt itself from the structural blind spots of AI governance.

The Difference Between Accessibility and Inclusion

There is a distinction that this discourse consistently collapses, and it is a distinction that persons with disabilities experience with considerable personal consequence.

Accessibility determines whether a person can use the system. Inclusion determines whether the system was designed with that person as a full human subject, rather than as an edge case to be accommodated later.

Accessible platforms built upon biased algorithms do not remove barriers. They move the barrier from the interface to the algorithm. A screen-reader-compatible job application portal that feeds into a hiring algorithm trained to penalise atypical speech patterns or non-linear employment histories is accessible in a technical sense and exclusionary in a structural one. The disabled applicant can submit the application. The system will still reject them.

The conversation about human-centred AI must therefore go further than user interface accessibility. It must address the assumptions embedded in the data, the objectives embedded in the optimisation function, and the absences embedded in the design team. Universal Design is not a feature to be added on. It is a methodology of designing from the margins outward, such that systems built to work for the most excluded users tend to work better for everyone.

The curb-cut effect, well documented in both physical and digital environments, illustrates this principle. Features designed for wheelchair users, closed captions developed for deaf and hard-of-hearing users, voice interfaces developed for users with motor impairments: these have consistently expanded usability for the broader population. Disability-led design is not charity. It is better engineering. It is a stress test for inclusion that the mainstream AI development pipeline systematically refuses to conduct.

Nothing About Us Without Us Is Not a Slogan. It Is a Design Requirement.

The principle of Nothing About Us Without Us, central to the disability rights movement since the 1980s, is sometimes treated by technologists as a vague aspirational gesture. It is in fact a precise methodological requirement.

It means that disabled people must be present at the data collection stage, so that training datasets capture the full range of human speech, movement, cognition, and behaviour. It means that disabled people must be present at the design stage, so that the objectives of the system are not calibrated exclusively around non-disabled norms of productivity, efficiency, and interaction. It means that disabled people must be present at the evaluation stage, so that bias audits assess performance across the full spectrum of the population rather than optimising for majority user groups and treating minority outcomes as acceptable collateral.

Research from the AAAI Conference on Artificial Intelligence in 2025, examining ableism in both Western and Indic language models, found that Indian AI systems consistently underestimate the harmfulness of ableist statements. The models reflect the cultural tolerances of the dominant society they were trained on. When that society normalises certain forms of disability-related discrimination, the model inherits that normalisation. Building cross-cultural competence into AI evaluation frameworks is therefore not an academic nicety. It is a basic requirement of fairness for the 2.74 crore Indians whose lives will increasingly be shaped by these systems.

This is the argument that the human-centred AI conversation must make room for. Not as a supplement to the main concern. As part of it.

Conclusion: Incomplete Humanity Is Not Humanity

The Hindu article is concerned about AI doing things to people without their meaningful participation. That concern is legitimate and necessary. But it is also incomplete. Because the people most likely to have AI systems act upon them without their participation, without their input into the training data, without representation in the design team, without recourse in the legal framework, without visibility in the policy document, are disabled people.

Disability is not a niche interest within the AI ethics discourse. It is the discipline's most rigorous test case. If an AI system cannot account for the full range of human bodies, minds, speech patterns, and modes of being in the world, it has not achieved human-centred design. It has achieved able-bodied-centred design dressed in the language of inclusion.

India is at a formative moment in shaping its AI ecosystem. The decisions being made now, about data, design, governance, and accountability, will embed their assumptions into public infrastructure for decades. If disability is absent from those decisions, the resulting systems will not be accessible to 2.74 crore Indians by omission. The omission will be structural and, given the legal frameworks now in place, unconstitutional.

The conversation about keeping humanity at the centre of the AI revolution must therefore include all of humanity. Not as a courtesy. As a constitutional obligation, as a matter of rights, and as a basic condition of the claim that the revolution is being made for people.

Those of us who have spent our lives being treated as edge cases, as outliers, as system anomalies, are not interested in watching another revolution proceed without us. We are the stress test. We are also the users. And it is past time that the mainstream AI ethics discourse remembered both.\

References

• Whittaker, M., Alper, M., Bennett, C.L., et al. (2019). Disability, Bias, and AI. AI Now Institute. https://ainowinstitute.org/disabilitybiasai-2019.pdf
• Shew, A. (2020). Ableism, Technoableism, and Future AI. IEEE Technology and Society Magazine, 39(1), 40-85.
• Panda, S., Agarwal, A., and Patel, H.L. (2025). AccessEval: Benchmarking Disability Bias in Large Language Models. Proceedings of EMNLP 2025. ACL Anthology.
• Phutane, M., Seelam, A., and Vashistha, A. (2025). A Human-Centered Audit of Ableism in Western and Indic Language Models. AAAI Conference on Artificial Intelligence.
• Rajive Raturi v. Union of India and Others, Writ Petition (Civil) No. 4/2005, Supreme Court of India, Judgment dated 8 November 2024.
• Rights of Persons with Disabilities Act, 2016. Ministry of Law and Justice, Government of India.
• United Nations Convention on the Rights of Persons with Disabilities, 2006. Articles 4 and 9.
• Singit, N. (2025). An Open Letter to the Ministry of Electronics and Information Technology: A Critique of the India AI Governance Guidelines on the Omission of Mandatory Disability and Digital Accessibility Rules. The Bias Pipeline. https://thebiaspipeline.nileshsingit.org
• Singit, N. (2026). Technoableism and the Bias Pipeline: How Ableist Ideology Becomes Algorithmic Exclusion. The Bias Pipeline. https://thebiaspipeline.nileshsingit.org
• Singit, N. (2026). TechnoAbleism in India's AI Moment: Why Accessibility Is Not Enough. Moneylife.in / The Bias Pipeline. https://thebiaspipeline.nileshsingit.org

You Have the AI. Now Make It Build Something Everyone Can Use.

  A Practical Guide to WCAG 2.2 Compliance When Using AI-Generated and Vibe-Coded Websites

Look at that, they’ve finally given the AI an intelligence upgrade—it’s building things we can actually use!

In the earlier article on this blog, the argument was made that AI coding tools — when used carelessly or under pressure — tend to reproduce the same patterns of inaccessibility that already exist on the web. They learn from what is out there. What is out there was mostly built without disabled users in mind. So the output carries the same bias forward, often faster than before.

That article explained why the problem exists. This one is about what to do instead.

The good news is that you do not have to wait for the tools to improve on their own. You can intervene. You can set conditions, write better prompts, configure your tools differently, and build habits into your workflow that make accessibility the default outcome rather than an afterthought. This is possible even if you are relatively new to web development. In fact, if you are just starting out, this is the right time to build these habits. It is far harder to unlearn poor practice than it is to start correctly.

This guide walks through the main steps. It focuses on WCAG 2.2 compliance, which is the current standard published by the World Wide Web Consortium. The four principles of WCAG are Perceivable, Operable, Understandable, and Robust. These are sometimes abbreviated as POUR. Keep that word in mind. It is a reasonable test to apply to anything you build.

Step One: Set Up Your Prompt as a Standing Instruction

Most AI coding tools allow you to write a system prompt, a custom instruction set, or a project-level configuration that gets applied to every request in a workspace. This is not a feature that most new developers use for accessibility. It should be the first thing you configure.

Before you write a single line of code, open the settings for your workspace or project and add a standing instruction along the following lines:

"All code you generate for this project must comply with WCAG 2.2 at Level AA. Every image must have a meaningful alt attribute, not a placeholder such as 'alt' or 'image'. Every interactive element must have a visible label and an accessible name. Headings must follow a logical order: one H1 per page, H2 for sections, H3 for sub-sections. Do not skip heading levels. Forms must associate every input with a label element using a 'for' attribute that matches the input's 'id'. Colour contrast must meet a minimum ratio of 4.5 to 1 for normal text and 3 to 1 for large text. All functionality must be operable by keyboard alone."

The important point is that this instruction must be present before you begin. If you add it later, you will spend considerable time correcting code that was already generated without it.

Step Two: Write Accessibility Requirements Into Every Prompt

The standing instruction sets a baseline. But it is not enough on its own. Research from the CHI Conference on Human Factors in Computing Systems has shown that developers using AI coding assistants regularly forget to request accessible output for individual components, even when they intend to follow good practice. The tool does not remind you. You have to remember.

The practical solution is to develop a habit of ending every prompt with an accessibility check. If you are asking the tool to generate a navigation menu, do not just describe the visual layout and the links you want. End the prompt with: "Ensure this component is fully keyboard-navigable, uses appropriate ARIA roles where HTML semantics are insufficient, and includes visible focus indicators on all interactive elements."

If you are generating a form, add: "Associate every label with its input using matching 'for' and 'id' values. Mark required fields in a way that does not rely on colour alone. Provide clear error messages that are programmatically associated with the relevant input using 'aria-describedby'."

If you are generating a modal or dialog, add: "The dialog must trap keyboard focus while it is open. It must return focus to the triggering element when it closes. It must be dismissible using the Escape key."

These additions cost you perhaps ten to twenty seconds per prompt. What they save is the time required to fix inaccessible output after the fact, which is considerably longer and considerably more difficult when the structure of the component is already set.

Step Three: Do Not Accept Generated Code Without Reading It

This is the step that vibe coding skips entirely. Vibe coding means you describe what you want, the AI produces code, and you paste it in. It is fast. It is also how inaccessibility gets embedded into production code at scale.

Research by Mowar and colleagues from 2024 found that developers consistently accepted AI suggestions without checking them. They accepted placeholder alt text without replacing it, heading structures that were out of order, and forms without labels. These failures are not obscure. They are visible in the code itself, provided you read it.

Develop a short review checklist to run through every time you accept generated code. Five checks will catch the most common failures.

First: look at every image tag. Is there an alt attribute? Does the alt value describe what the image actually shows? If the image is decorative, the alt value should be empty: alt="". It should not say "image" or "photo" or be absent altogether.

Second: look at the heading tags. Is there only one H1? Do the headings descend in logical order? An H3 should not appear before an H2 has introduced the section it belongs to.

Third: look at every input element in any form. Does each one have a label element? Does the label's 'for' attribute match the input's 'id'? A placeholder attribute is not a label. It disappears when the user starts typing.

Fourth: look at every button and link. Does each one have text or an accessible name that describes what it does? A button that says "Click here" or a link that says "Read more" tells a screen reader user nothing about where the link goes or what the button does.

Fifth: look at any use of colour to convey information. If something is shown in red to indicate an error, is there also a text label or an icon that conveys the same information? Colour alone is not a sufficient signal.

This review takes two or three minutes for a typical component. It is not a burden. It is the difference between producing something that works for everyone and producing something that works only for some.

Step Four: Configure Automated Checking Into Your Build Process

Manual review is necessary. It is not sufficient. Some accessibility failures are structural and not immediately visible by reading the code. Colour contrast ratios, for instance, require a calculation. Focus order depends on the rendered DOM, not the source code. ARIA relationships can be technically present but logically broken.

Automated accessibility checkers can catch a significant portion of these issues before anything reaches a user. The most commonly used tool is axe-core, available as a browser extension and also integrable into build processes for projects using Node. Another widely used option is the WAVE browser extension from WebAIM. Both are free.

If you are building with a framework such as React or Vue, linting tools can flag accessibility problems in real time during development. For React, eslint-plugin-jsx-a11y is the standard choice. It will flag missing alt attributes, improper ARIA usage, and other common violations as you write.

The limitation of automated tools is important to understand. They typically catch around thirty to forty per cent of WCAG failures. A tool can tell you whether an alt attribute is present. It cannot tell you whether the alt text is meaningful. Automated tools are a floor, not a ceiling.

Step Five: Test With a Screen Reader Before You Publish

This step is skipped more often than any other. It should not be. A screen reader test reveals problems that code review and automated tools both miss, because it shows you how the page actually behaves in use.

NVDA is a free screen reader for Windows. VoiceOver is built into macOS and iOS and needs no installation. Turn the screen reader on, navigate using only the keyboard, tab through the interactive elements, use the heading navigation shortcut to move through the page structure, fill in a form, and activate a modal. Note anything confusing, missing, or out of order. Fix it before publishing.

You can also ask your AI tool to review code from a screen reader perspective. A prompt such as "Review this component and identify elements that a screen reader user would find confusing or inaccessible" will often surface problems a general review misses. It is not a substitute for testing with an actual screen reader. It is a useful intermediate step.

Step Six: Handle Colour, Motion, and Cognitive Load

WCAG covers more than headings and labels. Three areas that AI-generated code frequently handles poorly are colour contrast, motion, and reading complexity.

For colour contrast, use a tool such as the Colour Contrast Analyser from TPGi or the contrast checker at WebAIM.org. Enter the foreground and background colours your code uses and check that the ratio meets the WCAG 2.2 requirement. If your AI tool generates CSS with colour values, check those values before accepting the suggestion. Light grey text on a white background is an extremely common failure in AI-generated designs.

For motion, any animation that plays automatically and lasts more than five seconds must have a mechanism to pause, stop, or hide it. This is a WCAG 2.2 requirement. More importantly, it is a genuine problem for people with vestibular disorders, epilepsy, and certain cognitive differences. When generating animations or transitions, add to your prompt: "This animation must respect the user's 'prefers-reduced-motion' media query setting. If the user has set their system to reduce motion, the animation should not play."

For reading complexity, consider the plain language of any text you generate alongside your code. WCAG 3.1 requires that the language of a page is identified in the HTML. More broadly, content that is written in unnecessarily complex language excludes users with cognitive differences, users for whom English or Hindi or whichever language the site uses is not their first language, and users who are reading under stress or fatigue. Ask your AI tool to generate content at a reading level that is clear and direct. Check it yourself before publishing.

The Broader Point

Accessible code is not a special category of code that you add at the end of a project. It is good code. It is code that has been built with an accurate understanding of who uses the web. That understanding includes people who navigate by keyboard, people who use screen readers, people who cannot distinguish between certain colours, people who experience seizures, people who process information differently, and people who are using older or lower-specification devices.

In India, these are not edge cases. The official count of persons with disabilities in the country is over 26 million, and independent assessments suggest the real number is considerably higher. Under the Rights of Persons with Disabilities Act 2016 and under Article 9 of the UNCRPD, which India ratified in 2007, there is a clear legal framework that places the obligation for accessible digital services on the organisations that provide them.

If you are building a website, you are providing a digital service. If that service is inaccessible, the person who cannot use it has not merely been inconvenienced. They have been excluded from something to which they have a right.

AI tools can help you build accessible websites. They can also make it very easy to build inaccessible ones very quickly. The difference is almost entirely in how you use them. Set the right instructions, write the right prompts, read the code you accept, run the checks, test with a screen reader, and fix what you find. None of this requires advanced expertise. It requires the decision to make it a habit.

Start with that decision. The rest follows.

This article is a follow-up to "The Roots of Technoableism: Why Forced AI Coding Is Making the Web Less Accessible," published on The Bias Pipeline on 29 March 2026.

The Roots of Technoableism: Why Forced AI Coding Is Making the Web Less Accessible

The "Zabardasti AI" Mandate: A Cartoon on Corporate Techno-Ableism and Inaccessibility

John Xavier's article in The Hindu, published on 28 March 2026, raises a concern that deserves serious attention. He shows how companies that force artificial intelligence tools upon their employees tend to achieve the opposite of what they set out to do. Workers at Shopify, Duolingo, and Coinbase have been told, in effect, that refusing AI is the same as refusing a future at the company. The predictable result, as Xavier documents, is quiet sabotage: skipped training sessions, deliberately poor inputs to game dashboards, and a slow return to older methods. He argues that this failure is rooted in the destruction of psychological safety, the condition under which people feel genuinely free to take risks, ask questions, and speak up without fear of punishment.

This analysis is sound. When a mandate arrives as a threat, the natural human response is not enthusiasm but self-protection. Workers comply on the surface and resist underneath. Xavier is correct to say that treating a cultural challenge as though it were a process re-engineering problem is a category error at the leadership level.

The difficulty is that the article stops there. It treats forced AI adoption as a problem between the company and its employees. The harm that flows downstream, past the employee, to the people who will use the software that these employees produce, does not appear in the frame at all. That harm has a name. It is called technoableism, and in a country governed by the Rights of Persons with Disabilities Act 2016, and bound by the United Nations Convention on the Rights of Persons with Disabilities, it is not merely an ethical concern. It is a legal one.

What Technoableism Is

The concept was developed by Ashley Shew, a scholar at Virginia Tech, in her 2023 book Against Technoableism: Rethinking Who Needs Improvement. Shew argues that the technology sector operates almost entirely within the medical model of disability, which treats disabled bodies and minds as defects requiring correction. The non-disabled body is taken as the norm. Disabled people appear in this framework, if they appear at all, as special cases at the margins of design, not as primary stakeholders with rights.

This assumption finds its way into artificial intelligence systems in a simple and well-documented manner. AI coding tools learn from the code that already exists on the internet. That code was written, in the overwhelming majority of cases, without any attention to disability. It was written for users who see screens clearly, who navigate with a mouse, who can process information quickly, and who have no sensory or cognitive differences. When an AI coding assistant is trained on this material, it absorbs these assumptions. Its suggestions then carry them forward into new software, and the exclusion that was already present in old code is reproduced, at greater speed, in the new.

What the Research Demonstrates

This is not a theoretical risk. Researchers Prakriti Mowar and colleagues, whose work was published at the CHI Conference on Human Factors in Computing Systems in 2024, studied how developers actually behave when they use AI coding assistants to build web interfaces. Three problems appeared consistently. Developers routinely forgot to request accessible features from the tool. When the tool offered suggestions, developers accepted them even when the output was incomplete, for instance accepting a placeholder text attribute for an image without ever replacing it with a meaningful description. And developers found it genuinely difficult to verify, on their own, whether the code the tool had produced met any recognised accessibility standard.

Separate research examining code generated by tools such as ChatGPT and GitHub Copilot found that the output regularly broke basic rules. Headings appeared in the wrong order. Interactive elements lacked proper labels. Keyboard navigation failed entirely in several cases. One developer who tried supplying explicit Web Content Accessibility Guidelines to Copilot as part of the prompt still reported that the tool continued suggesting invalid heading structures. These are not cosmetic problems. A heading structure that is out of order is not an inconvenience for a sighted user navigating with a mouse. For a blind user relying on a screen reader, it can make a page entirely unusable.

Why the Mandate Compounds the Problem

On its own, an imperfect tool can be managed. A developer who has time and authority can review AI suggestions, reject the problematic ones, and add accessibility features before the code goes into production. This is not an efficient workflow, but it is a workable one. The corporate mandate removes the conditions under which that review is possible.

When managers measure performance by the number of lines of code pushed to a repository, or by token consumption, the incentive is to accept suggestions quickly and move on. Adding accessibility to AI-generated code is methodical work. It frequently requires rewriting significant sections of what the tool has produced, because accessible code depends on the logical structure of the document object model, not merely on how the interface looks on screen. In a mandate-driven environment where speed is the metric of value, that rewriting is the first task to be abandoned.

Xavier observes that some employees resist mandates by gaming metrics or reverting to old methods. There is, though, a second response that is less visible and considerably more damaging: compliance that is empty. The developer uses the tool, meets the daily target, ships the code, and nobody notices that the resulting product excludes a substantial number of its intended users. The resistance Xavier describes is at least honest about itself. The quiet compliance that produces inaccessible software at scale is harder to see and far more difficult to remedy once it is embedded in production systems.

The Cognitive Dimension

There is a further layer to this problem. Anthropic's own research from 2026 examined what happens to developer understanding when AI assistance becomes the primary mode of working. Developers who relied on AI assistance scored approximately 17 percentage points lower on tests of their comprehension of code they had produced just minutes earlier, compared with developers who had coded manually. That is not a marginal difference. It represents a genuine and measurable decline in domain knowledge.

This matters for accessibility because inclusive design requires a kind of technical empathy that depends on structural understanding. A developer who builds an interface from scratch must think through how a screen reader will interpret the document object model, how a keyboard user will move through a form without a mouse, and whether every interactive element announces its purpose clearly. When the developer instead accepts and lightly edits AI-generated code without deeply examining what has been produced, this thinking does not happen in the same way. The structural decisions have already been made by the algorithm, and the developer may not fully understand them. Accessibility, which depends on precisely that structural understanding, suffers accordingly.

The Bias Pipeline

Nilesh Singit, has written extensively on artificial intelligence and disability, describes what he calls a bias pipeline [click here to visit website]. The pipeline begins in the training data, which reflects a digital world built for non-disabled users, and runs through to the final product. At each stage, the assumption that the legitimate user is able-bodied and neurotypical is reinforced. Singit draws a careful and important distinction between accessibility and algorithmic bias. Accessibility asks whether a disabled person can use a system. Algorithmic bias asks whether the system was designed with that person in mind at all.

A system can be technically accessible, in the sense that a screen reader can navigate it, while remaining biased in its deeper assumptions: about who constitutes a normal job applicant, what a valid educational trajectory looks like, or what counts as a competent written response. An artificial intelligence recruitment tool might produce a portal that passes a Web Content Accessibility Guidelines check and yet penalise applicants for employment gaps resulting from medical treatment, or rate lower the communication style of a person with a cognitive difference. The portal is accessible. The pipeline is still biased. Singit's argument is that both problems must be addressed, and the current trajectory of AI coding mandates ensures that neither is.

The Legal Obligation in India

Xavier's article does not address the Indian legal framework, but it is directly relevant to the conversation he has started. The Rights of Persons with Disabilities Act 2016 places a positive obligation on establishments, including private entities, to ensure that their goods and services are accessible. The Supreme Court of India's judgment in Rajive Raturi v. Union of India affirmed that accessibility is not a dispensation but a right. India has also ratified the UNCRPD, whose Article 9 requires states, and by extension the organisations that operate within their jurisdiction, to take concrete steps to ensure that persons with disabilities can access information and communications technology on an equal basis with others.

When a company deploys software built by developers who were coerced into using AI tools that generate inaccessible code, it is not merely making a management error. It is producing a product that may violate these obligations. The corporate language around AI mandates speaks entirely in terms of productivity, tokens, and efficiency. That language has no room for the user who cannot read a screen or navigate with a mouse. The law, however, does make room for that user. Organisations that ignore this do so at considerable legal risk, and with considerable harm to the population of more than 26 million persons with disabilities recorded in India, a number that independent assessments suggest is substantially higher in reality.

The Vibe Coding Problem

Alongside AI mandates, there has grown a practice that some in the industry call vibe coding. The term describes an approach in which the developer types a general description of what is wanted, the AI produces a complete block of code, and the developer accepts it with minimal scrutiny. It is coding by approximation and acceptance rather than by deliberate craft. It is, in a certain sense, the logical product of the productivity mandate taken to its conclusion: if the measure of performance is volume of code delivered per day, vibe coding maximises the metric.

The consequences for accessibility are predictable and well-supported by evidence. When an entire application is assembled from AI-generated blocks that the developer has not examined in detail, the structural qualities on which accessibility depends are entirely at the mercy of the training data. And as the research by Mowar and colleagues shows, that training data does not reliably produce accessible output. What is more, when a developer who has not fully understood the generated structure attempts to retrofit accessibility, the modifications can cause failures elsewhere in the code. This creates a practical disincentive: the cost of making the code accessible is too high, the risk of breaking something else is too great, and the deadline is too close. The accessibility work does not happen.

What Ought to Be Done

The argument being made here is not that artificial intelligence shall have no role in software development. It shall, and there is no reason why it ought not. The argument is that the conditions under which AI tools are deployed determine whether they serve everyone or merely the majority.

Companies that choose to integrate AI coding assistants shall need to hold those tools to accessibility standards before adoption, not after. AI coding assistants ought to be evaluated on whether their output meets the Web Content Accessibility Guidelines by default, not merely on whether the output functions visually. Developers shall need to retain the time and professional authority to review suggestions critically, to reject inaccessible code, and to perform manual accessibility audits before deployment. This is incompatible with mandate regimes that measure performance purely by speed and volume.

Most importantly, disabled experts ought to be involved in the design and evaluation of AI systems from the outset. As Shew has argued, disabled individuals possess deep and practical expertise in navigating hostile architectures. That expertise is precisely what is required when building systems that are supposed to serve the full range of human users. Singit's proposed Inclusivity Stack and Disability-Smart Prompts, which embed accessibility requirements into the prompting framework of AI tools, point towards what genuine reform might look like. Until these standards are adopted and enforced, compelling developers to use AI tools is not a step towards inclusion. It is a step towards the automation of exclusion.

Conclusion

Xavier is right that forcing employees to use AI produces outcomes that no serious organisation ought to want: resistance, resentment, and metrics that measure activity rather than value. But the full cost of these mandates is not felt in the boardroom. It is felt by the person who arrives at a government portal and cannot submit a form because the keyboard navigation was never tested, by the job applicant whose screen reader cannot parse the heading structure of the recruitment interface, by the student who cannot access digital learning materials because the AI that generated them never considered that a user might need them in a different format.

These are not edge cases. They are citizens. They are rights-holders. And the legal frameworks that India has enacted and ratified exist precisely to ensure that the speed of the market does not override their claim to equal participation.

Zabardasti with artificial intelligence tools does more than demoralise employees, as Xavier correctly observes. It embeds technoableism into the infrastructure of the digital present. True efficiency is not measured in tokens consumed or lines of code shipped. It is measured in whether the systems that are built actually work for the people who need to use them.

References

• Primary Source (Article Being Rebutted)
  Xavier, John. "Why Forcing Employees to Use AI is Producing the Opposite of What Companies Want." The Hindu, 28 March 2026. (Author profile at: https://muckrack.com/john-xavier)
  Why forcing employees to use AI is producing the opposite of what companies want

• Shew, Ashley. Against Technoableism: Rethinking Who Needs Improvement. W. W. Norton & Company, 2023. ISBN: 9781324036661.Publisher page: https://wwnorton.com/books/9781324036661
  Virginia Tech faculty page: https://liberalarts.vt.edu/news/bookshelf/science-technology-and-society-bookshelf/2023/liberalarts-against-technoableism.html
  

• Mowar, Peya, Yi-Hao Peng, Aaron Steinfeld, and Jeffrey P. Bigham. "Tab to Autocomplete: The Effects of AI Coding Assistants on Web Accessibility." ASSETS '24: Proceedings of the 26th International ACM SIGACCESS Conference on Computers and Accessibility, October 2024.
  DOI and full paper: https://dl.acm.org/doi/10.1145/3663548.3688513
  Author's PDF: https://peyajm29.github.io/assets/documents/assets24e-sub1034-cam-i26.pdf
  Mowar, Peya, Yi-Hao Peng, Jason Wu, Aaron Steinfeld, and Jeffrey P. Bigham. "CodeA11y: Making AI Coding Assistants Useful for Accessible Web Development." Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems.
  Full paper (arXiv): https://arxiv.org/abs/2502.10884
  ACM Digital Library: https://dl.acm.org/doi/10.1145/3706598.3713335
  

• Shen, Judy Hanwen, and Alex Tamkin. "How AI Impacts Skill Formation." Anthropic Research, January 2026.
  Official Anthropic page: https://www.anthropic.com/research/AI-assistance-coding-skills
  Full paper (arXiv): https://arxiv.org/html/2601.20245v1
  Reported coverage (InfoQ): https://www.infoq.com/news/2026/02/ai-coding-skill-formation/
  

• World Wide Web Consortium (W3C). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 5 October 2023.  Official standard: https://www.w3.org/TR/WCAG22/
  

• The Rights of Persons with Disabilities Act, 2016 (No. 49 of 2016). Parliament of India
  India Code (full text): https://www.indiacode.nic.in/handle/123456789/2155
  

• Rajive Raturi v. Union of India & Ors., Writ Petition (C) No. 243 of 2005. Supreme Court of India. Judgment dated 8 November 2024 (2024 INSC 858).
  Indian Kanoon (full judgment): https://indiankanoon.org/doc/98908321/
  

• Disability Rights India commentary: https://www.disabilityrightsindia.com/2024/11/supreme-court-holds-recommendatory.html
  Oxford Human Rights Hub commentary (on the 2017 judgment): https://ohrh.law.ox.ac.uk/through-two-progressive-rulings-indian-supreme-court-bolsters-rights-of-the-disabled/
  

• United Nations. Convention on the Rights of Persons with Disabilities, Article 9 (Accessibility). Adopted 13 December 2006, entered into force 3 May 2008. India ratified on 1 October 2007.
  Full text: https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities/convention-on-the-rights-of-persons-with-disabilities-2.html

AI for All or Exclusion by Default? Open Letter to PM Narendra Modi on Disability Bias in Artificial Intelligence, Accessibility Challenges, and Lessons from India AI Impact Summit 2026 – Addressing TechnoAbleism in India's AI Policy and Governance

Date: 26/02/2026

To,

Shri Narendra Modi Ji
Hon’ble Prime Minister of India
South Block, New Delhi

Subject: On Artificial Intelligence, Disability Bias, and the Meaning of “AI for All”

Hon’ble Prime Minister,

Namaskar.

I write to you not as a technologist, nor as a lawyer by formal training. I write as a citizen who lives with disability, and as someone who has had to understand both law and technology simply in order to participate in ordinary life. Much of what I know about systems has not been learnt in classrooms. It has been learnt at doorways without ramps, on websites without structure, and in digital forms that could not be completed without assistance.

Exclusion rarely announces itself. It is usually designed quietly.

At the India AI Impact Summit 2026, when your address was translated in real time through an AI-powered sign language avatar, I watched carefully. It was an impressive demonstration, certainly. But it was also something more subtle. For a brief moment, Access was visible. It was not an afterthought. It stood alongside innovation, not behind it. That visibility matters. It signals direction.

I would also like to draw to the attention of Shri Narendra Modi that Moneylife published an article entitled “TechnoAbleism in India’s AI Moment: Why Accessibility Is Not Enough” [click here to read article] on 17 February 2026, coinciding with the India AI Impact Summit’s session on disability. The piece shows that this issue is already the subject of public discussion and media scrutiny, which underlines the urgency of treating accessibility and disability bias as central elements of India’s AI programme.

Yet direction must be followed by design.

We speak today of “AI for All.” It is a powerful phrase. But if it is to carry meaning, it must confront a difficult truth: artificial intelligence systems, as they are presently trained and deployed across the world, tend to absorb and reproduce the biases already present in society. Disability is not excluded intentionally. It is excluded structurally.

Artificial intelligence learns from data. That data is drawn from the world as it has been recorded. The recorded world, especially the digital one, reflects certain assumptions about how a person moves, speaks, types, sees, processes information, and builds a career. The so-called average user becomes the reference point. Systems are optimised around that reference point. Others are accommodated only when someone remembers to ask.

In such systems, disability becomes an exception.

This becomes visible in small but telling ways. When generative AI tools are asked to create websites or applications, they often produce code that assumes mouse navigation, adequate vision, and conventional interaction patterns. Keyboard accessibility may not be complete. Structural markup for screen readers may be missing. Alternative text may not be generated unless explicitly requested. Colour contrast frequently fails established accessibility norms.

Unless instructed, accessibility does not appear by default.

That word, default, is where the real issue lies.

Under the Rights of Persons with Disabilities Act, 2016, and under India’s obligations pursuant to the United Nations Convention on the Rights of Persons with Disabilities, accessibility is not optional. It is not decorative. It is a matter of Equality and Dignity. The Hon’ble Supreme Court has affirmed that accessibility is foundational to the exercise of fundamental rights. Without access, rights remain theoretical.

When artificial intelligence begins to generate systems at scale, inaccessible design also begins to scale. What was once a single inaccessible website becomes hundreds. What was once a human oversight becomes an automated pattern. Exclusion is no longer episodic. It is multiplied.

A citizen need not be denied formally. She may simply be unable to use what has been built.

India has articulated an ambitious artificial intelligence architecture, extending from infrastructure and compute to foundational models and applications. The vision is large. The confidence is visible. But I worry about timing. If disability is considered only at the application stage, after the underlying models have already been trained on datasets that insufficiently represent disability experience, then correction later will be partial and costly.

Bias does not remain soft once embedded. It settles into systems.

We have seen, in other technological domains, a familiar cycle. Innovation is celebrated. Adoption expands rapidly. Harm becomes visible only after scale has been achieved. Regulation then attempts to repair what might have been prevented. Artificial intelligence operates at a velocity and magnitude that make delayed correction far more difficult.

The Book of Proverbs says, “Where there is no vision, the people perish.” I do not read that verse as theological warning. I read it as policy advice. Vision must mean foresight; asking who is not being seen.

Around the world, governments have begun to grapple with these questions. The European Union has enacted an Artificial Intelligence Act that links AI governance explicitly to fundamental rights and non-discrimination. High-risk systems are subject to structured assessment and documentation. Bias audits and impact assessments are becoming part of regulatory vocabulary in several jurisdictions. The conversation is no longer limited to efficiency. It includes fairness.

India, as a State Party to the UN Convention on the Rights of Persons with Disabilities, is already bound by obligations to ensure equal access to information and communication technologies. These commitments do not diminish because technology evolves. If anything, their relevance increases.

This is not an argument for importing foreign law. It is an argument for aligning our technological progress with our own constitutional morality.

There is another dimension that requires attention, and it cannot be resolved by rhetoric alone. We need structured, publicly supported research on disability bias in artificial intelligence systems. Not assumption. Not symbolic inclusion. Research.

Datasets must be examined for representational gaps. Model outputs must be tested systematically across disability-related contexts. Evaluation metrics must measure performance across diverse sensory and cognitive realities. Without such empirical work, we shall continue to debate in abstraction.

Artificial intelligence is not only engineering. It touches law, sociology, governance, ethics, and lived experience. Universities such as NALSAR and other institutions working at the intersection of law and public policy ought to collaborate with technical institutes developing AI systems. Organisations grounded in disability rights must be involved as knowledge partners, not merely consulted at the end.

Public funding is being directed towards compute capacity, innovation ecosystems, and model development. A focused allocation for research on AI and disability bias would not be disproportionate. 

Yet its impact would be long-term and structural.

The Government of India ought undertake such a structured research initiative on artificial intelligence and disability bias, I would respectfully seek to be involved in that effort. For several years, I have been examining this question in depth and have maintained a dedicated platform, thebiaspipeline.nileshingit.org [click here to visit site], where I have written extensively on disability bias in digital systems and AI. While many organisations in India are rightly focused on accessibility compliance, very few are examining algorithmic bias itself as a systemic concern. I believe my sustained work in this area positions me to contribute meaningfully to any national research initiative. Significant public resources are presently being invested in artificial intelligence. If disability bias is not studied with equal seriousness, an important dimension of inclusion risks being overlooked. The promise of “Sabka Saath, Sabka Vikas” cannot be realised if persons with disabilities are not structurally included in the design and evaluation of emerging technologies.

Over the past year, I wrote to the Ministry of Electronics and Information Technology and to NITI Aayog when national AI policy discussions were underway. My intention was simple: to place before them the structural concerns surrounding disability bias in AI systems. I have not received substantive responses. I mention this not as complaint, but as indication that this dimension has not yet been treated with the seriousness it deserves.

The phrase “human in the loop” is often used in AI governance. It is a reassuring phrase. Machines, we are told, shall not decide alone. But one must ask quietly: whose humanity is present in that loop?

As Shakespeare wrote, “What is the city but the people?” If oversight committees and review boards do not include disability expertise, certain harms will remain invisible. Representation in governance is not ceremonial. It is epistemic.

India stands at a formative moment. Our AI ecosystem is still being shaped. The choices being made now will determine whether exclusion is prevented or automated. If accessibility standards are embedded by default in publicly funded AI systems; if Disability Impact Assessments become routine for high-stakes deployments; if datasets are audited honestly; if disability expertise is included in national AI councils and technical bodies; then India may demonstrate that technological leadership and social Justice are not adversaries.

They may strengthen one another.

If accessibility remains secondary, we shall eventually attempt repair. Repair is always more expensive than foresight.

Hon’ble Prime Minister, artificial intelligence may indeed represent a civilisational opportunity. It is also a moral test. Let Access be built into foundations, not attached later. Let Inclusion be structural, not symbolic. Let Equality be measurable in code, not only declared in speech.

I place these reflections before you with respect and with hope.

Jai Hind. 

Yours sincerely,

Nilesh Singit

TechnoAbleism in India’s AI Moment: Why Accessibility Is Not Enough

When artificial intelligence is built on narrow assumptions of the “normal” user, accessibility features alone cannot prevent exclusion embedded within the algorithm itself.

India’s present moment in artificial intelligence is often described in terms of innovation, opportunity, and national technological leadership. The India AI Impact Summit brings global attention to how artificial intelligence is shaping governance, development, and social transformation. 

Within these discussions, disability is increasingly visible through conversations on accessibility, assistive technologies, and digital inclusion. This attention is important. For many years, disability was largely absent from technology policy debates. Yet, a deeper issue remains insufficiently examined: accessibility alone does not ensure inclusion when artificial intelligence systems themselves are shaped by structural bias.

Accessibility and bias are frequently treated as interchangeable ideas. They are not the same. Accessibility determines whether a person with disability can use a system. Bias determines whether the system was designed with that person in mind at all. When systems are built around assumptions about a so-called normal user, accessible interfaces merely allow disabled persons to enter environments that continue to exclude them through their internal logic. The interface may be open; the opportunity may still be closed.

This structural problem becomes visible in the rapidly expanding practice often called ‘vibe coding’, where developers use generative AI tools to create websites and software through simple prompts. When an AI coding assistant is asked to generate a webpage, the default output usually prioritises visual layouts, mouse-dependent navigation, and animation-heavy design. Accessibility features such as semantic structure, keyboard navigation, or screen-reader compatibility rarely appear unless they are explicitly demanded. The system has learned that the ‘default’ user is non-disabled because that assumption dominates the data from which it learned. As these outputs are reproduced across applications and services, exclusion becomes quietly automated.

Bias also appears in the decision-making systems that increasingly shape employment, education, financial access and public services. Hiring systems that analyse speech, expression, or behavioural patterns may interpret disability-related communication styles as indicators of low confidence or low performance. Speech recognition tools often struggle with atypical speech patterns. Vision systems may fail to recognise assistive devices correctly. These outcomes are not isolated technical errors. They arise because disability is often missing from training datasets, testing environments and design teams. When disability is absent from the design stage, the system internalises non-disabled behaviour as the baseline expectation.

Another less visible dimension of bias emerges from the way artificial intelligence systems classify behaviour. Many systems are trained to recognise patterns associated with what developers consider efficient, confident or normal interaction. When human diversity falls outside those patterns, the system may interpret difference as error. Research in AI ethics repeatedly shows that classification models tend to perform poorly when training datasets do not adequately represent disabled users, leading to systematic misinterpretation of speech, movement or communication styles. 

These classification failures are rarely dramatic; they appear as small inaccuracies that accumulate over time. A speech interface that repeatedly fails to understand a user, an automated assessment tool that consistently undervalues atypical communication, or a recognition system that misidentifies assistive devices can gradually shape unequal access to opportunities. As these outcomes arise from technical assumptions rather than explicit discrimination, they often remain invisible in public debates, even as their effects are widely experienced.

These patterns together reflect what disability scholars describe as techno-ableism - the tendency of technological systems to appear empowering while quietly reinforcing assumptions that favour non-disabled ways of functioning. Technologies may expand participation on the surface, yet the intelligence embedded within them continues to treat disability as deviation rather than diversity. A person with disability may be able to access the interface, log into the system or navigate the platform, yet still face exclusion through hiring algorithms, recognition systems, or automated decision tools that were never designed around diverse bodies and minds. The experience is not exclusion from technology, but exclusion within technology itself.

Public discussions frequently present disability mainly through assistive innovation: tools that help blind users read text, applications that assist persons with mobility impairments or systems designed for specific accessibility functions. These innovations are valuable and necessary. However, when disability appears only in assistive contexts, it is positioned as a specialised technological niche rather than a structural dimension of all artificial intelligence systems. The mainstream design pipeline continues to assume the non-disabled user as the default, while disability inclusion becomes an add-on layer introduced later.

India currently stands at a formative stage in shaping its artificial intelligence ecosystem. As public digital infrastructure, governance platforms and automated service systems expand, the assumptions embedded in present design choices will influence social participation for decades. If accessibility becomes the only measure of inclusion, structural bias risks becoming embedded within the foundations of emerging technological systems. Inclusion then becomes symbolic rather than substantive: systems appear inclusive because they are accessible, yet continue to produce unequal outcomes.

From the standpoint of persons with disabilities, this distinction is deeply personal. Accessibility determines whether we can interact with the system. Bias determines whether the system recognises us as equal participants once we enter. Accessible platforms built upon biased intelligence do not remove barriers; they simply move the barrier from the interface to the algorithm.

As a disability rights practitioner working at the intersection of law, accessibility, and technology, I view the present expansion of AI discussions with cautious attention. Disability is finally visible in national technology conversations, yet the focus remains concentrated on accessibility demonstrations rather than the deeper question of structural bias. Artificial intelligence will increasingly shape employment, governance, education and everyday social participation. Whether these systems expand equality or quietly reproduce exclusion will depend not only on whether they are accessible, but also on whose experiences shape the data, assumptions, and decision rules within them.

Accessibility opens the door; fairness determines what happens after entry. Without confronting bias directly, technological progress risks creating a future that is digitally reachable yet socially unequal for many persons with disabilities. Many of the issues discussed here, including the structural relationship between accessibility and algorithmic bias, are explored in greater detail at The Bias Pipeline (https://thebiaspipeline.nileshsingit.org), where readers may engage with further analysis.

References

• India AI Impact Summit official information portal, Government of India.
• Coverage of summit accessibility and inclusion themes, Business Standard and related reporting.
• United Nations and global policy discussions on AI and disability inclusion.
• Nilesh Singit, The Bias Pipeline https://thebiaspipeline.nileshsingit.org/

(Nilesh Singit is a disability rights practitioner and accessibility strategist working at the intersection of law, governance, and AI inclusion. A Distinguished Research Fellow at the Centre for Disability Studies, NALSAR University of Law, he writes on accessibility, techno-ableism, and algorithmic bias at www.nileshsingit.org)

Moneylife.in
Published 17th Fevruary 202

MoneyLife.in

The Inclusivity Stack: Operationalising Disability Justice in India’s Sovereign AI Architecture

The Inclusivity Stack

Abstract

The Government of India’s strategic pivot towards "Sovereign Artificial Intelligence," crystallised in the ₹10,371 crore IndiaAI Mission, represents a watershed moment in the nation’s digital governance trajectory. As the state moves to integrate Artificial Intelligence (AI) into the foundational layer of Digital Public Infrastructure (DPI)—spanning healthcare, agriculture, and urban governance—it faces a critical architectural choice: to replicate the exclusionary patterns of the "medical model" of disability or to operationalise a "social model" that views accessibility as a non-negotiable constitutional guarantee. This report proposes the "Inclusivity Stack," a comprehensive governance and technical framework designed to embed disability justice into the IndiaAI ecosystem. Drawing extensively on the Supreme Court’s landmark judgment in Rajive Raturi v. Union of India (2024), the Rights of Persons with Disabilities (RPWD) Act, 2016, and global best practices such as the EU AI Act and Canada’s CAN-ASC-6.2 standard, this document outlines a roadmap for "fixing" the digital environment rather than the individual. It argues that the inclusion of India’s 26.8 million persons with disabilities is not merely a moral imperative but a prerequisite for the mathematical robustness, legal validity, and economic viability of India’s sovereign AI ambitions.

1. Introduction: The Sovereign AI Moment and the Risk of Digital Apartheid

1.1 The Genesis of the IndiaAI Mission

In March 2024, the Union Cabinet approved the IndiaAI Mission with a substantial budgetary outlay of ₹10,371.92 crore, signaling India’s intent to move from being a consumer of Western AI models to a creator of indigenous, sovereign AI capabilities.1 This mission is structurally organised around seven distinct pillars, designed to democratise access to computing power and data:

1. IndiaAI Compute Pillar: The deployment of over 38,000 Graphics Processing Units (GPUs) to provide affordable computational infrastructure to startups and researchers.2
2. IndiaAI Application Development Initiative: Targeting critical sectors such as healthcare, agriculture, and governance.2
3. AIKosh (Dataset Platform): A unified repository for high-quality, non-personal datasets to train indigenous models.3
4. IndiaAI Foundation Models (BharatGen): The development of "BharatGen," a sovereign Large Multimodal Model (LMM) trained on diverse Indic languages and datasets.4
5. IndiaAI FutureSkills: Aimed at expanding the AI talent pool through academic and vocational training.2
6. IndiaAI Startup Financing: Venture capital support for deep-tech AI startups.6
7. Safe & Trusted AI: A framework for responsible AI governance, including the establishment of the IndiaAI Safety Institute (AISI).7

While the mission’s scale is ambitious, aiming to catalyse a $1.7 trillion contribution to the Indian economy by 2035 2, its current architectural blueprint lacks explicit mechanisms to address the "digital apartheid" faced by Persons with Disabilities (PwDs). In a nation where internet access is already stratified by caste, class, and geography, the uncritical deployment of AI threatens to deepen these divides.

1.2 The "Data Void" and Algorithmic Exclusion

The exclusion of PwDs from the digital ecosystem is not accidental but systemic, often described as a "data void." Contemporary AI systems are predominantly trained on data that reflects the "normative" able-bodied user.

• Speech Recognition: Models trained on standard datasets often fail to recognise dysarthric speech (common in conditions like cerebral palsy) or the vocal patterns of the deaf community.8
• Computer Vision: Facial recognition systems, such as those used in the DigiYatra biometric boarding initiative, are frequently trained on datasets that lack representation of individuals with facial differences, Down syndrome, or palsy, leading to higher failure rates for these groups.9
• Natural Language Processing (NLP): Large Language Models (LLMs) often hallucinate "cures" or offer patronizing advice when users disclose a disability, reflecting the biases inherent in their training corpora.11

If the IndiaAI Mission proceeds without rectifying these voids, the "Sovereign AI" infrastructure will effectively become a "Sovereign Exclusion Mechanism," automating the denial of services to the most vulnerable citizens.

1.3 The Economic and Constitutional Imperative

The argument for inclusion is not solely humanitarian; it is economic and constitutional.

• Economic Cost: Excluding PwDs from the digital economy limits the potential GDP growth that the IndiaAI Mission seeks to unlock. Accessible technology enables workforce participation for millions who are currently marginalized.13
• Constitutional Mandate: The Supreme Court of India, in Rajive Raturi v. Union of India (2024), explicitly held that accessibility is a facet of the Fundamental Right to Life (Article 21) and Equality (Article 14).14 The Court mandated that the "State has an obligation to ensure that all steps... are taken" to ensure accessibility in "information, technology and entertainment".16

This report articulates the "Inclusivity Stack"—a layered framework to operationalise these legal and ethical mandates within the technical architecture of the IndiaAI Mission.

2. Theoretical Framework: De-Medicalising Artificial Intelligence

To build an inclusive AI architecture, policy-makers must first interrogate and dismantle the theoretical models of disability that currently inform—often subconsciously—the development of AI systems.

2.1 The Medical Model vs. The Social Model in Code

The development of AI has historically been rooted in the Medical Model of Disability. This model views disability as a "deficit," "pathology," or "aberration" residing within the individual that requires diagnosis, treatment, or cure.17

• In AI Development: This manifests in data annotation practices where non-normative behaviors (e.g., lack of eye contact in autism, stuttering in speech) are labeled as "errors," "noise," or "negative samples" to be filtered out.11
• The Consequence: An AI system trained on this model views a disabled user as a "broken" user. A proctoring algorithm flags a neurodivergent student’s movements as "suspicious" 20; a hiring algorithm ranks a candidate with a disability lower because their resume signals a "deviation" from the norm.12

In contrast, the Social Model of Disability, which underpins the UN Convention on the Rights of Persons with Disabilities (UNCRPD), posits that disability is constructed by societal barriers—physical, attitudinal, and digital—that prevent full participation.21

• In AI Development: Operationalising the Social Model requires shifting the focus from "fixing the user" to "fixing the system." It demands that AI interfaces be designed to accommodate diverse modes of interaction (e.g., supporting screen readers, switch devices, or sign language) as native features, not afterthoughts.19

2.2 Confronting "Technoableism"

The philosopher of technology Ashley Shew defines "Technoableism" as the pervasive belief that technology is the "solution" to disability, often characterizing disabled people as "problems" awaiting a technological "fix".23

• The Trap of "Inspiration Porn": Technoableism often manifests in high-profile projects—such as AI-powered exoskeletons or brain-computer interfaces—that garner media attention ("Inspiration Porn") while basic digital infrastructure remains inaccessible.24
• Policy Implication: For the IndiaAI Mission, avoiding technoableism means prioritizing boring but essential infrastructure (e.g., ensuring the CAPTCHA on the PM-Kisan portal is accessible to the blind) over flashy, high-tech "cures" that benefit a few. It means recognizing that disabled people are experts in their own lives and must lead the design process ("Nothing Without Us").23

3. The Legal Layer: From Guidelines to Non-Negotiable Standards

The foundation of the Inclusivity Stack is a robust legal framework that elevates accessibility from a voluntary "best practice" to a mandatory compliance requirement. The legal landscape in India has shifted dramatically in this regard following recent judicial interventions.

3.1 The Rajive Raturi Paradigm Shift (2024)

On November 8, 2024, the Supreme Court of India delivered a landmark judgment in Rajive Raturi v. Union of India.14 The case, originating from a PIL filed in 2005 by visually impaired activist Rajive Raturi, addressed the systemic failure of the state to implement accessibility mandates.

Key Judicial Findings:

1. Mandatory Rules: The Court accepted the argument presented by the NALSAR Centre for Disability Studies (CDS) that Rule 15 of the RPWD Rules, 2017, which prescribed accessibility standards, had historically been treated as directory (voluntary). The Court ruled that Rule 15, read with Sections 40, 44, and 45 of the RPWD Act, creates a mandatory compliance framework.15
2. Ultra Vires: The NALSAR report Finding Sizes for All argued that any interpretation of the rules that allows for "self-regulation" or "guidelines" is ultra vires (beyond the powers of) the parent Act, which mandates full accessibility.26
3. Digital Inclusion: While the case focused on physical access, the judgment explicitly stated that "accessibility to information, technology and entertainment is equally important".16 This extends the mandate to all digital platforms, AI interfaces, and electronic services provided by the state.

Implication for IndiaAI: Any AI system deployed by the government (e.g., BharatGen, DigiYatra) that fails to meet accessibility standards is now illegal and actionable under the RPWD Act.27

3.2 IS 17802: The Constitutional Standard for Code

The technical benchmark for this legal mandate is IS 17802: Accessibility for ICT Products and Services, notified by the Bureau of Indian Standards (BIS) in 2021/2022.28

• Part 1 (Requirements): Aligned with the global standard EN 301 549 and WCAG 2.1, this section specifies functional performance statements (e.g., "usage without vision," "usage with limited manipulation").29
• Part 2 (Conformance): Defines the testing methodologies to verify compliance.29
• Enforceability: Following the RPWD Amendment Rules 2023, IS 17802 is the statutory standard.30 This means that procurement of AI systems via the Government e-Marketplace (GeM) must strictly adhere to these standards.

3.3 Comparative Jurisprudence: The EU and Canada

India’s legal framework can be further strengthened by examining global best practices:

• Canada (CAN-ASC-6.2:2025): Canada has released the world’s first standard specifically for "Accessible and Equitable Artificial Intelligence Systems".31 It mandates that persons with disabilities be involved in the entire AI lifecycle—from data collection to model training—and introduces the concept of "Equitable AI" to prevent algorithmic discrimination.25
• European Union (EU AI Act): The EU AI Act (Article 5 & Recital 80) categorises AI systems that exploit vulnerabilities of persons with disabilities as "Unacceptable Risk" (prohibited). High-risk systems (e.g., education, employment) must demonstrate compliance with accessibility requirements by design.33

Recommendation: The IndiaAI Mission should adopt a framework analogous to CAN-ASC-6.2, mandating "lifecycle inclusion" for all projects funded under the Safe & Trusted AI pillar.

4. The Data Layer: Constructing the Disability Data Commons

Artificial Intelligence is, at its core, an engine of pattern recognition. If the "pattern" of disability is absent from the training data, the AI will inevitably treat disability as an anomaly. The AIKosh pillar of the IndiaAI Mission 2 must address this "data void" to ensure sovereign AI is truly inclusive.

4.1 The Representation Gap in Indic Datasets

Current datasets for Indian languages (e.g., those used to train BharatGen) suffer from a dual exclusion:

1. General Data Poverty: While initiatives like Bhashini are addressing the lack of Indic language data, there is a severe scarcity of data representing disabled speakers of these languages.8
2. Specific Modality Gaps:

• Dysarthric Speech: There are few, if any, large-scale datasets of dysarthric or atypical speech in languages like Hindi, Tamil, or Bengali. This renders voice-activated UPI payments or government helplines inaccessible to millions with motor or speech impairments.35
• Indian Sign Language (ISL): Despite being a scheduled language capability under the New Education Policy, ISL lacks a comprehensive, annotated video-to-text corpus required to build robust translation models.36

4.2 The "Outlier Advantage": Robustness via Inclusion

A compelling technical argument for inclusion is the concept of the "Outlier Advantage." Machine Learning (ML) research indicates that training models on "edge cases" or diverse outliers improves the mathematical robustness and generalisation capabilities of the model for all users.37

• Curriculum Learning: By including "difficult" samples—such as stuttered speech or heavily accented voice commands—during training, the model learns to identify the phonetic core of language rather than over-fitting to superficial acoustic features.39
• Universal Benefit: A speech model trained on dysarthric speech performs significantly better in noisy environments (e.g., a railway station) for non-disabled users. Thus, investing in disability data is an investment in the overall quality of India’s sovereign AI.40

4.3 Governance: Data Empowerment and Protection Architecture (DEPA)

To collect this sensitive data without exploitation, India must leverage its Data Empowerment and Protection Architecture (DEPA).41

• Disability Data Trusts: We propose the creation of "Disability Data Commons"—fiduciary structures where the disability community pools their data (e.g., voice samples, gait patterns).
• Consent Managers: Using DEPA’s electronic consent artifact, PwDs can grant temporary, purpose-limited access to their data for training "public good" models (like BharatGen) while retaining ownership.43 This shifts the dynamic from "data extraction" to "data empowerment."

5. The Model Layer: Indigenous Intelligence and Red Teaming

The IndiaAI Compute Pillar and BharatGen initiative provide the computational muscle to build indigenous foundational models.4 This sovereign control offers a unique opportunity to "bake in" inclusion at the model layer, rather than retrofitting it later.

5.1 BharatGen and the Constitutional AI Paradigm

BharatGen, India’s proposed sovereign Large Multimodal Model, is currently being trained on datasets spanning 22 Indian languages.5 To avoid the pitfalls of Western models, BharatGen must adopt a Constitutional AI approach.

• Constitution as the Objective Function: The model’s reward function (in Reinforcement Learning from Human Feedback - RLHF) should be aligned with the constitutional values of Article 14 (Equality) and Article 21 (Dignity).
• Anti-Ableist Fine-Tuning: The model must be penalised for generating "inspiration porn," "medical model" diagnoses for social queries, or ableist stereotypes. It should be rewarded for providing accessible, empowering, and rights-based responses.12

5.2 Accessibility Red Teaming

The Safe & Trusted AI pillar 7 must institutionalize Accessibility Red Teaming—a structured adversarial testing process focused on disability bias.45

• Methodology: Unlike security red teaming (which tests for hacks), accessibility red teaming tests for Allocative Harms (denial of resources) and Quality of Service Harms (degraded performance).46
• The Red Team: This requires recruiting "white-hat" testers with disabilities—blind screen-reader users, autistic testers, deaf signers—to identify failure modes that able-bodied developers cannot perceive.47
• NIST Alignment: The IndiaAI Safety Institute (AISI) should align its red teaming protocols with the NIST AI Risk Management Framework (RMF), which explicitly identifies "bias and discrimination" as top-tier risks.48

5.3 Case Study: The Bhashini Gap

Bhashini, the National Language Translation Mission, is a flagship success, offering text-to-text translation in 22 languages.36 However, it currently treats Indian Sign Language (ISL) as an outlier.

• The "23rd Language": ISL is a distinct natural language with its own grammar (Subject-Object-Verb), distinct from spoken Hindi or English.
• The Inclusivity Stack Requirement: The Bhashini mandate must be expanded to treat ISL as the "23rd language." This requires funding for specific transformer architectures capable of processing 3D spatial grammar (video-to-text and text-to-avatar), moving beyond simple gesture recognition.36

6. The Governance Layer: Operationalising Justice

Technology is deployed within a bureaucratic structure. The "Governance Layer" ensures that the technical capabilities of the Inclusivity Stack are enforced through administrative and financial levers.

6.1 Public Procurement as a Policy Lever (GeM)

The Government of India is the largest purchaser of technology in the country. The Government e-Marketplace (GeM) is the primary funnel for this procurement.51

• Mandatory Accessibility Check: GeM must integrate a mandatory "IS 17802 Compliance" field for all AI and software tenders. Vendors should be required to upload a Voluntary Product Accessibility Template (VPAT) or a certificate from the Standardisation Testing and Quality Certification (STQC) directorate.52
• Market Shaping: By disqualifying inaccessible products from government tenders, the state creates a powerful market incentive for private vendors to adopt "Universal Design" principles.

6.2 Disability Impact Assessments (DIA)

For high-stakes AI deployments (e.g., policing, welfare distribution, healthcare), the nodal agency must conduct a Disability Impact Assessment (DIA) prior to deployment.8

• Framework: A DIA evaluates:

1. Exclusion Risk: Does the system (e.g., DigiYatra) exclude specific disability phenotypes (e.g., facial paralysis)?
2. Disparate Impact: Is the error rate higher for PwDs than for the general population?
3. Accommodation Pathways: Is there a non-digital, human-in-the-loop alternative available?

• Accountability: The results of the DIA should be public, and high-risk findings should trigger a mandatory pause in deployment until mitigations are in place.54

6.3 Institutional Accountability: CCPD and CAG

• Chief Commissioner for Persons with Disabilities (CCPD): The CCPD should establish a specialized "Digital Rights Wing" equipped with technical experts to adjudicate complaints regarding digital accessibility and AI discrimination.30
• Comptroller and Auditor General (CAG): As the CAG moves towards auditing AI systems 9, it must include specific "inclusivity audit" parameters. An AI system that is inaccessible is an inefficient use of public funds and should be flagged in CAG reports.

7. Case Studies in Exclusion and Remediation

7.1 DigiYatra and Biometric Exclusion

The Problem: DigiYatra uses Facial Recognition Technology (FRT) for airport entry. While efficient for the majority, it poses severe exclusion risks for PwDs.

• Biometric Failure: Individuals with cerebral palsy (head tremors), facial disfigurements, or Down syndrome often experience higher "False Rejection Rates" in FRT systems.9
• Physical Barriers: The automated gates often close too quickly for wheelchair users or those with slow gaits, causing physical anxiety or harm.55

The Inclusivity Stack Solution:

1. Data: Retrain the FRT models using a "Disability Data Trust" dataset to improve recognition of diverse faces (The Outlier Advantage).
2. Process: Mandate a permanent, staffed "Accessibility Lane" that does not require biometric authentication. This lane should not be a "penalty box" (slower) but a "premium service" (faster) to ensure dignity.56

7.2 PM-Kisan and Algorithmic Gatekeeping

The Problem: Welfare schemes like PM-Kisan rely on Aadhaar-seeded databases and AI-driven fraud detection to disperse funds.57

• Exclusion: AI systems may flag "suspicious" patterns—such as a mismatch in biometrics due to manual labor or disability—leading to the automated suspension of benefits ("Digital Death").
• Lack of Recourse: The grievance redressal mechanisms are often digital-first (chatbots), which may themselves be inaccessible to the blind or illiterate.

The Inclusivity Stack Solution:

1. Human-in-the-Loop: Any AI decision to suspend benefits must be automatically escalated to a human review officer.
2. Accessible Redressal: A "Click-to-Call" feature or a dedicated, accessible web portal compliant with IS 17802 must be available for beneficiaries to challenge algorithmic decisions.25

8. Conclusion: The Road to a Viksit Bharat

India’s aspiration to become a Viksit Bharat (Developed Nation) by 2047 rests on its ability to harness the full potential of its human capital. Leaving 2.21% of the population (officially) or closer to 15% (globally estimated) behind in a "digital apartheid" is not just a violation of human rights; it is a strategic error that undermines the nation’s economic and social cohesion.

The Inclusivity Stack proposed in this report is not an optional add-on; it is the structural steel required to support the weight of a billion aspirations. By operationalising the legal mandates of Rajive Raturi, leveraging the "Outlier Advantage" in data, and enforcing accountability through governance, India can demonstrate that its "Sovereign AI" is truly sovereign—because it serves everyone.

As India builds the digital highways of the 21st century, it must ensure they have ramps. The cost of exclusion is high, but the return on inclusion—a resilient, robust, and just digital republic—is immeasurable.

Table 1: The Inclusivity Stack – Summary of Recommendations

Layer	Current State (The Problem)	The Inclusivity Stack (The Solution)	Key Lever / Standard
Legal	Voluntary guidelines; "Soft Law" approach.	Mandatory Compliance; Non-negotiable standards.	Rajive Raturi Judgment; IS 17802; RPWD Act S.40.
Data	Data Voids; Medical Model annotation; Exclusion of outliers.	Disability Data Commons; Social Model annotation; Outlier Advantage.	AIKosh; DEPA; Data Trusts.
Model	Bias; Hallucinations; "Inspiration Porn"; Ignored edge cases.	Constitutional AI; Accessibility Red Teaming; Anti-ableist RLHF.	BharatGen; NIST RMF; AISI.
Interface	Inaccessible CAPTCHAs; Lack of ISL; Voice-only or Text-only silos.	Universal Design; Multi-modal access (ISL, text, voice, switch).	Bhashini (ISL Mission); CAN-ASC-6.2.
Governance	Self-regulation; Lack of audits; Technoableism.	Disability Impact Assessments (DIA); Third-party Audits; Procurement mandates.	GeM; CCPD; CAG Audits.

References & Citation Key

• Legal: Rajive Raturi v. Union of India (2024) 14; RPWD Act 2016 27; IS 17802.28
• Policy: IndiaAI Mission 1; NITI Aayog AI Strategy 7; EU AI Act 33; CAN-ASC-6.2.25
• Theory: Technoableism (Ashley Shew) 23; Social vs. Medical Model 18; Algorithmic Harms.46
• Technical: Red Teaming 45; Bias in datasets 8; Bhashini 36; Outlier Advantage.37
• Governance: GeM Procurement 51; DEPA & Data Trusts.41

Works cited

1. Cabinet Approves Over Rs 10300 Crore for IndiaAI Mission, will Empower AI Startups and Expand Compute Infrastructure Access - PIB, accessed on February 14, 2026, https://www.pib.gov.in/PressReleasePage.aspx?PRID=2012375
2. Transforming India with AI - PIB, accessed on February 14, 2026, https://www.pib.gov.in/PressReleasePage.aspx?PRID=2178092
3. Transforming India with AI: Rs 10,300 crore mission, 38,000 GPUs & a vision for inclusive growth | DD News, accessed on February 14, 2026, https://ddnews.gov.in/en/transforming-india-with-ai-rs-10300-crore-mission-38000-gpus-a-vision-for-inclusive-growth/
4. parliament question: role of bharatgen ai - Press Release: Press Information Bureau, accessed on February 14, 2026, https://www.pib.gov.in/PressReleseDetailm.aspx?PRID=2223738®=3&lang=1
5. BharatGen: India's First Sovereign AI Initiative, accessed on February 14, 2026, https://bharatgen.com/
6. Union budget 2024-25 allocates over 550 crores to the IndiaAI mission, accessed on February 14, 2026, https://indiaai.gov.in/article/union-budget-2024-25-allocates-over-550-crores-to-the-indiaai-mission
7. India AI Governance Guidelines - AWS, accessed on February 14, 2026, https://indiaai.s3.ap-south-1.amazonaws.com/docs/guidelines-governance.pdf
8. Digital accessibility in the era of artificial intelligence—Bibliometric analysis and systematic review - Frontiers, accessed on February 14, 2026, https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2024.1349668/full
9. Auditing AI: What is it and why does it matter for India?, accessed on February 14, 2026, https://www.orfonline.org/expert-speak/auditing-ai-what-is-it-and-why-does-it-matter-for-india
10. Balancing convenience and data privacy in the Digi Yatra app, accessed on February 14, 2026, https://papers.ssrn.com/sol3/Delivery.cfm/5150113.pdf?abstractid=5150113&mirid=1
11. ABLEist: Intersectional Disability Bias in LLM-Generated Hiring Scenarios - arXiv, accessed on February 14, 2026, https://arxiv.org/html/2510.10998v1
12. Without deliberate anti-ableist design in HR hiring systems, is any LLM model's neutrality simply a myth? - Gareth Ford Williams, accessed on February 14, 2026, https://garethfordwilliams.medium.com/without-deliberate-anti-ableist-design-in-hr-hiring-systems-is-any-llm-models-neutrality-simply-d7cc134e8238
13. The Intersection of Technology, Disability Rights and Worker Rights, accessed on February 14, 2026, https://www.nationaldisabilityinstitute.org/wp-content/uploads/2025/01/intersectionoftechnologydisabilityandworkerrights2024report.pdf
14. Case Report: Rajive Raturi v. Union of India (2024) [LiveLaw (SC) 875], accessed on February 14, 2026, https://kshetryandassociates.com/case-report-rajive-raturi-v-union-of-india-2024-livelaw-sc-875/
15. IN THE SUPREME COURT OF INDIA CIVIL ORIGINAL JURISDICTION Writ Petition (C) No. 243 of 2005 Rajive Raturi …Petitioner Vers, accessed on February 14, 2026, https://api.sci.gov.in/supremecourt/2005/9321/9321_2005_1_1503_56986_Judgement_08-Nov-2024.pdf
16. Important Judgements for the Persons with disabilities | NIEPVD Dehradun | India, accessed on February 14, 2026, https://niepvd.nic.in/important-judgements-for-the-persons-with-disabilities/
17. Disability-First AI Dataset Annotation: Co-designing Stuttered Speech Annotation Guidelines with People Who Stutter - arXiv, accessed on February 14, 2026, https://arxiv.org/html/2602.10403v1
18. Medical and Social Models of Disability | Office of Developmental Primary Care, accessed on February 14, 2026, https://odpc.ucsf.edu/clinical/patient-centered-care/medical-and-social-models-of-disability
19. Identifying Disability Insensitive Language in Scholarly Works using Machine Learning - IslandScholar, accessed on February 14, 2026, https://islandscholar.ca/sites/default/files/2025-10/robyroshna_honours_thesis_2025.pdf
20. Full article: Disabling AI: power, exclusion, and disability - Taylor & Francis, accessed on February 14, 2026, https://www.tandfonline.com/doi/full/10.1080/01425692.2025.2519482
21. Technology and Disability: Trends and Opportunities in the Digital Economy in ASEAN, accessed on February 14, 2026, https://www.eria.org/uploads/Technology-and-Disability-Trends-and-Opportunities-in-the-Digital-Economy-in-ASEAN.pdf
22. Social Model vs Medical Model of disability - disabilitynottinghamshire.org.uk, accessed on February 14, 2026, https://www.disabilitynottinghamshire.org.uk/index.php/about/social-model-vs-medical-model-of-disability/
23. Ashley Shew - Against Technoableist AI - YouTube, accessed on February 14, 2026, https://www.youtube.com/watch?v=j7JcRwNWETM
24. Against Technoableism | Rethinking Who Needs Improvement | College of Liberal Arts and Human Sciences | Virginia Tech, accessed on February 14, 2026, https://liberalarts.vt.edu/news/bookshelf/science-technology-and-society-bookshelf/2023/liberalarts-against-technoableism.html
25. Summary of CAN-ASC-6.2:2025 – Accessible and Equitable Artificial Intelligence Systems, accessed on February 14, 2026, https://accessible.canada.ca/creating-accessibility-standards/overview-asc-62-accessible-equitable-artificial-intelligence-systems
26. Finding Sizes For All - Report On The Status of The Right To Accessibility in India - Scribd, accessed on February 14, 2026, https://www.scribd.com/document/749742948/Finding-Sizes-for-All-Report-on-the-Status-of-the-Right-to-Accessibility-in-India
27. Case Laws that are Shaping Digital Accessibility in India - BarrierBreak, accessed on February 14, 2026, https://www.barrierbreak.com/case-laws-that-are-shaping-digital-accessibility-in-india/
28. India's Digital Accessibility Laws and Overview • DigitalA11Y, accessed on February 14, 2026, https://www.digitala11y.com/indias-digital-accessibility-laws-and-overview/
29. IS 17802 (Part 2) : 2022 - Broadband India Forum, accessed on February 14, 2026, https://broadbandindiaforum.in/wp-content/uploads/2022/08/IS-17802_2_2022.pdf
30. RPWD Act and IS 17802: India's Digital Accessibility Standards (2025 Guide), accessed on February 14, 2026, https://www.pivotalaccessibility.com/2025/06/rpwd-act-and-is-17802-indias-digital-accessibility-standards-2025-guide/
31. CAN-ASC-6.2:2025- Accessible and Equitable Artificial Intelligence ..., accessed on February 14, 2026, https://accessible.canada.ca/creating-accessibility-standards/asc-62-accessible-equitable-artificial-intelligence-systems
32. How to Implement CAN-ASC-6.2:2025 Accessibility Requirements for AI Systems?, accessed on February 14, 2026, https://www.barrierbreak.com/how-to-implement-can-asc-6-22025-accessibility-requirements-for-ai-systems/
33. A disability-inclusive Artificial Intelligence Act: : a guide to monitor ..., accessed on February 14, 2026, https://www.edf-feph.org/content/uploads/2024/10/AI-Act-implementation-toolkit-Final.pdf
34. EU AI Act - Updates, Compliance, Training, accessed on February 14, 2026, https://www.artificial-intelligence-act.com/
35. (PDF) Artificial Intelligence for Accessibility: A Comprehensive Systematic Review and Impact Framework for Assistive Technologies - ResearchGate, accessed on February 14, 2026, https://www.researchgate.net/publication/396241449_Artificial_Intelligence_for_Accessibility_A_Comprehensive_Systematic_Review_and_Impact_Framework_for_Assistive_Technologies
36. Bhashini AI - Making Languages More Accessible with Digital Technology - Unicef, accessed on February 14, 2026, https://www.unicef.org/digitalimpact/bhashini-ai-making-languages-more-accessible-digital-technology
37. AI Data-Driven Personalisation and Disability Inclusion - ResearchGate, accessed on February 14, 2026, https://www.researchgate.net/publication/348569682_AI_Data-Driven_Personalisation_and_Disability_Inclusion
38. AI Fairness for People with Disabilities: Point of View - arXiv, accessed on February 14, 2026, https://arxiv.org/pdf/1811.10670
39. 2024 Summer Research Grant Awardees | Villanova University, accessed on February 14, 2026, https://www.villanova.edu/villanova/provost/research/institute-research-scholarship/find_support_need/internal_funding/summer-grant/2024-Recipients.html
40. (PDF) Tamavaq™: A Hybrid Quantum–Classical Grover Pipeline for Precision Neoantigen Vaccination in Glioma - ResearchGate, accessed on February 14, 2026, https://www.researchgate.net/publication/397449493_Tamavaq_A_Hybrid_Quantum-Classical_Grover_Pipeline_for_Precision_Neoantigen_Vaccination_in_Glioma
41. AI Impact Summit 2026: AI Governance at the Edge of Democratic Backsliding, accessed on February 14, 2026, https://www.csohate.org/2026/02/11/ai-impact-summit-2026/
42. Rebooting consent in the digital age: a governance framework for health data exchange, accessed on February 14, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC8728384/
43. The design of a data governance system - SUERF - The European Money and Finance Forum, accessed on February 14, 2026, https://www.suerf.org/publications/suerf-policy-notes-and-briefs/the-design-of-a-data-governance-system/
44. What Is a Data Trust? - Centre for International Governance Innovation, accessed on February 14, 2026, https://www.cigionline.org/articles/what-data-trust/
45. Red teaming ChatGPT in medicine to yield real-world insights on model behavior - PMC, accessed on February 14, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC11889229/
46. Toward a Taxonomy of Algorithmic Harms for ... - AAAI Publications, accessed on February 14, 2026, https://ojs.aaai.org/index.php/AIES/article/download/36745/38883/40820
47. Guide to Red Teaming Methodology on AI Safety (Version 1.10), accessed on February 14, 2026, https://aisi.go.jp/assets/pdf/E1_ai_safety_RT_v1.10_en.pdf
48. Supporting NIST's Development of Guidelines on Red- teaming for Generative AI - Carnegie Mellon University, accessed on February 14, 2026, https://www.cmu.edu/sites/default/files/cmu-block-center-site-files/2025-07/supporting-nists-development-of-guidelines-on-red-teaming-for-generative-ai-2024.pdf
49. NIST releases its Generative Artificial Intelligence Profile: Key points | DLA Piper, accessed on February 14, 2026, https://www.dlapiper.com/en/insights/publications/ai-outlook/2024/nist-releases-its-generative-artificial-intelligence-profile
50. Bhashini Logo, accessed on February 14, 2026, https://bhashini.gov.in/
51. Harnessing AI and digital public infrastructure (DPI) for Viksit Bharat | EY, accessed on February 14, 2026, https://www.ey.com/content/dam/ey-unified-site/ey-com/en-in/insights/ai/documents/ey-harnessing-ai-and-digital-public-infrastructure-for-viksit-bharat.pdf
52. The Central Government to leverage AI in GeM procurement: Union Minister Piyush Goyal, accessed on February 14, 2026, https://indiaai.gov.in/article/the-central-government-to-leverage-ai-in-gem-procurement-union-minister-piyush-goyal
53. Digital accessibility in the era of artificial intelligence—Bibliometric analysis and systematic review - PMC, accessed on February 14, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC10905618/
54. Impact Assessments: - Supporting AI Accountability & Trust - Workday Blog, accessed on February 14, 2026, https://blog.workday.com/content/dam/web/en-us/documents/legal/access-partnership-workday-impact-assessment-paper.pdf
55. Adoption of Digital Identity in Airline Transit: A Global Overview | Kairos Blog, accessed on February 14, 2026, https://www.kairos.com/post/adoption-of-digital-identity-in-airline-transit-a-global-overview
56. Digi yatra policy doc - Ministry of Civil Aviation, accessed on February 14, 2026, https://www.civilaviation.gov.in/sites/default/files/migration/Digi%20yatra%20policy%20doc.pdf
57. GOVERNING AI IN WELFARE DELIVERY - Efficiency, Exclusion, and Constitutional Accountability PARNEET KAUR - SSRN, accessed on February 14, 2026, https://papers.ssrn.com/sol3/Delivery.cfm/6080208.pdf?abstractid=6080208&mirid=1
58. Why Governments Need Unified Social Registry for Beneficiary Targeting - CSM Technologies, accessed on February 14, 2026, https://www.csm.tech/blog-details/blog_pdf/why-governments-need-unified-social-registry-for-beneficiary-targeting
59. Supreme Court Mandates Barrier-Free Public Spaces. A Landmark Judgment Ensuring Equal Access to Public Spaces for Persons with Disabilities (PWDs) - Lawtext, accessed on February 14, 2026, https://lawtext.in/judgement.php?bid=1158
60. Recital 80 | EU Artificial Intelligence Act, accessed on February 14, 2026, https://artificialintelligenceact.eu/recital/80/
61. Social and medical models of disability and mental health: evolution and renewal - PMC, accessed on February 14, 2026, https://pmc.ncbi.nlm.nih.gov/articles/PMC6312522/
62. LLM Red Teaming: The Complete Step-By-Step Guide To LLM Safety - Confident AI, accessed on February 14, 2026, https://www.confident-ai.com/blog/red-teaming-llms-a-step-by-step-guide
63. Samudaye - Bhashini, accessed on February 14, 2026, https://bhashini.gov.in/samudaye/anusandhan-mitra/6