Content & Editorial Accessibility Checklist

Accessibility checks for writers, editors, and content designers. Plain language, link text, image alt, inclusive language, and UX writing — the content-side decisions that affect who can read, understand, and act on your page.

Interactive Content

0 of 25 items complete

Plain Language & Reading Level

Content matches your audience's reading level For general audiences, aim for Grade 8 or below. Tools like Hemingway Editor give a live grade. (SC 3.1.5 Reading Level, AAA)
Jargon, acronyms, and technical terms are defined on first use Spell out acronyms the first time: "Web Content Accessibility Guidelines (WCAG)." Link to definitions where possible. (SC 3.1.3, 3.1.4)
Sentences are short and direct Aim for 15–20 words per sentence on average. Break compound sentences into two. One idea per sentence.
Active voice is the default "The team shipped the feature" not "The feature was shipped by the team." Passive voice only when the actor is unknown or irrelevant.
Idioms, metaphors, and cultural references are explained or avoided "Hit it out of the park" doesn't translate. Neither do regional references. Write for a global audience by default. (SC 3.1.3 Unusual Words)

Headings & Page Structure

Exactly one H1 per page and it describes the page The H1 should tell a screen reader user what the page is about in one line. Semantic HTML guide
Heading levels don't skip H2 → H3, never H2 → H4. Skipping levels breaks the page outline that screen reader users rely on. (SC 1.3.1)
Headings describe the section, not its position "What to pack" beats "Section 2." Screen reader users listen to a heading list to navigate — vague headings make that list useless. (SC 2.4.6)
Long pages include a table of contents or on-page nav Any page over ~1,500 words benefits from jump links. Sighted and screen reader users both use them to scan.

Links & Calls to Action

Link text describes the destination Avoid "click here," "read more," and "learn more." Use "Read the accessibility guide" instead. Screen reader users often navigate by link list. (SC 2.4.4, 2.4.9)
Links that open new windows, downloads, or external sites are labeled Include the format and size: "Download report (PDF, 2.3 MB)" or "View site (opens in new window)." Surprises are accessibility failures.
Links with the same text go to the same destination If two links both say "Learn more" but go to different pages, screen reader users can't tell them apart. Make the text specific. (SC 3.2.4)
CTAs use specific action verbs "Download the annual report" beats "Submit." "Start your free trial" beats "Go." Tell users what happens when they click.

Images & Media

Informative images have descriptive alt text Alt text conveys the same information a sighted user gets. Not "image of chart" — describe what the chart shows. (SC 1.1.1) Alt Text guide
Decorative images use alt="" or CSS backgrounds Hero swirls, pattern dividers, and purely visual flourishes should not be announced. Never omit the alt attribute — use empty alt="" explicitly.
Functional images describe the action, not the image A magnifying glass icon inside a search button is alt="Search", not alt="Magnifying glass." The alt becomes the button's accessible name.
Videos have synchronized captions Pre-recorded video needs captions covering speech, speaker identification, and meaningful sounds. Auto-captions aren't enough without review. (SC 1.2.2)
Videos and audio have text transcripts Transcripts serve Deaf users, users on slow connections, and anyone who prefers reading. Also boost SEO — search engines can't watch video. (SC 1.2.1)

Inclusive Language

Language about disability follows the relevant community's preference Person-first ("person with a disability") vs. identity-first ("Deaf person," "autistic person") — preferences differ. When in doubt, ask the community or mirror how they describe themselves.
Gender-neutral language is used unless gender is essential Singular "they" for an unknown person. "Chair" instead of "chairman." "Staff" instead of "manpower." "Folks" or "everyone" instead of "guys."
No ableist metaphors or culturally exclusionary idioms Avoid "crazy," "insane," "tone-deaf," "lame," "crippling," "blind spot." Swap for precise words — "surprising," "unreasonable," "major," "limitation."

Content Design & UX Writing

Error messages explain what went wrong and how to fix it "Invalid input" is useless. "Enter a valid email address, like name@example.com" is actionable. (SC 3.3.3) Forms pattern
Form labels are persistent and describe what's needed Visible labels that don't disappear when the user types. Placeholder text alone is not a label — it fails screen readers and short-term memory. (SC 3.3.2)
Empty states explain what users will see and how to populate it "No messages yet" alone doesn't help. Add "Start a conversation by tapping the + button." Empty states are onboarding opportunities.
Dates, times, currencies, and numbers are localized and readable "2026-04-18" is unambiguous; "04/18/26" is not. Spell out months for multi-region audiences. Use the user's locale where possible. Include currency symbols and units.

Frequently asked questions

Who runs this checklist — designer, developer, or writer?

Content writers and copy editors. The items are about word choices and content structure that affect accessibility — link text quality, heading clarity, plain-language summaries, abbreviation handling. Designers and developers can spot issues, but the fixes live in the copy.

What's the minimum reading level I should target?

WCAG 3.1.5 (Level AAA) suggests lower-secondary education level for content not focused on the experts in the field. Use tools like Hemingway, Readable.io, or Microsoft Word's Flesch-Kincaid score. AA-level WCAG doesn't require a specific reading level, but plain-language writing is one of the highest-leverage accessibility decisions.

How should I handle abbreviations and jargon?

Expand on first use: "Web Content Accessibility Guidelines (WCAG) ...". For domain-specific terms, link to a glossary or definition. The <abbr title="..."> element provides a tooltip but isn't reliably announced by screen readers, so prefer in-text expansion.

What about emoji and Unicode symbols in text?

Use sparingly and only where they add meaning. Screen readers announce them verbosely ("☑️" becomes "ballot box with check"). Don't substitute emoji for words ("Tap 📞 to call" — bad; "Tap the phone icon to call" — good). Decorative emoji can be hidden with aria-hidden="true" on a wrapping span.

How long should headings be?

Short enough to be scannable in a screen reader's heading list (under ~10 words is a good target). Descriptive enough to communicate what the section is about without context. "Why this matters" is fine; "Why this matters: a deep look at the operational reasons behind..." is too long.

Does content accessibility affect SEO?

Yes — heavily. Search engines use the same signals as screen readers (heading hierarchy, alt text, link text, page title) to understand content. Writing accessible content is writing SEO-friendly content. The two practices reinforce each other.