How to Write for Web Accessibility

Writing accessibly isn’t a separate writing style — it’s the practice of writing clearly enough that screen-reader users, low-vision readers, users with cognitive or learning disabilities, and anyone reading on a tiny screen in a hurry can all get to the information they need. The legal frame is real, too: the U.S. DOJ’s April 2024 Title II rule (with the April 2026 Interim Final Rule extending compliance to April 26, 2027 for jurisdictions of 50,000+ and April 26, 2028 for smaller ones), the European Accessibility Act (enforcement since June 28, 2025), and Canada’s Accessible Canada Act all reference WCAG 2.1 or 2.2 Level AA as the technical baseline.

Write unique, descriptive page titles

Every page needs a short title that describes the content and distinguishes it from every other page on the site. WCAG 2.2 Success Criterion 2.4.2 Page Titled (A) requires it; 2.4.6 Headings and Labels (AA) reinforces that titles and labels must describe topic or purpose.

• Lead with the most specific information. “Reset Your Password — Acme Bank” beats “Acme Bank — Reset Your Password.” Search results, tabs, and screen readers all surface the title first; the leading words do the navigation.
• Don’t reuse the same title across multiple pages. “Home,” “Untitled Document,” or the bare site name fail this rule.
• If the page is one step in a flow, name the step: “Step 2 of 4: Shipping Address.” That gives users with cognitive disabilities and screen-reader users an instant location cue.

Page titles are usually rendered as the <title> element and as the H1 on the page itself — the writer often controls one, the CMS controls the other. Treat them as a pair: when you write a new title, write the H1 to match.

Use headings to convey meaning and structure

Screen-reader users navigate by heading. JAWS, NVDA, and VoiceOver all let users press a single key (“H” in JAWS/NVDA, the rotor in VoiceOver) to jump from heading to heading, just like a sighted reader scans bolded section titles. Bad heading structure breaks that navigation entirely.

Three rules from WCAG 2.2:

• 1.3.1 Info and Relationships (A): structure that’s conveyed visually must also be conveyed in code. A line styled to look like a heading isn’t a heading unless it’s marked up as one.
• 2.4.6 Headings and Labels (AA): headings describe topic or purpose.
• 2.4.10 Section Headings (AAA): long content uses section headings to organize it. Treat this as a baseline, not an aspirational extra.

Practical guidance for writers:

• One H1 per page, then nest H2 → H3 → H4 in logical order. Don’t skip levels for visual styling — restyle the heading rather than picking the level by size.
• Headings should make sense out of context. “The next section” or “More info” fail when read in a screen-reader heading list; “Refund policy for digital goods” works.
• Front-load keywords and concrete nouns. “Submit a claim” is more useful than “What to do if something goes wrong with your order.”
• If you can read the H2s in order and reconstruct the article’s argument, the heading structure is doing its job.

Write meaningful link text

“Click here” and “Read more” are the canonical examples of inaccessible link text. Screen-reader users often pull up a list of every link on a page; out of context, “Click here” tells them nothing. WCAG 2.4.4 Link Purpose (In Context) (A) requires that a link’s purpose be determinable from the link text plus its immediate context. 2.4.9 Link Purpose (Link Only) (AAA) raises the bar: the link text alone must explain where it goes.

Apply this every time:

• Link the words that describe the destination. “Read the 2026 accessibility report” beats “Read the report by clicking here.”
• Don’t use the same link text for two different destinations. “Learn more” appearing six times on a page, each going somewhere different, is a trap.
• For non-HTML targets, signal the format and size: “Download the 2026 buyer’s guide (PDF, 2.4 MB).”
• Avoid bare URLs in body copy. https://example.com/blog/long-slug-here is unreadable when announced character by character.

Write alt text that conveys the same information as the image

WCAG 1.1.1 Non-text Content (A) requires every meaningful image to have a text alternative that serves the same purpose. The writing rules:

• Functional images (icons that act as buttons or links): describe the action, not the picture. A magnifying-glass icon that opens search gets alt="Search", not alt="magnifying glass".
• Informative images (charts, diagrams, photos used to convey content): describe the information the image carries, in one or two sentences. For a sales chart, write the takeaway: “Q1 2026 revenue, up 18% over Q4 2025, driven by enterprise renewals.”
• Decorative images (visuals that add atmosphere but no information): use empty alt — alt="" — so screen readers skip them. Don’t fill the field with “image of” or the file name.
• Complex images (infographics, detailed diagrams): use a short alt plus a longer description nearby in the body copy or via aria-describedby.

Two writer’s tests: read the alt text aloud in place of the image — does the sentence still make sense? And: don’t start with “Image of” or “Picture of.” Screen readers already announce that an image is present.

Provide captions, transcripts, and audio descriptions for media

Multimedia is governed by a cluster of criteria that all require text equivalents:

• 1.2.1 Audio-only and Video-only (Prerecorded) (A): a transcript for podcasts and audio-only content; a transcript or audio description for silent video.
• 1.2.2 Captions (Prerecorded) (A): synchronized captions for prerecorded video with audio.
• 1.2.3 Audio Description or Media Alternative (A): either an audio description track or a full text alternative.
• 1.2.4 Captions (Live) (AA): live captions for live video.
• 1.2.5 Audio Description (Prerecorded) (AA): an audio description track for prerecorded video.

What writers actually deliver:

• Captions include dialogue plus speaker identification (“[Sam:] We shipped Tuesday.”) plus non-speech sounds important to comprehension (“[door slams]”). They’re not just transcripts pasted onto the screen.
• Transcripts for audio-only content are full text versions, with speaker labels and significant non-speech sounds noted.
• Audio descriptions are scripts read in pauses in the dialogue that describe key visual information — a character’s expression, an on-screen graphic, a setting change.

