Accessibility Belongs in the First Prompt, Not the Final Audit

Accessibility belongs in the first prompt a developer writes to an AI coding assistant, not in the post-build audit pass. That's the central argument Pasquale Pillitteri, a developer and writer focused on inclusive design, makes in his latest essay on accessibility in vibe coding.

Vibe coding describes a workflow where a developer describes the application they want in natural language and lets a generative model produce the code. The term captured a shift that moved from prototype to production over the past year, as large language models grew fluent enough to ship features rather than just suggest snippets. Pillitteri's argument targets the workflow directly. When accessibility arrives at the end, it inherits whatever the model has already decided.

What is vibe coding, and why does timing matter?

In a vibe-coded project, the prompt is the specification. The developer types something close to "build me a checkout flow with address, shipping, and payment" and reviews what comes back. Components, layout, and interactions fall out of the model's interpretation of that text. The model rarely infers that the developer needs visible focus on every interactive element, error messages announced to assistive technology, or a minimum contrast on disabled buttons. Those details don't surface unless they sit inside the first prompt.

Why do final audits keep missing the mark?

Audits run on finished code. They test against published accessibility guidelines and produce a list of failures an engineer can act on. That list matters. It doesn't, however, reach the decisions a model made during generation, when the shape of a component was set in motion by a sentence like "make the primary action stand out."

Color-coded error states. Modal dialogs that close on outside click but ignore the escape key. Inputs that rely on placeholder text as a label. These patterns show up in audits as findings, but they trace back to a single line of prompt.

Pillitteri's point lands here. The audit can patch the symptom. It can't rewrite the thinking that produced the layout. When developers write prompts that treat accessibility as a constraint rather than an outcome, the model responds in kind.

What changes when accessibility lives in the first prompt?

A prompt that names the audience changes the output. Write "build me a checkout flow usable by someone navigating with a keyboard and a screen reader, with visible focus on every interactive element, error messages announced via a live region, and a 4.5:1 minimum contrast" and the model has somewhere to start. The generated code is no longer a clean guess about intent. It's a response to a stated need.

The user outcome is measurable. People who navigate by keyboard or assistive technology either complete the flow or they don't. Specifying accessibility upfront shifts that ratio in a way a late audit cannot.

What does this mean for design teams?

For design leaders, the implication is operational. Accessibility stops being a checklist handed to engineering at the end of a sprint. It becomes a brief that enters the prompt before the model writes a line of code. The role of accessibility experts shifts earlier in the cycle, into the prompt-writing phase, where one well-constructed sentence can prevent dozens of audit findings.

Engineering managers who have shipped with vibe-coded workflows describe the shift as similar to writing a design brief. The prompt replaces the ticket. Constraints stated once at the top travel through every generated component.

Pillitteri's argument is small in scope and pointed in application. It doesn't need new tooling or new standards. It needs the order of operations to change.

If vibe coding is how more teams ship software this year, accessibility will rise or fall on what those first prompts say.