InHouse Inclusive

Writing Inclusive and Understandable Web Content

Introduction: Good writing is at the heart of accessibility. Clear, concise, and inclusive language helps all readers, especially those with cognitive or learning disabilitieslibrary.harvard.edu. Using active voice, defining terms, and avoiding jargon or idioms reduces confusion. Harvard’s guidelines stress that “plain language and well-organized writing benefits all users, but especially those with cognitive disabilities such as dyslexia and ADHD”library.harvard.edu. Similarly, MDN’s accessibility training advises using “simple plain language, steering clear of slang and abbreviations… and providing definitions where it is not possible”developer.mozilla.org.

Learning Objectives:

  • Use plain language principles (short sentences, common words, active voice).
  • Apply inclusive writing: use person-first language (“people with disabilities”) and respect (avoid “victim” wording, don’t talk down).
  • Avoid discriminatory or ableist terms (e.g. say “person uses a wheelchair” not “wheelchair-bound”).
  • Define acronyms on first use, and explain complex terms (WCAG 2.2 AAA encourages simpler versions for difficult textw3.org).
  • Structure content with bullets or lists to aid scanning and comprehension.

Related Topics:

  • Inclusive content style guides (ableist language, cultural sensitivity).
  • WCAG 3.1 (Readable content, acronyms, alternatives).
  • Plain-language guidelines (e.g. PlainLanguage.gov).
  • Assistive tech limitations (e.g. text-to-speech struggles with slang).

Examples (Inaccessible vs Accessible):

  • Jargon/Complexity: “Please commence utilization of the hyperlink below for additional elucidation.” vs. “Click this link to learn more.” (Accessible uses simple verb “click” and common words).
  • Tone: “Users must log in to access the portal.” vs. “To access the portal, please log in here.” (Accessible is more polite/neutral and direct).
  • Inclusive Language: “The blind cannot see our interface.” vs. “A blind person may need descriptive text or an audio cue.” (Use person-first and factual language).
  • Acronyms: “You must follow SOPs (Standard Operating Procedures).” vs. “You must follow the Standard Operating Procedures (SOPs).” (Accessible expands the acronym on first mention).

WCAG Guidance: While WCAG 2.2 doesn’t require specific reading levels at AA, it does have AAA criteria (3.1.4 Abbreviations and 3.1.5 Reading Level) that encourage clear writing and explanationsw3.org. For AA compliance, use consistent terminology (SC 3.2.4) and ensure instructions don’t rely solely on complex language or senses (SC 3.2.5 Change on Request). The core idea is under Guideline 3.3 and 3.1: make content understandable.

Tips & Checklist:

  • Checklist: Include items like “No more than one idea per sentence” or “Acronyms defined.” Yale’s content-editor checklist or simple checklists (e.g. number of words per sentence) can be handyusability.yale.edu.
  • Templates: Provide a “style sheet” template with examples of inclusive phrasing. For instance, a library example suggests “Use the word accommodations, not special treatment” when discussing disability serviceslibrary.harvard.edu.
  • Review: Have multiple eyes review content (especially for bias). Consider a plain-language review (checklist at PlainLanguage.gov). Harvard even links to a checklist for plain languagelibrary.harvard.edu.
  • Resources: Use readability tools (Flesch scores) and inclusive language checkers. Many organizations have glossaries (e.g. APA Inclusive Language guidelines).

Downloadable Resources: A Writing Accessibility Checklist (e.g. do’s and don’ts list) and sample text file showing poor vs. improved writing can help editors practice. Templates (like a Word doc with built-in heading styles and writing tips in comments) can enforce structure and clarity from the start.