# Accessibility Prompting Fixes Attributes Not Interaction Patterns ## Claim Adding accessibility instructions to an AI page-builder prompt reliably improves attribute-level properties like contrast and labels, and reliably fails to produce correct keyboard and focus behaviour for interactive components. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Demonstrated for AI website builders; the accordion example failed keyboard interaction even after additional accessibility prompting. - The split tracks what is expressible as a static property versus what requires stateful behaviour across events — the second is where generation degrades. - Untested here against component libraries or code-generation contexts outside page builders. - Implies the manual pass should be aimed at interactive widgets specifically, not spread evenly across the page. ## Evidence From the WordPress Accessibility Day 2025 session by Janaki Konar and Fahad Lambate on building a site with AI: prompting closed the contrast and labelling gaps while the accordion's keyboard behaviour stayed broken. ## Links - [[A Passing Automated Accessibility Score Is a Floor Not a Verdict]] — the same floor-versus-verdict gap measured on a generator's output instead of a checker's report - [[Generated Accessibility Targets Do Not Transfer Verification Responsibility]] — the general rule this is a worked instance of — a tool aiming at accessibility does not discharge the author's testing duty - [[An Icon Needs a Visible Label Not Just an Accessible Name]] — another case where the machine-checkable property passes while the human-facing behaviour still fails - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — the build-time thread — this is where AI generation sits on the prevent-versus-remediate line.