The need for INCLUSION.md

Beyond A11Y.md: context engineering for inclusive AI-assisted design and development.

May 2026Accessibility

Going Beyond A11Y.md

AI-assisted work is rapidly becoming the default for designers and engineers alike. Designers now prompt their way into flows, components, and entire products. Engineers do the same with code. And in both cases, generative systems are no longer just helping us ship - they're helping us design.

That shift moves accessibility and inclusive design upstream. The experiences and interfaces we used to author by hand are now being willed into existence by agentic systems trained on tons of different datasets like the public web - which, as we know painfully well, is overwhelmingly inaccessible and unevenly representative of human diversity.¹

In Mismatch, Kat Holmes describes exclusion as exactly that - a "mismatch" between systems and the ways (plural!!) humans need to use them. Now, exclusion usually isn't malicious. It happens when systems get quietly optimized around what's assumed to be the predominant use case.

Sadly, modern LLMs are inherently 'mismatched' in this exact way. But they aren't purposefully built to be exclusionary - they inherit statistical assumptions from skewed training data. Their understandings of humanity are driven by the most common patterns they've been exposed to.

The training data problem, briefly

The 2023 WebAIM Million Report found that 96.3% of the top one million homepages had detectable WCAG failures.¹ LLMs are trained extensively on public web content. The math isn't subtle.

And it's not theoretical. In You Look Like a Thing and I Love You, Shane shares a whole catalog of examples of ML systems faithfully learning the wrong pattern from their data: a skin-cancer classifier that mostly learned to detect rulers (because malignant photos in the dataset often had one for scale), a "fish" detector that mostly learned to recognize human fingers (because most training photos were of anglers holding their catch), and image taggers that confidently labeled sheep in any green grassy field - even when the sheep weren't there.⁷ Probabilistic systems are extraordinarily good at finding the easiest correlation in front of them, and the easiest correlation is rarely the one we meant.

When that same property gets pointed at people, the failure modes turn from funny to harmful. Amazon famously had to scrap an internal resume-screening model after it learned to down-rank applications containing the word "women's" - because the historical data it learned from was overwhelmingly male.⁷ Word-embedding studies have surfaced similar patterns at the language level (man is to computer programmer as woman is to homemaker, etc.).⁷ Same mechanism, different stakes.

Emerging research has documented disability representation patterns in LLM outputs including ableist framing, tokenization, inspiration narratives, underrepresentation, deficit-based language, intersectional erasure, and neurotypical communication assumptions.²³⁵

The hard part is that most of these harms aren't loud. Disabled participants in this research often described model outputs as mirroring familiar social stereotypes - not producing obviously hateful content.³ Subtle exclusion is much harder to detect and govern inside design and engineering systems. For a deeper dive into the empirical evidence behind this - the ABLEIST research, hiring bias across LLMs, the training-data feedback loop, and what bias-correction techniques actually move the needle - I wrote a nifty companion piece on Thesis.⁵

Now, we'll be fair and acknowledge that modern flagship models like Claude and ChatGPT have invested tons of time and money into releasing bigger, better models with less biases, less hallucinations, less silly bugs, etc. And I'm not asserting that perfection is required here for there to be value.

The Landscape Today

Accessibility compliance !== inclusion

Most accessibility tooling and guidance still focuses on implementation correctness: semantic HTML, keyboard navigation, ARIA, contrast, WCAG conformance. All of it essential. None of it really addresses representational harms, cultural assumptions, or the contextual gaps living inside the generative systems we're now designing and building with.

An interface can pass an accessibility audit cleanly and still reproduce exclusionary assumptions about disability, cognition, communication, culture, literacy, or identity when designing and building end to end experiences.

The distinction I keep coming back to:

• Accessibility addresses whether users can access a system.
• Inclusion addresses whether users are meaningfully considered in the assumptions shaping the system in the first place.

AI is now an upstream design partner

The biggest structural shift in our craft right now is that AI tools sit between human intent and what ships - and increasingly that's true on the design side as much as the engineering side. Figma's Make, Cursor, v0, Claude Code, Copilot, and friends are drafting components, generating layouts & product flows, naming things, writing microcopy, sketching personas, even mocking research artifacts.

If AI is going to design with some autonomy, it needs to be aware of the biases baked into its training data - much like human designers need to be aware of the cognitive schemas and assumptions shaping how we understand the world and our users. Self-awareness is a prerequisite for inclusion, whether the designer is a person or a probabilistic system. And to address this, we need new clever ways to operationalize inclusivity in our flashy new AI tools. One of the most effective emerging patterns for this is context engineering.

Markdown / *.md context conventions are all the rage

If you've been working in AI-assisted tooling lately, you've probably noticed people slapping *.md files in their repos to give their assistants more context. It's a great way to better prime agents to code and design in a repo with complete, accurate, and specific information - not just its general built-in knowledge of general stuff.

Some recent popular examples I've seen:

