Writing Accessible Content
Accessible content starts before a single line of code is written. Good writing, structure, and intentional choices make content usable for everyone.
Plain Language Principles
Plain language makes content usable for people with cognitive disabilities, non-native speakers, people under stress, and frankly — everyone. WCAG 2.2 SC 3.1.5 recommends supplemental content for reading levels above lower secondary education.
Headings & Structure
Headings are the primary navigation tool for screen reader users. 71% of screen reader users navigate by headings first when arriving at a new page (WebAIM Screen Reader Survey).
Use headings hierarchically. Start with a single H1 for the page title. Use H2 for major sections, H3 for subsections. Never skip heading levels (H1 to H3 with no H2).
Make headings descriptive. "Section 1" tells a screen reader user nothing. "Refund Policy" tells them exactly what's there — and whether they need to read it.
Don't use headings for styling. If something just needs to look bigger or bolder, use CSS. Headings convey document structure — using them decoratively breaks navigation for screen reader users.
Writing for Screen Readers
Screen readers announce content in a linear order, reading through the DOM from top to bottom. Write content that works in that context:
- Avoid relying on spatial phrases like "the form on the right" or "see below" — these are meaningless in audio
- Expand abbreviations and acronyms on first use, or use the
<abbr>element with a title attribute - Avoid using all-caps for emphasis — screen readers may spell out the letters or read in a strange way; use CSS instead
- Don't use ASCII art, emoticons inline with text, or special characters as decorative separators
- Emojis are read aloud by screen readers using their descriptive names — use sparingly and intentionally
- Avoid using tables for layout — use semantic tables only for tabular data
Alt Text Best Practices
Alt text (WCAG 2.2 SC 1.1.1) is the most frequently audited accessibility requirement. Writing it well is an art — here are the rules:
Describe the purpose, not just the appearance
Bad: "photo of a woman." Good: "Sarah Chen, CEO of A11y Consultants, speaking at the 2025 Accessibility Summit." Describe what matters in context.
Don't start with "Image of..." or "Picture of..."
Screen readers already announce the element type. Starting with "image of" is redundant and wastes the user's time.
Decorative images get empty alt attributes
If an image is purely decorative, use alt="". Screen readers will skip it. Do not omit the alt attribute entirely — that causes screen readers to announce the file name.
Charts and infographics need full descriptions
A bar chart's alt text should summarize the key finding, not describe each bar. "Sales grew 40% from 2024 to 2025, with Q4 being the strongest quarter." Provide the full data table for complex charts.
Functional images describe their action
A logo that links to the homepage gets alt="A11y Consultants — Home" (or similar). A search icon button gets alt="Search". The alt text describes the action the image triggers.
Link Text
Screen reader users often navigate by jumping between links on a page. Links must be descriptive enough to make sense out of context (WCAG 2.2 SC 2.4.4).
Avoid
- Click here
- Read more
- Learn more
- Download
- www.example.com/page?id=42
Better
- Download the 2025 Accessibility Report (PDF)
- Read our WCAG 2.2 checklist
- Learn more about our audit services
- View Sarah Chen's biography
- ADA Compliance Guide
When a link opens a new tab or window, indicate it in the link text or with a visually hidden label: "WCAG 2.2 specification (opens in new tab)". Also use target="_blank" rel="noopener".
Tables
Use tables only for tabular data — never for layout. Accessible tables require proper semantic markup:
- Use
<th>elements for header cells with the appropriatescopeattribute (scope="col"orscope="row") - Add a
<caption>element to describe the table's purpose - For complex tables with multi-level headers, use
idandheadersattributes to associate data cells with their headers - Avoid merged cells where possible — they complicate screen reader navigation significantly
- Ensure tables are responsive — allow horizontal scrolling on small screens rather than breaking layout
Forms & Labels
Forms are where most accessibility failures happen. Clear labels and good error handling are essential (WCAG 2.2 SC 3.3.1, 3.3.2).
Always use visible labels associated with inputs using <label for="...">. Never rely on placeholder text alone — placeholders disappear when users start typing.
Mark required fields both visually (asterisk is fine if explained) and with the required attribute or aria-required="true".
Write helpful error messages. "Invalid input" is useless. "Please enter a valid email address (example: [email protected])" tells the user exactly what to fix.
Don't use color alone to indicate errors. Red text must also be accompanied by an icon, error message text, or other non-color indicator.
Readability Tips
Left-align body text
Centered and justified text is harder to read for people with dyslexia. Use left alignment for all body copy.
Use sufficient line height
Aim for 1.5× the font size for body text. Dense paragraphs are harder to scan and read.
Limit line length
45–75 characters per line is optimal. Very wide text columns are difficult to track, especially for users with cognitive disabilities.
Break up dense text
Use bullet points, numbered lists, and short paragraphs. Long unbroken blocks of text are hard for everyone.
Use sufficient font size
A minimum of 16px for body text is recommended. Never use CSS to prevent text resizing.
Avoid jargon
Technical terms should be explained on first use. If you must use acronyms, spell them out the first time.
Want Content Accessibility Training?
We offer workshops for content teams on writing accessible copy, headings, alt text, and more. Custom training for your CMS and workflow.
Inquire About Training