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.