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. Roughly seven in ten screen reader users report navigating 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: "A speaker demonstrating screen-reader navigation to a conference audience." Describe what the image is doing on the page, not merely what is in the frame.
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 annual accessibility report (PDF, 1.2 MB)
- Read our WCAG 2.2 checklist
- Learn more about our audit services
- View the speaker’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.
Primary sources
Standards and regulations change. Verify anything you plan to rely on against the source itself.
This guide is technical information, not legal advice.
It describes accessibility standards and how to test against them. Whether a specific obligation
applies to your organization, and how to answer any regulatory filing, is a question for your counsel.
No consultant can certify legal compliance or guarantee that an organization will avoid a complaint,
claim, or enforcement action.
Last reviewed August 31, 2026.
Want your content team trained on this?
Half-day and full-day workshops for content authors, covering headings, link text, alt text, and plain language, built around your CMS and your actual publishing workflow.
Ask about content training