Back to blog
Industries16 min read

20 AI Prompts for Accessible, Plain-Language Copy

20 plain language AI prompts for auditing, rewriting, and verifying accessible copy — plus the WCAG checks a prompt alone can't pass.

NH
Nafiul Hasan
Founder, Prompt Architects

TL;DR: These 20 plain language AI prompts cover the real arc: auditing copy against WCAG's actual reading-level and non-text criteria, rewriting jargon for a named audience instead of a vague "simpler" target, drafting alt text a human still has to check, and verifying the rewrite didn't drop a fact. Plain wording is one input to accessibility, not the whole job.

Plain language work sits in a good spot: readers benefit immediately, and clean copy tends to help with search and AI-answer visibility as a side effect. But "make this simpler" is not one prompt — it's several different jobs, and none of them is the same job as passing an accessibility audit. What follows is 20 copy-paste prompts split across auditing, rewriting, describing non-text content, and verifying the result, plus the standards a prompt genuinely cannot satisfy on its own.

What actually counts as "plain language," and is it the same as accessible?

Plain language has an actual definition, not just a vibe. The International Plain Language Federation, one of the three founding bodies behind the ISO standard, states it directly: "A communication is in plain language if its wording, structure, and design are so clear that the intended readers can easily find what they need, understand what they find, and use that information" (iplfederation.org/plain-language, accessed September 3, 2026). That definition became the basis of ISO 24495-1, the first international plain-language standard. As the Federation's own page puts it, "ISO published Part 1 of its plain language standard in 2023." It covers general principles and guidelines, and the Federation says it applies across languages and sectors.

Notice what's absent from that definition: no grade level, no maximum sentence length, nothing about screen readers or color. Plain language is about wording, structure, and design working together so a reader can use the content. Accessibility, as WCAG defines it, is a much wider net that also covers non-text alternatives, color contrast, keyboard operability, captions, and semantic structure. Plain wording is one slice of that net.

Which standards define plain language and accessibility, and at what level?

Three different documents get cited under the umbrella of "make this accessible," and they aren't interchangeable.

StandardWhat it governsLevel / status
WCAG 2.2, SC 3.1.5 Reading LevelA supplemental plain-language version when text needs more than a lower-secondary reading levelAAA
WCAG 2.2, SC 1.1.1 Non-text ContentA text alternative for images, icons, and interactive controlsA
WCAG 2.2, SC 1.4.3 Contrast (Minimum)Color contrast between text and its backgroundAA
ISO 24495-1:2023Wording, structure, and design principles for plain languageInternational standard, not a legal mandate on its own
US Plain Writing Act of 2010Federal agencies must write public-facing content for their specific audienceUS federal law

WCAG 2.2 is the current W3C recommendation, published on 5 October 2023 with an update on 12 December 2024 (w3.org/WAI/standards-guidelines/wcag, accessed September 3, 2026), and it groups every success criterion into one of three conformance levels: A, AA, or AAA. SC 3.1.5 Reading Level sits at the top tier:

That level matters. AAA is the strictest of WCAG's three tiers, not AA, and the W3C is direct about the whole tier: "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content" (w3.org/WAI/WCAG22/Understanding/conformance, accessed September 3, 2026). Most legal accessibility mandates, including ADA Title II, Section 508, and the EU's EN 301 549, are pegged to Level AA. SC 3.1.5 is genuinely good practice worth building into a prompt. It is not a checkbox most sites are legally required to tick.

Which readability formula should your prompts target?

"Grade 8" is not one number. It's shorthand for whichever formula produced it, and the two most common formulas count different things.

FormulaWhat it countsRough methodCommon use
Flesch-Kincaid Grade LevelAverage words per sentence, average syllables per word0.39 × (words ÷ sentences) + 11.8 × (syllables ÷ words) − 15.59Built into most web readability tools; developed for the U.S. Navy in 1975 by J. Peter Kincaid
SMOGWords of 3 or more syllables across a 30-sentence sample1.0430 × √(polysyllabic words × 30 ÷ sentences) + 3.1291Health literacy and patient-facing materials; published by G. Harry McLaughlin in 1969

Both formulas measure sentence and word mechanics, not whether a real reader actually understood the content. That gap is exactly why plain-language guidance pushes back against one universal target. As the U.S. government's plain-language guidance puts it: "One of the most common plain language myths is that you have to “dumb down” your content so that everyone can read it. That’s not true." The same guidance is specific about what knowing your audience means in practice: "Don’t write for an 8th-grade class if your readers are PhD candidates, small business owners, or working parents. Only write for 8th graders if your audience is, in fact, an 8th-grade class" (digital.gov/guides/plain-language/principles, accessed September 3, 2026, content adapted from plainlanguage.gov). Every prompt below asks you to name the actual reader instead of reaching for a fixed grade number, for exactly that reason.

5 prompts to audit copy before you touch a word