Caption tooling has improved enormously: YouTube’s auto-captions, Otter.ai, Rev, 3Play Media, and Descript all produce solid first drafts. Auto-captions still need a human review pass for proper nouns, technical terms, and homophones — and a quick read-through for the kind of error that turns a brand name into a slur. Always review before publishing.

Write clear, specific instructions and error messages

Forms are where unclear writing causes real harm. The relevant criteria:

• 3.3.1 Error Identification (A): when an error is detected, identify it in text and describe it to the user.
• 3.3.2 Labels or Instructions (A): labels or instructions are provided when content requires user input.
• 3.3.3 Error Suggestion (AA): if an error is detected and suggestions for correction are known, provide them — unless doing so would compromise security or the form’s purpose.

For writers, that means:

• Tell users what format you want. “Date (MM/DD/YYYY)” beats “Date.” “Phone (10 digits, no dashes)” beats “Phone.”
• Make labels specific. “Email address” beats “Email.” “Mobile phone” beats “Phone” on a form that already has a separate work-phone field.
• Write error messages that say what to do. “Email is required” tells the user the field is empty; “Enter your email address (e.g., name@example.com) to continue” tells them what success looks like.
• Don’t hide instructions in placeholder text. Placeholders disappear on input, fail contrast more often than not, and aren’t reliably announced by assistive tech. Use a visible label or helper text instead.

Write in plain language

WCAG 3.1.5 Reading Level (AAA) is the explicit rule, calling for content readable at a lower-secondary education level (roughly U.S. grades 7-9) when supplemental content is required. Even at AA, plain language is the default expectation and aligns with the U.S. Plain Writing Act of 2010, which still governs federal communications.

Plain-language techniques that move the needle:

• Short sentences. Aim for 15-20 words on average. Mix shorter and longer for rhythm; avoid stringing together same-length declaratives.
• Short paragraphs. Two to four sentences. White space is a comprehension aid, not a styling choice.
• Common words. Use “help” instead of “facilitate,” “use” instead of “utilize,” “before” instead of “prior to.”
• Active voice and second person. “You can update your password” beats “Passwords may be updated by users.”
• Spell out acronyms on first use, followed by the abbreviation in parentheses: “Web Content Accessibility Guidelines (WCAG).”
• Define technical terms inline when omission would lose meaning. For longer pieces, add a glossary.
• Lists for parallel content. If a sentence contains three commas separating parallel items, it’s usually a list waiting to happen.

Tools that help writers ship accessibly

Modern editing tools have caught up with accessibility expectations:

• Hemingway Editor flags long sentences, passive voice, and reading-grade level.
• Readable (readable.com) calculates Flesch-Kincaid, SMOG, and other readability scores against a target grade.
• Microsoft Word’s Editor and Google Docs’ suggestions include readability and clarity checks; Word also exposes Flesch-Kincaid grade level under File → Info → Check for Issues → Document Stats.
• Grammarly includes a clarity score and flags wordy or unclear constructions.
• WAVE (wave.webaim.org) and axe DevTools catch many text-related issues — missing alt text, empty links, missing form labels — once content is on the page.
• YouTube Studio, Otter.ai, Rev, 3Play Media, and Descript handle captions and transcripts.
• Plainlanguage.gov remains the best free reference for plain-language writing technique, particularly for public-sector content.

Frequently asked questions

What reading level should I write to?

For general public web content, target U.S. grade 8-9 — broadly accessible, still allows nuance. WCAG 3.1.5 (AAA) calls for lower-secondary level for supplemental material; the U.S. Plain Writing Act applies grade 8 to federal communications. Use Hemingway, Readable, or Word’s built-in stats to spot-check.

Do I really need a transcript if I have captions?

For prerecorded audio-only content (podcasts), yes — captions don’t apply because there’s no video. For prerecorded video, captions satisfy WCAG 1.2.2 at Level A. Transcripts aren’t strictly required at AA but are widely expected for podcasts and recommended for video because they’re searchable, indexable, and easier to skim.

What’s the difference between captions and subtitles?

Captions are written for users who can’t hear the audio — they include speaker IDs, sound effects, and music cues. Subtitles assume the user can hear the audio but doesn’t understand the language — they’re translation-only. Use captions for accessibility; subtitles are localization.

Is using AI to draft alt text or captions OK?

As a starting point, yes — modern image-description models and speech-to-text systems produce usable first drafts. Always review: AI alt text often misses context (it can describe what’s in the image but not why it’s in the article), and auto-captions still mangle proper nouns and technical terminology. Treat AI output as a draft, not a deliverable.

Does this apply to social-media copy too?

Yes, and most major platforms now support accessibility features writers should use: alt text on images (Twitter/X, Bluesky, Instagram, LinkedIn, Facebook), captions on video (built-in or via the platform’s caption editor), and CamelCase for hashtags (#WebAccessibility, not #webaccessibility) so screen readers parse the words correctly.

The bottom line

Most accessibility wins for writers are stylistic habits that also make content better for everyone: descriptive titles, clear headings, meaningful link text, useful alt text, captions and transcripts, helpful instructions, and plain language. WCAG 2.2 maps each of those to a specific success criterion, and the tooling — Hemingway, Otter, Stark, WAVE — is good enough now that none of these are heavy lifts. Bake the rules above into your style guide and your editorial review checklist, and the next post you ship will be measurably more accessible than the last one.