Accessibility & Responsive Prompts
Make accessibility and responsiveness explicit requirements so AI builds inclusive, adaptive UI instead of div-soup you retrofit.
TL;DR
- Accessibility and responsiveness are requirements, not polish; state them in the prompt from the start.
- Require semantic HTML, keyboard operability, labels, focus management, and sufficient contrast.
- Ask for mobile-first, adaptive layouts and verify with real checks, not just a glance.
Make It A Requirement
Name The StandardState the target so expectations are concrete.
"Meet WCAG 2.2 AA."From The StartPut accessibility in the first prompt, not a later cleanup.
"Accessible by default, not retrofit."List The SpecificsSpell out roles, labels, focus, and contrast so nothing is vague.
"Semantic HTML, labels, focus order,
AA contrast."Semantics & Keyboard
Real ElementsUse button, a, nav, and headings instead of styled divs.
"Use <button>, not <div onClick>."Keyboard OperableEverything usable by mouse must work by keyboard too.
"Tab to reach, Enter/Space to
activate, Esc to close."Focus ManagementVisible focus and sensible focus order, especially for modals.
"Trap focus in the dialog; return
focus on close."Names & Contrast
Accessible NamesLabel icons, inputs, and controls for screen readers.
"aria-label on the icon button;
<label> tied to each input."ARIA SparinglyUse ARIA only when native semantics fall short.
"Prefer native elements; ARIA only
where needed."Color ContrastRequire AA contrast and do not rely on color alone.
"AA contrast; show state with icon +
text, not color only."Responsive & Verify
Mobile-FirstDesign for small screens first, then enhance upward.
"Mobile-first; reflow, don't
overflow. No h-scroll at 360px."Respect PreferencesHonor reduced motion and sufficient tap target sizes.
"Tap targets >=44px; respect
prefers-reduced-motion."Actually TestKeyboard, automated checker, and screen reader for key flows.
Tab through it. Run axe/Lighthouse.
Check a screen reader.Tips
- Name the standard ('meet WCAG 2.2 AA') and the specifics: roles, labels, focus order, contrast.
- Request keyboard and screen-reader behavior explicitly; these are the most commonly skipped.
Warnings
- Models produce div-soup with click handlers that keyboards and screen readers cannot use.
- Retrofitting accessibility later is costly; it is far cheaper to require it in the first prompt.
In Practice
A modal dialog requested with accessibility and responsiveness as explicit requirements, so you get semantic, keyboard-operable, contrast-safe UI instead of an inaccessible div with a click handler.
- The standard and specifics are named, so accessibility is concrete, not implied.
- Keyboard behavior and focus management are spelled out for the dialog.
- Accessible names and AA contrast are required, not left to chance.
- The prompt asks the model to list what it did so you know what to verify.
Build an accessible modal Dialog (React 18, TypeScript,
our design tokens). Target WCAG 2.2 AA.
Accessibility requirements:
- role="dialog", aria-modal, labelled by its heading
- open on trigger; trap focus inside; Esc closes;
return focus to the trigger on close
- all controls are real <button>s, keyboard operable
- visible focus-visible styles; AA contrast
- the close icon button has an aria-label
Responsive:
- full-screen sheet on mobile, centered card >=640px
- no horizontal scroll at 360px; tap targets >=44px
- respect prefers-reduced-motion for the open animation
After the code, list the accessibility features you
implemented so I can verify them.FAQ
Because it defaults to the quickest markup that looks right, often a div with an onClick, which is invisible to keyboards and screen readers. Models produce accessible UI reliably when you ask, and skip it reliably when you do not. Make it an explicit requirement.
Semantic elements (button, nav, main), accessible names and labels, keyboard operability and logical focus order, visible focus styles, ARIA only where semantics are insufficient, and color contrast meeting WCAG AA. Naming these produces inclusive components the first time.
Ask for mobile-first design with defined breakpoints, relative units, and content that reflows rather than overflows. Say what should change at each screen size, and require no horizontal scroll at common widths down to around 320-360px.
Do not trust a glance. Tab through the UI with the keyboard, run an automated checker (axe, Lighthouse), check contrast ratios, and test with a screen reader for key flows. Ask the model to list what it did so you know what to verify.