Audit first. Rewriting before you know what's actually wrong tends to fix the sentence you noticed and miss the three you didn't.

1. Reading-level triage (approximate, not a certified score)

Paste the copy below and estimate its approximate reading level using the Flesch-Kincaid Grade
Level method (average sentence length + syllables per word).
Copy: [paste paragraph]
Report: (1) your rough estimate, labeled "approximate, not a verified formula score" (2) the three
longest sentences (3) every word a first-time reader in [describe actual audience] might not know.
Do not rewrite anything yet — audit only.

2. Jargon and acronym audit

List every acronym, internal term, and industry jargon word in this text that a first-time reader
outside [your field/industry] would not recognize: [paste text].
For each one, give a plain-language definition short enough to insert inline (under 12 words) —
do not suggest a glossary link; the definition has to survive inside the sentence itself.

3. Passive voice and hidden-verb audit

Scan this text for two patterns: passive voice ("was completed by," "is required to be") and
hidden verbs — a verb turned into a noun, like "conduct an analysis" instead of "analyze".
Text: [paste text]
List each instance with its line, then the direct, active version of the same sentence. Don't
rewrite the full document — just the flagged sentences.

4. One-idea-per-sentence audit

Find every sentence in this text longer than 25 words or containing more than one idea joined by
"and," "which," or a semicolon: [paste text].
For each one, show how it splits into two shorter sentences without losing any fact, number, or
qualifier from the original.

5. WCAG 3.1.5 gap-check

Review this text for sections that likely require reading ability more advanced than a
lower-secondary-education level to follow (dense clauses, multi-part sentences, specialized
vocabulary): [paste text].
For each flagged section, don't rewrite it — instead draft a short supplemental summary in plain
language that could sit alongside the original as an alternate version, the way WCAG's own
guidance for this criterion allows.

How do you rewrite jargon without losing what it actually says?

Once the audit tells you where the actual problems are, the rewrite prompts below fix one pattern at a time instead of asking a model to "make this whole page simpler" in one pass, which tends to smooth over real distinctions along with the jargon.

6. Grade-level rewrite, audience-specified, facts protected

Rewrite this for [describe your actual reader, e.g., "new customers with no industry background"
or "returning users who already know our product"] — not a generic "simpler" reading level.
Text: [paste text]
Keep every number, date, name, and specific claim exactly as stated. Cut nothing that changes what
the text actually says. If a term genuinely has no simpler substitute, keep it and define it once
inline instead of removing it.

7. Active-voice pass

Rewrite this text in active voice — the subject of each sentence should be the one doing the
action, not the one being acted on: [paste text].
Flag any sentence where passive voice was actually necessary (for example, when the actor is
unknown or irrelevant) instead of forcing an active version that reads worse.

Digital.gov's own writing guidance explains why this pass matters more than it looks: "Active voice makes it clear who should do what. It eliminates ambiguity about responsibilities." (digital.gov/guides/plain-language/writing, accessed September 3, 2026, content adapted from plainlanguage.gov).

8. Hidden-verb (nominalization) pass

Find every nominalization in this text — a verb converted into a noun, usually ending in -tion,
-ment, -sion, or -ance (e.g., "make a decision" instead of "decide"): [paste text].
Rewrite each flagged sentence using the direct verb form. Leave every other sentence untouched.

The same guidance defines the pattern this prompt targets: "A hidden verb (or nominalization) is a verb converted into a noun. It often needs an extra verb to make sense." (digital.gov/guides/plain-language/writing, accessed September 3, 2026).

9. Inline-definition rewrite

This paragraph uses [term] without defining it: [paste paragraph].
Insert a plain-language definition of [term] directly where it first appears, in a clause of 10
words or fewer, rather than a footnote or glossary link. Keep the rest of the paragraph unchanged.

10. Wall-of-text to scannable structure

Restructure this into scannable form without cutting any fact: [paste dense paragraph].
Break it into: a one-sentence topic statement, then either short paragraphs (2-3 sentences each)
or a numbered/bulleted list if the content is a sequence or a set of options.
Do not summarize or shorten the actual content — only its structure changes.

How do you draft alt text an AI can't verify by itself?

Non-text content is where this topic stops being about sentences at all. WCAG's SC 1.1.1 sets the actual bar: "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below" (Level A, w3.org/WAI/WCAG22/quickref, accessed September 3, 2026). The phrase doing the real work is "serves the equivalent purpose," which is a higher bar than simply describing what's visually in the picture.

11. Purpose-first alt text draft

Draft alt text for this image: [describe the image and, critically, what it's FOR on the page —
e.g., "a screenshot showing the export button's location, used to help a user find that button"].
Describe the purpose the image serves on the page, not just what's visually in it. Keep it under
125 characters. Flag if you don't have enough context about the image's purpose to write this
accurately — don't guess.

12. Decorative-vs-informative triage

