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