• AGENTS.md - a vendor-neutral "agent instructions" file pushed by agents.md and adopted by Cursor, Aider, Continue, and others. The closest thing the ecosystem has to a shared standard.
• CLAUDE.md - Claude Code's native repo-level context file. Anthropic's CLI reads it automatically on session start; people use it for repo conventions, build commands, and what not to touch.
• .github/copilot-instructions.md - GitHub Copilot's official repo instructions file. Read by Copilot Chat and Copilot coding agents to shape suggestions and PR behavior.
• .cursor/rules/*.md (and the older .cursorrules) - Cursor's per-repo rule files. Can be scoped with glob patterns so different folders get different instructions.
• .windsurfrules and Continue's .continuerules - the same idea for Windsurf and Continue respectively.
• DESIGN.md - showing up in design-engineering tools like Google's Stitch and inside design-system repos to encode visual language, token usage, and component conventions.
• A11Y.md - an accessibility-specific instructions file (WCAG targets, ARIA conventions, keyboard models). Increasingly common in component libraries and design systems.
• CONTRIBUTING.md - the classic. Written for humans, but every modern coding assistant reads it as context too.

The throughline: each file targets a specific kind of decision the assistant is making. A11Y.md shapes implementation correctness. DESIGN.md shapes visual and interaction language. CONTRIBUTING.md shapes process. AGENTS.md and the vendor-specific files shape behavior overall.

Introducing INCLUSION.md!

The pitch is simple: an INCLUSION.md context file. A repository-level context engineering doc whose job is to give AI tools - the ones designers and engineers are now using together - persistent, inclusion-oriented guidance during generation.

Where A11Y.md is all about technical accessibility implementation, INCLUSION.md focuses on the contextual and representational layer:

• known training-data blind spots
• disability representation guidance
• communication diversity
• intersectional inclusion
• cultural assumptions and defaults
• cognitive accessibility considerations
• inclusive language heuristics
• review prompts for generated outputs

Now, grounding ourselves here: this file convention isn't going to "solve" AI bias. Bias mitigation is an unresolved sociotechnical problem and you can't prompt your way out of it.⁴

The goal is more modest and more durable: operationalize inclusive design principles directly inside AI-native design/dev workflows, right where generation is actually happening. Much like the other context files popping up in different tools, it's an attempt to smooth over some gaps and blind spots as AI builds products for us.

So what could that look like, specifically?

Open source it!

Talk is cheap - so I wanted to start hacking on this idea. I went ahead and drafted the actual scaffold and shipped it as an open-source repository:

github.com/BranonConor/inclusion.md

INCLUSION.md - an LLM/agent context convention for model biases.

It's intentionally rough around the edges - the kind of thing we can iron out together with collective, lived experience, as an industry and community. Fork it, adapt it, translate it, argue with it. The repo contains the full INCLUSION.md template + a CLI tool for easy npx generation in a project. It's also got a few examples of use cases and guidance on contributions. Neat.

How to start using it

There are two equally valid ways to get the file into your repo. Pick whichever fits your team's vibe.

1. Generate it with the CLI (recommended)

npx inclusion-md init

Run it, answer some questions, pick a use-case, and it writes an INCLUSION.md file to your repo root with your specifications. Zero install, zero dependencies, Node 16+.

2. Or copy the file by hand

curl -O https://raw.githubusercontent.com/BranonConor/inclusion.md/main/INCLUSION.md

Place it at the root of your repository and fill in Section 1 (Project Context) yourself. The first section is intentionally blank so you can detail the inclusion criteria specific to your project. The rest of the file is general inclusion guidance anyone might benefit from!

3. Point your AI assistant at it

// GitHub Copilot - in .github/copilot-instructions.md
This repository contains an `INCLUSION.md` at the project root.
Follow its guidance when generating UI copy, code, documentation,
error messages, persona descriptions, and review feedback.

// Cursor - in .cursor/rules/inclusion.md
Always read and follow `/INCLUSION.md` when generating code, copy,
or design artifacts in this repository.

// Claude Code - in CLAUDE.md
Read `/INCLUSION.md` and apply its review prompts before
finalizing any generated output in this repository.

4. Treat it like the rest of your engineering docs

Name an owner. Review on a cadence (quarterly is a reasonable default). Track changes in a CHANGELOG.md. Provide a feedback route for users and contributors.

And - this one matters - don't generate inclusion guidance with an LLM and ship it unedited. That's exactly the failure mode this whole essay is about. Use the template as a starting point, then bring it to disabled practitioners, accessibility experts, and the communities your software actually touches.

Final Thoughts

Thanks for making it this far. I'm hopeful this might actually influence the way agentic AI design and development takes shape, and that those effects are felt by real users of all abilities. Hit me up if you have thoughts. Cheers to doing our best :)

• Branon

References

1. WebAIM Million Report 2023 - webaim.org/projects/million/2023 ↩
2. ABLEIST: Measuring Ableist Harms in Large Language Models - arxiv.org/abs/2510.10998 ↩
3. Centering Disability Perspectives in LLM Research and Design - dl.acm.org/doi/10.1145/3613904.3642233 ↩
4. A Survey of Prompt Engineering and Guardrails for LLM Bias Mitigation - arxiv.org/abs/2506.18199 ↩
5. Branon Eusebio, The need for INCLUSION.md (Thesis) - thesis.social/article/cmp1vdxrs000h04k3xutnlbsw ↩
6. Kat Holmes, Mismatch: How Inclusion Shapes Design (MIT Press, 2018) - mitpress.mit.edu/9780262539485/mismatch
7. Janelle Shane, You Look Like a Thing and I Love You (Voracious, 2019) - janelleshane.com/book-you-look-like-a-thing ↩