Here is a list of images on this page and what each one is for: [paste list, one line per image
with its purpose or "purely visual/decorative" noted].
Sort them into two groups: images that need real descriptive alt text, and images that are pure
decoration and should get an empty alt attribute so assistive technology can ignore them.
For the first group, draft the alt text. For the second, just confirm the "decorative" call.

SC 1.1.1's own decorative exception is exactly this: "If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology" (w3.org/WAI/WCAG22/quickref, accessed September 3, 2026).

13. Chart and data-viz description

Here is the underlying data for a chart on this page: [paste the data table or key values].
Write a text description a screen-reader user could read instead of seeing the chart: state the
trend, the highest and lowest points, and any value a sighted reader would notice at a glance.
Do not just describe the chart type ("a bar chart showing...") — describe what it shows.

14. Accessible control and button labels

Here are the button/link labels on this page: [paste list, e.g., "Click here", "Learn more",
"Submit"].
Rewrite each one so its label alone describes what it does, without relying on the surrounding
sentence for context (a screen-reader user often hears the label in isolation).
Flag any label that's ambiguous even with context.

SC 1.1.1 covers this case directly too: "If non-text content is a control or accepts user input, then it has a name that describes its purpose" (w3.org/WAI/WCAG22/quickref, accessed September 3, 2026).

15. Plain-language supplemental summary

Here is a complex passage I don't want to rewrite or shorten: [paste passage].
Write a separate, standalone plain-language summary of it (not a replacement) that someone could
read on its own and understand the same key point, without needing the original passage's full
detail.
Label it clearly as a summary, not a substitute for the source.

What plain-language prompts cannot fix

A prompt operates entirely inside the text. Contrast is a design property, semantic structure is a markup property, and keyboard operability is an interaction property. Simplifying a paragraph does not touch any of the three, no matter how good the rewrite is. If a project's accessibility plan stops at "we ran it through an AI prompt," it has covered the wording and left the rest of WCAG untouched.

How do you verify a rewrite actually got easier to read?

Verification catches what a confident-sounding draft hides: a dropped fact, an over-simplified explanation, or a reading-level estimate the model made up on the spot.

16. Self-estimate with an honesty clause

Estimate this text's approximate reading level using the SMOG method (count words of 3+ syllables
across the sample, weight by sentence count): [paste text].
State your estimate as "approximate — not a certified SMOG score," name any simplifying assumption
you made, and recommend running the text through an actual readability checker before relying on
this number for anything official (legal, medical, or government content).

17. Before/after fact-preservation check

Original: [paste original text]
Simplified version: [paste your rewrite]
List every number, date, name, and specific claim in the original. Confirm whether each one still
appears, unchanged, in the simplified version. Flag anything dropped, softened, or altered — don't
just compare tone or length.

18. Human-and-tool handoff checklist

Based on this rewritten copy: [paste your simplified draft], list every accessibility item this
text pass CANNOT verify on its own: color contrast, heading order and semantic structure, alt text
accuracy against the actual image, keyboard focus order, and anything else that depends on the
page's code or design rather than its wording.
Output this as a checklist for a human or an automated accessibility scanner to run separately.

19. Audience-mismatch check

Original audience for this content: [describe, e.g., "specialists who already know the domain"].
Simplified draft: [paste your rewrite].
Check whether the simplification removed information this specific audience actually needs, or
added explanations they'd find condescending. Flag both directions — oversimplified AND
under-simplified — rather than assuming simpler is always better for this reader.

20. Final pre-publish pass

Here is my final draft: [paste draft]. Target reader: [describe them specifically].
Run three checks in order: (1) any sentence still requiring more than a lower-secondary reading
level to follow, per WCAG's reading-level guidance, (2) any remaining jargon without an inline
definition, (3) a plain list of what's NOT covered by this pass — contrast, alt text accuracy,
heading structure, and anything else that needs a human or accessibility tool before this ships.

How this fits your prompt library

These 20 prompts are the wording layer of an accessibility project, not the whole project. Save the ones you'll actually reuse (the audience-specified rewrite in #6 and the human-handoff checklist in #18 are worth keeping closest at hand) as variables so you're not retyping the same "who is this actually for" context every time. If prompt engineering itself is new territory, our beginner's guide covers the fundamentals, and our guide to building a personal AI prompt library covers the setup. Pair both with our brand-voice context guide so simplified copy still sounds like your brand rather than a compliance checklist. For adjacent copy work, see our landing page prompt collection, and run the prompt hygiene checklist before anything ships.

Free Chrome Extension

Stop rewriting prompts. Start shipping.

Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.

Create An Account

None of these prompts certify a page as accessible. They get the wording most of the way there, point at exactly what still needs a human, a screen reader, or an actual contrast checker, and stop short of pretending a rewrite is the whole job.


By Nafiul Hasan — Founder of Prompt Architects.

Frequently asked questions

Free Chrome Extension

Stop rewriting prompts. Start shipping.

Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.

Create An Account