Accessibility Review Checklist

What it is

An accessibility review checklist is a systematic assessment of whether your communications can be used by people with disabilities or different abilities—including people with vision impairments, hearing loss, motor limitations, cognitive differences, or older age-related changes. It covers everything from alt text for images to captions for videos to plain language alternatives to jargon.

Beyond being ethically important, accessibility is often a legal requirement under regulations like the UK Equality Act, GDPR, and WCAG guidelines. This template helps you meet those standards whilst making your communications better for everyone, not just people with disabilities. Clear, simple communication benefits all audiences.

When to use it

Use this template when:

• Creating communications for public or broad audiences
• Accessibility compliance is required (legal, regulatory, or organisational policy)
• Communications include images, videos, PDFs, or complex formats
• Content will be published digitally
• You want to ensure inclusive practice
• Reviewing for legal/compliance before approval
• Creating materials for diverse audiences

Don’t use this template if:

• Content is purely internal with no regulatory requirements
• You have no people with disabilities in your audience
• Accessibility is not a priority or requirement for your organisation
• Content is single-use, internal, and unlikely to be shared

Inputs needed

Before starting, gather:

• The content to review (all formats: text, images, videos, documents)
• Accessibility standards that apply (WCAG 2.1 Level AA is common standard)
• Your organisation’s accessibility policy or commitment
• Information about your audience accessibility needs
• Any known accessibility requirements from stakeholders
• Distribution channels (web, email, print, social, etc.)

---

The template

Accessibility review checklist

Content title: [Type and subject]

Format: [e.g., web page, PDF, email, video, document]

Reviewed by: [Name and date]

Applicable standard: [e.g., WCAG 2.1 Level AA, EN 301 549]

Visual accessibility

• Images have descriptive alt text – Each image has alt text that describes it meaningfully for people using screen readers. Alt text is concise but sufficient (not “image123.jpg” or blank).
• Colour is not the only way to convey information – If colour indicates importance (red=urgent, green=approved), there’s also text or symbols. Colour-blind people can understand.
• Contrast meets standards – Text contrast ratio is at least 4.5:1 for normal text, 3:1 for large text (WCAG AA standard). Check using contrast checker tool.
• Text is readable size – Body text is at least 16px. Text can be resized up to 200% without loss of functionality.
• Typography supports readability – Font choice and spacing are readable. Avoid all capitals, justified text, or very narrow columns. Use sans-serif fonts for digital content.
• Charts, diagrams, graphs have data tables – Complex visual information is available as accessible alternatives (tables, lists, descriptions) for people who can’t process images.
• Icons are explained – Decorative icons don’t need explanation, but functional icons (⚠️ warning, ✓ tick, → arrow) are explained or have text alternatives.

Textual accessibility

• Language is clear and simple – Jargon is minimised or defined. Sentence structure is straightforward. Avoid unnecessarily complex vocabulary. Aim for reading age 14-16 equivalent.
• Important information is up front – Key points appear first (inverted pyramid style). People using screen readers may not read entire document.
• Headings structure the content – Proper heading hierarchy (H1, H2, H3) is used consistently. Headings describe the section clearly. Screen readers rely on this structure.
• Acronyms are expanded – First use of acronym is spelled out (e.g., “World Health Organisation (WHO)”). People new to the field shouldn’t need external knowledge.
• Lists are formatted as actual lists – Bullet points and numbered lists use proper formatting, not just line breaks or dashes. Screen readers need correct markup.
• Important content isn’t only in images – Key information isn’t embedded in images of text. Always provide text alternative (not just alt text for images of text).

Audio and video accessibility

• Videos have captions/subtitles – Deaf and hard of hearing people can access. Captions include not just dialogue but relevant sounds ([door slams], [music playing], etc.).
• Audio has transcript – For podcasts, webinars, video content without video access. Transcript is readable text, properly formatted.
• Audio description provided – For videos with important visual information, audio description (separate audio track or descriptive captions) explains what’s happening.
• Automated captions reviewed – If using auto-captions, they’re checked for accuracy (auto-generated captions often miss technical terms, names, accents).

Document accessibility

• PDFs are tagged properly – Document uses proper structure tags (not just images of text). Generated from accessible source document, not scanned image.
• Fonts are embedded – Fonts work across devices/readers. Avoid decorative fonts that may not display correctly.
• Links are meaningful – Link text describes destination (not “click here” or “link”). Used with screen readers, link text needs context.
• Tables have headers – Data tables use proper header markup. Cells reference headers for context. Avoid nested tables.

Interactive and digital accessibility

