AI prompts for accessible design and code

AI is indisputably here and is making its way into every part of our workflow. And while it raises issues around ethics and accessibility, learning how to shape its outputs is our best chance at harnessing its power in favour of accessibility.

Nielsen Norman Group published their CARE model as guidance to getting better results from generative-AI chatbots:

The first two components of a prompt are Context and Ask, which will be specific to your project.

Rules and Examples are where we embed accessibility.

The Rules bit is straightforward enough:

“Make sure the design is fully compliant with WCAG 2.2AA”

WCAG 2.2AA is the latest international standard. Even if you live in or market to a region that doesn’t yet need to meet that standard, it is a good idea to aim for it.

But the power comes in being specific about your accessibility expectations. AI still gets accessibility wrong all the time, whether that’s making up WCAG criteria, missing some, or misinterpreting others.

Below you will find a plain English version of each WCAG 2.2 AA criteria, described in a sentence or two. Paste these descriptions as part of your prompt, as Examples to demonstrate what you want.

Important Notes:

1. The content for these prompts is taken directly from Aaardvark’s WCAG in Plain English. I used ChatGPT to extract the text (specifically: “For each H2 on each page [of the WCAG in Plain English site], write the text for the H2 plus the span that follows it”) and have not made any modifications except some tidy up. I take no credit to writing these prompts. The purpose of this page is to make it easier to copy-paste the prompts into your preferred gen AI, in the hopes to promote more accessible outputs.

2. I have not tested these prompts. I can’t attest to their effectiveness whatsoever. You may find more success by reading through the prompts and selecting the ones that best fit your project (ie, if you have no videos on your page, omit those criteria. Or, if you do have videos, the AI may trip up with the live vs prerecorded distinction so it would be best to select the relevant ones). If you use these prompts, please let me know your findings!

3. These plain English descriptions are not a replacement for the official WCAG. They may not capture edge cases and other specifications outlined in the more detailed sections of the documentation. While these prompts can help nudge AI towards a more accessible output, ultimately knowing what accessibility looks like is the best way to verify the results.

4. AI cannot make a 100% accessible design, site or app on its own. On the contrary, research has shown that AI consistently generates components and sites with accessibility issues. When prompted, it fixes those bugs by adding more code; thereby creating more accessibility issues and ultimately an unwieldy and inaccessible codebase. The only way to make sure something is actually accessible is to perform manual and user testing.

The prompts

1.1.1 Non-text Content

All images and other non-text content (like icons, charts, audio, CAPTCHAs, or controls) must have a descriptive text alternative that conveys their meaning. Purely decorative content can be hidden from assistive technologies (e.g. using an empty alt attribute).

1.2.1 Audio-only and Video-only (Prerecorded)

Prerecorded audio-only content must have a text transcript. Prerecorded video-only content must have a text or audio description.

1.2.2 Captions (Prerecorded)

Prerecorded videos with audio must have synchronized captions that include; all speech; relevant sound effects (like music, alarms, or laughter).

1.2.3 Audio Description or Media Alternative (Prerecorded)

Important visual content in prerecorded videos must be described using; an audio description or; a text-based alternative.

1.2.4 Captions (Live)

Live video with audio must include real-time captions that cover; speech and; important sound effects (like music, alarms, or laughter).

1.2.5 Audio Description (Prerecorded)

Important visual content in prerecorded videos with audio must be described using; an audio description, unless it is already explained in the main audio track.

1.3.1 Info and Relationships

Visual information and relationships (like labels, headings, or groupings) must also be conveyed in the code using semantic HTML (e.g. `<label for="">`, `<ul>`, `<h1>`) or ARIA attributes (e.g. `aria-describedby`, `role="group"`) so that assistive technologies can understand the structure.

1.3.2 Meaningful Sequence

Content must follow a logical and meaningful order in the code so it can be understood correctly by assistive technologies even if the visual layout differs.

1.3.3 Sensory Characteristics

Instructions and descriptions must not rely on sensory features alone, like color, shape, size, visual location, or sound. Always provide additional text to clarify meaning.

1.3.4 Orientation

Content must remain readable and usable in both portrait and landscape orientation, unless a specific one is essential (e.g. in a piano app that requires landscape to show the full keyboard).

1.3.5 Identify Input Purpose

The purpose of common form fields (like name, email, or address) must be defined in the code so that browsers and assistive technologies can offer input support, such as autocomplete.

1.4.5 Images of Text

Text must be actual text, not images of text, unless a specific visual presentation is absolutely necessary (e.g. logo).

1.4.10 Reflow

