Accessible Communications Checklist

Accessible Communications Checklist Resource type: Tier 1 Flagship — Accessibility Library home: L09 Accessibility & Plain Language Library Companion to: WCAG 2.2 AA Flagship Module; Plain-Language Style Guide for DSD; Accessible Meetings Checklist; Effective Communication for People with Communication Disabilities Standards reference: WCAG 2.2 AA; §508 Rehabilitation Act; Title II ADA; Minnesota Human Rights Act (MHRA) What this is A checklist for accessible communications across all DSD channels — email, DSD web pages, social media, video, audio, and imagery. This resource covers the accessibility requirements specific to each channel and the cross-cutting practices that apply everywhere. It is organized by channel for ease of use. Why this matters for DSD Communications are how DSD reaches staff, clients, community partners, and the public. When communications are not accessible: • Staff and clients with visual disabilities cannot access visual-only content • People who are deaf or hard of hearing cannot access audio or video content without captions • People with cognitive disabilities are excluded by dense, jargon-heavy communications • People with motor disabilities who use keyboard-only navigation cannot interact with inaccessible web forms, links, or social media • People with low vision cannot read low-contrast text on social media graphics or email templates The DOJ's 2024 Title II ADA Final Rule extends accessibility requirements to websites, mobile apps, social media posts, and other digital content. DSD's Resolution 26 requires WCAG 2.2 AA compliance for all digital content. Channel 1: Email Accessibility Email is DSD's primary internal communication channel and a key channel for client and partner communication. Checklist: Accessible Email Structure and format: • [ ] Use a clear, specific subject line that tells the reader what the email is about and what action (if any) is required ("Action required: Submit your updated service plan by October 15") • [ ] Put the most important information first — use the inverted pyramid (conclusion first, detail second) • [ ] Use short paragraphs (3–5 sentences) • [ ] Use bullet lists for three or more items • [ ] Use plain language — grade 8 reading level for broad audiences • [ ] Use a readable, sans-serif font (Arial, Calibri, Verdana) at 11–12pt minimum • [ ] Avoid decorative or background images in email templates Links: • [ ] All hyperlinks use descriptive text — not "click here," not raw URLs • [ ] Hyperlink text describes the destination or action ("Download the accessible meeting guide," "View the DSD event calendar") Images and graphics: • [ ] All images in emails have alt text • [ ] Decorative images are marked as decorative (blank alt text in HTML: alt="") • [ ] Do not send critical information as an image only — if you include a text image (poster, flyer), also include the same information as plain text in the email body Color and contrast: • [ ] Text has sufficient contrast against the email background (4.5:1 for normal text) • [ ] Color is not used as the only indicator of importance or status • [ ] Do not use colored text as the only way to highlight important information — use bold, bullets, or a clear statement Attachments: • [ ] All attachments are in accessible formats (accessible Word or accessible tagged PDF — not scanned PDFs) • [ ] Attachment names are descriptive ("DSD_WCAG_Checklist_2025.pdf" is better than "Checklist.pdf" or "Final_v3_FINAL.pdf") Common errors: • Sending a flyer or announcement only as an image, with no plain-text equivalent — the image is invisible to screen readers • Using red text as the only way to mark urgent content — colorblind users miss it • Attaching scanned PDFs — inaccessible to all assistive technology Channel 2: DSD Web Pages DSD maintains web pages for program information, resources, and public communications. All DSD web content must meet WCAG 2.2 AA. Checklist: Accessible Web Pages Structure: • [ ] Every page has a unique, descriptive page title (visible in browser tab) • [ ] Content is organized with heading hierarchy (H1 for page title, H2 for major sections, H3 for subsections) • [ ] Skip-to-main-content link at the top of every page (allows keyboard users to bypass navigation) • [ ] Consistent navigation in the same location across all pages Text and content: • [ ] Plain language — grade 8 reading level for public-facing pages • [ ] All acronyms defined on first use • [ ] All link text is descriptive and makes sense out of context • [ ] No "click here" or raw URL link text • [ ] All language changes (from English to another language) marked in HTML (lang attribute) Images and media: • [ ] All images have alt text • [ ] Decorative images have empty alt text (alt="") • [ ] All videos have closed captions • [ ] Pre-recorded videos have audio description if visual content is not conveyed in the narration • [ ] Audio-only content has a text transcript Color and contrast: • [ ] Normal text: 4.5:1 contrast ratio minimum • [ ] Large text (18pt+ or 14pt+ bold): 3:1 minimum • [ ] UI components (buttons, form fields, icons): 3:1 minimum • [ ] Color not used as the only indicator Forms: • [ ] All form fields have visible, descriptive labels • [ ] Error messages identify the field with the error and explain how to fix it • [ ] Required fields identified with text (not only with a color or asterisk — include "required" in text) • [ ] Forms can be completed by keyboard only • [ ] No timed form sessions without warning and extension option Focus and keyboard navigation: • [ ] All interactive elements reachable by keyboard (Tab key) • [ ] Focus indicator is visible on all interactive elements • [ ] No keyboard traps (Tab can always escape any interactive component) • [ ] Focused element is not hidden by sticky headers or footers (WCAG 2.4.11) • [ ] Logical tab order follows visual layout Touch targets: • [ ] Interactive elements are at least 24×24 CSS pixels (WCAG 2.5.8); aim for 44×44px • [ ] Sufficient spacing between touch targets to prevent mis-taps Common errors: • PDFs linked from web pages that are not accessible — all linked documents must meet accessibility standards • Forms that time out without warning — a user with a disability may need more time to complete a form • Icons without labels — a user cannot understand an icon-only button with a screen reader unless it has a text label or aria-label Channel 3: Social Media Accessibility DSD's social media presence reaches the public, community partners, and the broader DSD service community. Social media posts must be accessible. Checklist: Accessible Social Media Images and graphics: • [ ] All images posted on social media include alt text (most platforms support this natively) • [ ] Text-heavy graphics (announcements, event information, quotes) include the same text in the post caption, so screen reader users get the content even if the image alt text is insufficient • [ ] Infographics include a link to the same information in plain-text format (web page, document) Adding alt text on common platforms: • Twitter/X: Click the "Add description" option on uploaded images before posting • Facebook/Meta: Tap the edit icon on images; select "Alt text" and type description • LinkedIn: Alt text is added after upload in the edit menu • Instagram: Go to "Advanced settings" before posting; tap "Write alt text" Video: • [ ] All videos posted on social media have closed captions • [ ] Auto-generated captions are reviewed and corrected for accuracy before posting • [ ] Videos that rely on visual content for meaning include audio description or text description in the post Hashtags: • [ ] Hashtags use CamelCase (capitalize the first letter of each word): #AccessibilityMatters, not #accessibilitymatters — screen readers read CamelCase hashtags as distinct words rather than a string of merged letters • [ ] Limit the number of hashtags per post — multiple consecutive hashtags at the end of a post are disruptive to screen reader users Emoji: • [ ] Use emoji sparingly — screen readers read each emoji's full name ("sparkles," "red heart," "party popper") • [ ] Do not use emoji to replace words or as the only indicator of meaning • [ ] Do not stack multiple emoji in a row — each is read aloud Text in posts: • [ ] Plain language — clear, concise, grade 8 or lower • [ ] All links are embedded with descriptive text where the platform allows • [ ] Avoid ALL CAPS — screen readers read ALL CAPS letter by letter in some configurations Common errors: • Posting a graphic with event information (date, time, location, RSVP) without including that information in the text of the post — the graphic is invisible to screen readers • Using hashtags in all lowercase (#disabilityawareness) — screen readers read this as one word • Auto-posting video without reviewing captions for accuracy Channel 4: Video Captioning All video content DSD produces, commissions, or distributes must be captioned. Checklist: Accessible Video Closed captions (required): • [ ] All prerecorded video has closed captions • [ ] Captions are accurate (not only auto-generated without review) • [ ] Captions identify speakers when there are multiple speakers ("[Name]:") or use separate captions per speaker • [ ] Captions include relevant sound effects ("[phone rings]," "[applause]") • [ ] Captions are synchronized with audio • [ ] Caption text is readable (sufficient contrast, adequate font size — WCAG recommends minimum 22px caption text in video) Auto-caption review process: 1. Generate auto-captions in your platform (Teams, Zoom, YouTube, etc.) 2. Download the caption file (SRT or VTT format) 3. Review for accuracy — correct names, technical terms, acronyms, and Hmong/Somali/Spanish/Karen/Oromo terms that auto-captioning struggles with 4. Upload the corrected caption file before publishing Open captions vs. closed captions: • Closed captions can be toggled on/off by the viewer — preferred for most uses • Open captions are burned into the video and always visible — useful for social media where auto-captioning is unreliable or when you cannot guarantee the viewer will enable captions Audio description (when needed): • [ ] If the video relies on visual content not described in the narration (on-screen text, diagrams, demonstrations), add audio description • [ ] Audio description is a narration track that describes visual content during natural pauses in the audio • [ ] Contact the DSD Equity Team for guidance on commissioning audio descriptions Transcripts: • [ ] Provide a text transcript for all prerecorded video — particularly for screen reader users and Braille display users who may prefer reading to watching • [ ] Transcript includes all spoken words, speaker identifications, and descriptions of relevant audio and visual content Live video: • [ ] All live-streamed meetings and events use live captioning (Teams or Zoom live captions, or CART) • [ ] Live captions are clearly visible and have sufficient contrast • [ ] Sign language interpreter visible and in an accessible format for live events Channel 5: Audio Content DSD may produce podcasts, audio recordings of meetings, or audio-only training materials. Checklist: Accessible Audio • [ ] All audio content has a text transcript • [ ] Transcript is in an accessible document format (not a scanned PDF) • [ ] Transcript is published alongside the audio on the same page or in the same communication • [ ] Audio has no background music that competes with speech for listeners using hearing aids or cochlear implants • [ ] Volume is consistent — no sudden loud segments • [ ] Speakers identify themselves at the start of audio ("This is [Name]") Channel 6: Accessible Imagery Images used in all DSD communications must be inclusive and have meaningful alt text. Checklist: Accessible Imagery Alt text: • [ ] All informational images have meaningful alt text • [ ] Alt text describes what is in the image and why it is relevant — not just "person" or "group photo" • [ ] Decorative images have empty alt text Representation: • [ ] Images of people reflect the diversity of DSD's staff and client community — including people with visible disabilities • [ ] Avoid stock photos that portray disability in a stereotypical, pitying, or sensationalized way • [ ] Center dignity — people in images are portrayed as whole, active, and capable • [ ] For images of specific people: obtain consent; do not use images of clients who have not consented to appear in DSD communications Alt text for diverse representation images: • Describe the activity, context, or setting relevant to the communication — not personal characteristics unless they are directly relevant • Do not describe race, disability, or other personal characteristics unless that is the point of the image Cross-Cutting Practices for All Communications Regardless of channel, every DSD communication must: 1. Use plain language — grade 8 reading level for client-facing content 2. Not rely on color alone — add text, pattern, or symbol alongside any color coding 3. Meet contrast requirements — 4.5:1 for normal text, 3:1 for large text and UI elements 4. Include alt text for images — concise and meaningful 5. Caption all audio and video — not just the important parts 6. Use descriptive link text — no "click here" 7. Provide multiple ways to access information — link from email to web page; include plain text version alongside graphics 8. Test before publishing — run the Accessibility Checker; check contrast; test keyboard navigation on web content Where to Get Help • Section508.gov — Creating Accessible Communications: https://www.section508.gov/create/ • WebAIM — Email Accessibility: https://webaim.org/techniques/email/ • WebAIM — Social Media Accessibility: https://webaim.org/ • W3C WAI — Video Captions Tutorial: https://www.w3.org/WAI/media/av/captions/ • Colour Contrast Analyser: https://www.tpgi.com/color-contrast-checker/ • One DSD Equity Team: Accessibility review and consultation Connection to DSD's Six Program Goals DSD Program Goal — Accessible Communications Connection Equity and inclusion — Communications that exclude people with disabilities contradict DSD's equity mission Cultural and linguistic competence — Multilingual communities need accessible formats across all languages Olmstead implementation — Community integration depends on accessible information reaching people in accessible forms Workforce development — Internal communications must be accessible for staff with disabilities Quality improvement — Accessible communications reduce confusion, callbacks, and service errors Leadership and accountability — Leaders ensure all team communications meet accessibility standards before publishing Sources • Web Content Accessibility Guidelines 2.2, W3C, December 2024: https://www.w3.org/TR/WCAG22/ • DOJ ADA Title Two Web Accessibility Final Rule, April 2024: https://www.ada.gov/resources/2024-03-08-web-rule/ • Section508.gov — Creating Accessible Documents and Content: https://www.section508.gov/create/ • W3C WAI — Making Audio and Video Media Accessible: https://www.w3.org/WAI/media/av/ • WebAIM — Email Accessibility: https://webaim.org/techniques/email/ • Microsoft — Accessible Social Media: https://www.microsoft.com/en-us/accessibility • Twitter/X Accessibility: https://help.twitter.com/en/using-twitter/picture-descriptions Accessibility is everyone's responsibility. When in doubt, ask people with disabilities what works for them.