• Forms are properly labelled – Each form field has visible, associated label. People can understand what each field requires.
• Forms are navigable by keyboard – Can fill form using tab and enter keys (not just mouse). Focus indicator shows where you are in form.
• Error messages are clear – When form validation fails, user knows which field has an error and how to fix it. Errors are announced to screen readers.
• Links and buttons are clearly defined – No “dummy” links (href=”#”). Buttons and links are keyboard accessible.
• Moving/animated content can be paused – Flashing, auto-playing, or moving content doesn’t create seizure risk (nothing flashing more than 3 times per second). Content can be paused by user.

Inclusive language

• No ableist language – Language doesn’t use disability as insult or negative metaphor (e.g., “blind to the issue,” “lame idea,” “deaf to concerns”). Language is respectful and person-first or identity-first as appropriate.
• Neurodiversity acknowledged – References to neurodiversity (ADHD, autism, dyslexia) aren’t pathologising or stigmatising. Respectful terminology used.
• Diverse representation implied or shown – Language and examples don’t assume everyone has same abilities/background. Inclusive pronouns used (they/them, not assuming she/he).
• Plain language used – Content is clear and understandable for people with cognitive differences, non-native speakers, or lower literacy levels.

Format and distribution accessibility

• Multiple formats available – Content isn’t available only as PDF. Text version, HTML version, or large-print version available where needed.
• Email accessible – Email doesn’t rely on images to convey meaning. Text wraps properly in all email clients. Links are meaningful (not “click here”).
• Web version responsive – On mobile devices, content is accessible (not just desktop). Text doesn’t require horizontal scrolling.
• Print accessible – If printed, content remains accessible (not just digital-native design).

Sign-off

• Content meets applicable accessibility standard ([Standard name])
• Accessibility issues resolved or documented with workaround
• Ready for publication/distribution
• Accessibility maintained in updates

---

AI prompt

Base prompt

I need to review this content for accessibility compliance. Please assess it against WCAG 2.1 Level AA standards (or specify your standard).

Content to review:
[Paste or describe the content]

Format(s): [e.g., web page, PDF, email, video]

Audience: [Who will be using this? Note any known accessibility needs]

Areas of concern: [If you know specific accessibility issues, mention them]

Create an accessibility review that:
1. Assesses visual elements (alt text, colour contrast, images, charts)
2. Reviews text for clarity and structure (headings, lists, jargon, complexity)
3. Checks audio/video for captions, transcripts, audio description
4. Evaluates interactive elements (forms, links, buttons, keyboard navigation)
5. Reviews inclusive language (ableist terms, respectful terminology)
6. Checks document structure (if PDF or document)
7. Lists specific issues and how to fix them
8. Rates overall accessibility (compliant, mostly compliant, non-compliant)

Be specific about failures. Instead of "alt text needs work," show what's missing from specific images. Include what compliance level each issue affects.

Prompt variations

Variation 1 - WCAG compliance audit:

We need to audit [CONTENT] against WCAG 2.1 Level [AA/AAA] standards. Create a detailed accessibility review that:
- Lists each WCAG criterion that applies to this content
- Assesses whether we meet, fail, or partially meet each criterion
- Provides evidence for your assessment (specific images, form fields, etc.)
- Rates severity of failures (critical/major/minor)
- Estimates effort to fix each issue (quick fix/moderate effort/significant rebuild)
- Prioritises fixes (do critical issues first)

Variation 2 - Disability-specific access:

I want to ensure this content is accessible to people with:
- Visual impairment (blindness, low vision)
- Hearing loss (deafness, hard of hearing)
- Motor limitations (limited mobility, tremors)
- Cognitive differences (ADHD, autism, dyslexia, dyscalculia)
- Older age-related changes (vision, hearing, dexterity decline)

Content: [Paste]

For each disability category, assess what barriers exist in this content and how to remove them.

Variation 3 - Video accessibility:

We've created a video and need to make it fully accessible. Here's what it contains:
[Describe key scenes, dialogue, sound effects, any text on screen, music, important visual information]

Create an accessibility checklist for:
- What captions should say (dialogue + sound descriptions)
- Audio description script for visual-only information
- Transcript format and content
- Any other accessibility considerations

Variation 4 - Plain language review:

Part of accessibility is using clear, simple language. Please review this content for:
- Complexity level (reading age equivalent)
- Jargon that needs explaining
- Sentence length and structure
- Technical terms without definitions
- Whether someone unfamiliar with our field could understand it
- Ableist language or problematic terminology

Content: [Paste]

Provide suggestions for plain language alternatives.

Variation 5 - Inclusive language audit:

I want to ensure our communications use respectful, inclusive language. Please review this content for:
- Ableist language or disability used as metaphor
- Gendered language (assuming pronouns)
- Terms that could be offensive or outdated
- Assumptions about audience (abilities, background, family structure, etc.)
- How we refer to neurodiversity (autism, ADHD, dyslexia, etc.)
- Any stereotyping or tokenism in representation

Content: [Paste]

Flag specific phrases and suggest alternatives.

---

Human review checklist

• Has visual accessibility been assessed (alt text, colour contrast, images, charts)?
• Has text clarity been reviewed (headings, lists, jargon, reading level)?
• Have audio and video elements been checked for captions, transcripts, audio description?
• Have interactive elements been tested for keyboard navigation and form accessibility?
• Has inclusive language been reviewed (ableist terms, respectful terminology)?
• Are specific failures identified with location/examples, not just general comments?
• Have fixes been prioritised (critical accessibility barriers first)?
• Is the overall compliance level clear (meets standard, doesn’t meet standard)?
• Are format-specific issues addressed (web vs PDF vs email vs print)?
• Would someone with a disability be able to use this content fully?

---

Example output

Content: Product FAQ page

Format: Web page, HTML

Standard: WCAG 2.1 Level AA

Reviewed: 30 January 2026

---

Assessment Summary:

Overall compliance: Partially compliant – Critical issues must be fixed before publication.

Critical issues (blocks accessibility):

1. FAQ items aren’t structured with proper headings – screen readers can’t navigate the page
2. Product images missing alt text – people using screen readers can’t see what products look like
3. “Important notice” is conveyed only through red text – colour-blind people don’t see it

Major issues (significantly limits access):

1. Form field labels aren’t associated with inputs – screen reader users can’t understand what each field is
2. Focus indicator invisible on keyboard navigation – can’t see where you are when tabbing
3. FAQ search function doesn’t work with keyboard alone

Minor issues (reduces usability):

1. Some headings could be clearer (“Details” vs “Shipping Details”)
2. One image caption is vague for screen reader users
3. Links need more descriptive text (“Learn more” → “Learn more about shipping options”)

---

Specific fixes needed:

Critical – Alt text for product images:

• Current: Images have no alt text
• Fix: Add descriptive alt text to all product images. Example: “Blue waterproof jacket, chest-zip design, shown in size M” (not “image1.jpg” or blank)
• Effort: Low (10 images × 1 minute each)

Critical – Page structure with headings:

• Current: FAQ items aren’t marked as headings in HTML; just styled as headings visually
• Fix: Use proper <h2> tags for each FAQ question. Use <h3> for sub-sections if any
• Effort: Low (proper HTML markup of existing content)
• Impact: Screen reader users can navigate page by headings; massively improves usability

Critical – Red text warning:

• Current: “Important: Ships within 24 hours” is only marked red for emphasis
• Fix: Add icon or text indicator that doesn’t rely on colour. Example: “⚠️ Important: Ships within 24 hours” or add bold text
• Effort: Low (add icon or text modifier)
• Impact: Colour-blind users can now see what’s important

Major – Form labels:

• Current: Search field has no visible label associated with it
• Fix: Add <label> tag associated with search input: <label for="search">Search FAQs:</label>
• Effort: Low (HTML fix, improves accessibility, improves usability for everyone)

Major – Focus indicator:

• Current: When tabbing through page, focus indicator is invisible (hard to see where you are)
• Fix: Add CSS focus styling: button:focus { outline: 2px solid blue; } (or branded colour, must have 3:1 contrast minimum)
• Effort: Very low (CSS update)
• Impact: Keyboard navigators can see where they are in the page

---

Inclusive language review:

• Use “people with disabilities” not “the disabled” (identity vs label)
• No ableist language found (“blind spot,” “deaf to concerns”)
• Examples assume diverse user groups; no stereotyping found

Recommendations for enhancement (not required for AA compliance):

• Consider plain language review (some FAQ answers could be simpler)
• Add keyboard shortcut hints (help keyboard users navigate faster)
• Consider expandable FAQ sections for mobile (better experience on small screens)

---

Related templates

• Tone Style Checker – Inclusive language affects tone appropriateness
• Approval Workflow Mapper – Include accessibility review in approval process
• Content Approval Tracker – Track accessibility review status

---

Tips for success

Use automated tools for baseline checking. Tools like WAVE, Lighthouse, or NVDA screen reader can identify obvious issues (missing alt text, colour contrast problems, structural issues). Use them as a starting point, not final verification.

Test with actual assistive technology. Automated checking misses real usability issues. If possible, test with screen readers, keyboard navigation, speech recognition. Real user testing is invaluable.

Plain language benefits everyone. Accessibility isn’t separate from good communication. Clear, simple language helps people with cognitive differences, non-native speakers, people on mobile, and people reading quickly. It’s not a compromise—it’s better.

Make captions comprehensive. Don’t just caption dialogue. Describe important sounds, silences, and visual information. “[Door slams]” or “[phone ringing]” help deaf viewers understand what’s happening. Captions should be complete enough someone could understand without sound.

Don’t assume disabilities. Not all people with vision loss are completely blind. Not all people with hearing loss prefer sign language. Ask your users about their needs. Accessibility isn’t one-size-fits-all.

---

Common pitfalls

Assuming accessibility is “add-on.” Retrofitting accessibility onto inaccessible content is hard. Building it in from the start is easier and cheaper. Don’t create content then try to make it accessible afterward.

Only checking alt text and captions. Yes, those matter, but accessibility is broader. If your page structure is broken, captions won’t help. If your language is too complex, clear alt text won’t fix understanding. Check everything.

Using poor colour contrast thinking it looks better. Light grey text on white doesn’t look better—it just fails accessibility. Good design includes sufficient contrast. Accessible design is better design.

Forgetting about keyboard users. Some users can’t use a mouse (due to motor limitations, tremors, or preference). Everything that works with a mouse should work with keyboard alone (tab, enter, arrow keys). Test your whole site with keyboard navigation.

Setting alt text to blank for decorative images, then forgetting which are decorative. Some “decorative” images are actually informative. Think carefully. A photo of a product is informative. A spacer image is decorative. Err on the side of including information if you’re unsure.

---