Accessibility and Inclusive Content

Accessible Content Review

Review content structure, language, links, media alternatives, instructions, and interaction guidance for barriers that can prevent people from completing a task.

Free editable Markdown · Accessibility specialists, editors, and content designers · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Review context

Page, asset, and version: [Enter]
Primary user task: [Describe]
Review owner and date: [Name, YYYY-MM-DD]
Content and interaction scope: [List]
Devices and viewports: [List]
Assistive technology and browser tested: [Record exact combinations]
Known limitations of this review: [Describe]
People with relevant lived expertise involved: [Role/process or Not available]

Structure and language

Page title and H1 describe the content's purpose.
Heading levels form a meaningful hierarchy without skipped meaning.
Reading and focus order preserve the intended sequence.
Lists and tables are used for real relationships, not visual layout.
Instructions avoid relying only on color, shape, sound, or position.
Sentences, terms, abbreviations, and labels suit the reader and task.
Important conditions, risks, and choices are not hidden in dense text.
Link text communicates its destination or action out of context.

Images, audio, video, and data

Media inventory: [List each item and purpose]

Informative images have concise context-appropriate alternatives.
Decorative images can be ignored by assistive technology.
Functional images have alternatives that identify the action.
Complex charts include their conclusion, relevant values, and source in accessible form.
Prerecorded speech has accurate captions and an appropriate transcript.
Important visual-only information is described where the task requires it.
Flashing, autoplay, motion, and time behavior were escalated for technical review.

Forms, instructions, and errors

Keyboard and focus result: [Record]
Zoom, reflow, and text-spacing result: [Record]

Labels, requirements, examples, and formats are available before input.
Placeholder text is not the only label or instruction.
Errors identify the affected field, explain the problem, and offer recovery.
Status and success messages are communicated without relying on visual change alone.
Time limits, fees, consequences, and irreversible actions are clear in advance.
Help and contact alternatives are discoverable.

Issue and verification log

Duplicate for each barrier.

Issue ID and location: [Enter]
Barrier observed: [Describe]
People or tasks affected: [Describe without assumptions]
Severity: [Blocking / Serious / Moderate / Minor]
Owner type: [Content / Design / Code / Media / Product]
Required correction: [Describe expected outcome]
Fixed version: [Enter]
Verification method and tester: [Record]
Status: [Open / Fixed / Accepted risk with owner]

Signoff

Blocking issues remaining: [List or None]
Technical accessibility review: [Owner/status]
Content reviewer decision: [Approve / Return / Conditional]
Final tested version and date: [Enter]
Residual limitations: [State accurately]
Next review trigger: [Component change, new media, research, scheduled date]

How to use this template

Define the page task, user contexts, technologies, and scope of the content review.
Inspect headings, order, language, links, media alternatives, and non-visual meaning.
Complete key actions using keyboard, zoom, reflow, and relevant assistive technology.
Log each barrier with affected users, severity, owner, correction, and verification method.
Retest the fixed rendered version and record residual risks without claiming certification.

Review whether structure communicates meaning

Start with the content's task and read the heading outline without the body. Headings should identify sections and levels, not merely create large text. Check that lists, tables, quotations, and emphasis represent their real relationships and remain understandable when visual styling is unavailable. Put necessary instructions before the field, control, or action they govern. Avoid communicating a required state only through color, position, shape, or sensory language such as “click the green box on the right.” A clear source order benefits keyboard and screen-reader users, people using magnification, small screens, reading modes, or translation tools.

Make text and media alternatives purposeful

Use familiar, direct language, define necessary terms, expand uncommon abbreviations, and keep labels consistent. Link text should identify its destination or action when read outside the surrounding paragraph. For images, decide whether the purpose is informative, functional, complex, or decorative; alternative text should provide the equivalent information needed in that context, not repeat the caption or describe every visible detail. Videos may need synchronized captions, transcripts, speaker identification, and descriptions of important visual information. Charts need the conclusion, relevant data, and source available in text or an accessible data format.

Inspect instructions, errors, and completion paths

Accessibility often fails at moments of action. Verify that requirements, input formats, time limits, fees, consequences, and needed documents appear before submission. Labels and examples should remain visible or programmatically available, and errors should identify the problem and explain recovery without blame. Test keyboard navigation, focus visibility, zoom, reflow, text spacing, and screen-reader announcements with the implemented interface; these are not established by copy alone. Include people with disabilities in research and review, compensate expertise appropriately, and log issues by user impact. Escalate code or design defects to their owners instead of trying to solve every barrier with extra wording.

See the fields in context

Fictional example: newsletter signup form

RiverPost is an invented newsletter. The findings below illustrate issue documentation, not a conformance assessment.

Barrier: The fictional email field uses placeholder text as its only label, and the error says only “Invalid.”
Affected task: A screen-reader or memory-limited user may lose the field purpose and cannot tell which format will work.
Correction: Add a persistent “Email address” label and an error that identifies the field and gives an example format.
Verification: Retest keyboard focus and announcement in the named preview version using the recorded browser and screen reader.
Signoff: Keep the issue open until the implemented form, not a design image, passes the defined check.

Frequently asked questions

Does this checklist prove that a page conforms to an accessibility standard?

No. It supports a content review. Complete evaluation may require technical testing, applicable standards, representative tasks, and qualified human judgment.

How should alt text be written?

Describe the information or function the image contributes in its context. Decorative images generally should not create redundant announcements.

Is plain language an accessibility requirement for every reader?

Clear language reduces many barriers, but readers and tasks differ. Preserve precise meaning, structure information well, and test comprehension with relevant people.

Can automated tools complete the review?

They can detect some patterns, but they cannot judge most context, purpose, meaning, usability, or the quality of alternatives. Combine automation with manual and human testing.