Accessibility is one of those things most React developers agree on in theory.
Semantic HTML. Keyboard navigation. Screen reader support. Proper labels. Everyone knows it matters.
And then they open a pull request and find a clickable div where a button should be. An icon with no label. A form input with no associated label element. A modal that traps focus nowhere.
Not because the developer forgot. Because GitHub Copilot generated it that way and nobody defined what accessible output actually looks like.
The AI does not skip accessibility on purpose
GitHub Copilot is not making a judgment call when it generates a clickable div instead of a button.
It is taking the path of least resistance. A div works. It renders. It does not throw an error. Without a rule that says "interactive elements must always use semantic HTML", Copilot has no reason to reach for a button instead.
The same is true for form labels. For ARIA attributes. For focus management in modals. For keyboard operability.
Copilot will generate accessible code when the rules define that it must. Without those rules, it improvises. And improvised accessibility looks like the pull request nobody wants to review.
Accessibility is not a prompt problem
You cannot fix this by describing accessibility requirements in every prompt.
You will forget sometimes. You will be in a hurry sometimes. The prompt will be vague sometimes. And the moment the description is missing, Copilot falls back to whatever it defaults to.
Accessibility built on prompt discipline is fragile. It works when you remember. It breaks when you do not.
The only way to make accessibility consistent is to move it out of the prompt and into the rules. Rules that define what every piece of generated UI must look like before Copilot writes a single line.
Semantic HTML by default. Labels always present. Interactive elements always keyboard operable. Focus management always handled. Not sometimes. Every time.
What consistent accessible output actually looks like
I have been working with a rule system for GitHub Copilot for several months now.
Accessibility is not something I think about per prompt anymore. It is defined in the system. Every component that comes out follows the same accessible patterns. Semantic HTML. Proper labels. Keyboard support. ARIA only where semantic HTML is not enough.
The output is accessible by default. Not because every prompt asks for it. Because the rules make it impossible for Copilot to generate anything else.
That is what the right rules do. They remove the dependency on memory, discipline, and perfect prompts. The standard is always there. The output always follows it.
The prompt does not matter. The rules do.
Accessible React output is not a question of how well you describe accessibility to your AI.
It is a question of whether your AI has rules that make accessible output the only option.
Give it those rules. Stop reviewing for accessibility issues after the fact. Start defining what accessible means before the first line is generated.
The prompt doesn't matter. The rules do.
Want to see what those rules look like?
I packaged my first three React AI rules as a free PDF. The starting point for consistent, rule-driven AI output in every React project.
👉 Get My First 3 React AI Rules — free
And if you want the full system — including accessibility rules, architecture, typing, state, and more:
Top comments (0)