Content remains functional and easy to read when; zoomed to 400% or; viewed at 320px width, without needing to scroll in two directions (except for tables, maps, and similar content).

1.4.11 Non-text Contrast

Interactive controls (e.g. buttons, form fields, focus indicators) and graphics that convey meaning (e.g. icons, charts, graph lines) must have a contrast ratio of at least 3:1 against adjacent colors.

2.1.2 No Keyboard Trap

It must always be possible to move focus into and out of any component using a keyboard alone (e.g. \[tab], \[shift] + \[tab], \[enter], \[esc]), without getting stuck. ([AAArdvark][4])

2.1.4 Character Key Shortcuts

Keyboard shortcuts should use modifier keys like \[ctrl], \[cmd], or \[alt/option]. If single-key shortcuts are used (e.g. ‘S’ for save), it must be possible to turn them off, remap them with a modifier key, or restrict them to when the relevant element is focused.

2.2.1 Timing Adjustable

Time limits must be avoided unless essential for the task (e.g. exams, auctions). If time limits are used, it must be possible to turn them off, adjust them to at least 10× the default, or extend them by at least 10×.

2.2.2 Pause, Stop, Hide

If content moves, scrolls, blinks, or updates automatically for more than 5 seconds, it must be possible to pause it, stop it, or hide it.

2.3.1 Three Flashes or Below Threshold

Content must not flash, blink, or flicker more than three times per second, unless it stays within safety limits designed to avoid visual overload and reduce the risk of seizures.

2.4.1 Bypass Blocks

It must be possible to skip repeated blocks of content (e.g. navigation, header) and jump directly to the main part of the page.

2.4.2 Page Titled

Each page must have a unique and descriptive title that reflects its topic or purpose.

2.4.3 Focus Order

Focus must follow a logical and meaningful order that preserves relationships and matches how the page is naturally read, regardless of layout or language direction.

2.4.4 Link Purpose (In Context)

The purpose of each link must be clear from the link text itself, or the surrounding context.

2.4.5 Multiple Ways

At least two different ways must be available to find pages or content (e.g. navigation menus, on-page links, site search, or a sitemap).

2.4.6 Headings and Labels

Headings must describe what follows. Labels and buttons must clearly communicate what information is needed or what action will happen.

2.4.11 Focus Not Obscured (Minimum)

When an element receives focus, it must be at least partially visible.

2.5.1 Pointer Gestures

Actions that rely on gestures (like swiping or pinching) must also be possible using a single tap, click, or button.

2.5.2 Pointer Cancellation

Actions must not trigger on press or touch down. They must only trigger on release (like mouse-up or finger lift).

2.5.3 Label in Name

The visible text of a button, link, or form field must also be part of its accessible (programmatic) name.

2.5.7 Dragging Movements

Actions that require dragging (like reordering) must also be possible using buttons or another method that does not require dragging.

2.5.8 Target Size (Minimum)

Targets must be at least 24×24px, unless they are part of a sentence or block of text, surrounded by enough space, or near another target with the same function that meets the size.

3.1.1 Language of Page

Each page must have a `<html lang="">` attribute that matches the main language of the page.

3.1.2 Language of Parts

Any parts of the content in a different language must be marked with the correct `lang` attribute. Expressions borrowed from another language (like “déjà vu” in English) do not need this, unless pronunciation or understanding would be affected.

3.2.2 On Input

No unexpected changes must happen when a field value changes (like auto-submit, reload, open new page).

3.2.3 Consistent Navigation

Navigation elements (like menus, links, search) must appear in the same place and order across pages.

3.2.4 Consistent Identification

Elements with the same function must look, behave, and be labeled the same way across pages.

3.2.6 Consistent Help

Help options (like contact link, support widget) must appear in the same place across pages.

3.3.1 Error Identification

Errors and validation must be clearly identified and described in text, not just visually (like color or highlighting).

3.3.2 Labels or Instructions

Form fields must have clear labels or instructions to avoid confusion and help complete the input correctly.

3.3.3 Error Suggestion

Errors and validation messages must show text that explains the problem and gives suggestions for how to fix it (like “enter at least 8 characters”).

3.3.7 Redundant Entry

Don’t ask for the same information twice in the same process. Provide pre-filled fields or selection options if the information was already given.

3.3.8 Accessible Authentication (Minimum)

Authentication must not rely on memory alone. Allow copy-paste, password managers, or other options (like email verification).

4.1.2 Name, Role, Value

Interactive elements must have a clear name (what it is), the correct role (what it does), and any current value or state, so that assistive technologies can interpret and interact with them correctly.