Table of contents12
The first time I listened to my own website through a screen reader — software that reads web pages aloud for people who are blind or have low vision — I lasted ninety seconds before I turned it off. It wasn’t broken. It was just… exhausting. “Click here. Click here. Image. Image. Click here.” My links all said “click here.” My images had no descriptions. My headings were a random scatter of sizes I’d picked for how they looked. I’d written a site for eyes and never once considered ears.
I’m Fatima Noor, and I write content for WordPress sites. That ninety seconds changed how I write everything. A screen reader doesn’t see your layout, your colors, or your beautiful typography. It hears a linear stream of words — headings, links, image descriptions, form labels — in the order your code presents them. Writing for that stream isn’t a separate skill. It’s just writing well, with structure.
This guide teaches you exactly how to write WordPress content that works beautifully when heard: headings that form a real outline, alt text that describes with purpose, links that make sense out of context, and plain-language habits that help every reader, not just screen reader users. If you publish anything on WordPress — posts, pages, product descriptions — this is for you. Let’s write for ears.
The objection I expect: “But hardly anyone uses a screen reader, right?” More people than you think — and here’s the part that should convince you anyway. Everything in this guide also helps sighted readers: clearer headings, better link text, shorter paragraphs, descriptive image text. Search engines, which also “read” your page without seeing it, reward the same structure. Writing screen reader friendly content isn’t a niche accommodation. It’s just better writing, verified by the strictest reader you’ll ever have.
Here’s what this guide covers:
- How a Screen Reader Actually Experiences Your Page
- Rule 1: One H1, Then Headings in Order, Never Skipped
- Rule 2: Write Alt Text With Purpose (and Skip It When There’s None)
- Rule 3: Links Must Make Sense Out of Context
- Rule 4: Structure With Lists, Not Fake Formatting
- Rule 5: Write in Plain Language and Short Paragraphs
- Rule 6: Tables Need Real Headers
- Rule 7: Punctuation Is Pronunciation
- The WordPress-Specific Habits That Matter
- Your Pre-Publish Screen Reader Checklist
- Frequently Asked Questions
- Final Thoughts
Ready? Let’s get started.
How a Screen Reader Actually Experiences Your Page
Here’s the deal: you need to understand the experience before the rules make sense. A screen reader user doesn’t “look at” your page. They navigate it — and the navigation is nothing like scrolling.
The first thing announced when a page loads is the page title — the <title> element, which in WordPress comes from your page/post title plus site name. Then the user typically pulls up a list of all headings and jumps between them, the way you’d scan a table of contents. Or they tab through links — hearing just the link text, out of context. Or they navigate by landmarks: the header, navigation, main content, and footer regions of the page.
Everything is linear and announced. The screen reader says “heading level 2” before each H2. It says “link” before each link. It says “graphic” before each image, then reads the alt text — or, if there’s no alt text, it may read the file name (“IMG_4829-final-v2.jpg”), which is as unhelpful as it sounds. Decorative images marked properly are skipped in silence, which is exactly right.
Two popular screen readers to know: NVDA, free on Windows, and VoiceOver, built into every Mac and iPhone. They’re what your visitors actually use, and they’re what you should test with. The experience differs slightly between them — JAWS, another popular one, even announces “graphic link” for linked images — but the content rules that satisfy all of them are the same. That’s what this guide teaches.
Bonus Tip: The single most illuminating thing you can do this week: turn on your screen reader (NVDA is free; Mac users press Cmd+F5 for VoiceOver), close your eyes, and listen to your homepage for two minutes. You’ll hear every “click here,” every undescribed image, every structural mess — instantly. It’s humbling and it’s the best writing teacher I know.
Rule 1: One H1, Then Headings in Order, Never Skipped
Screen reader users navigate by headings more than by any other method. Your headings are their map — and most WordPress sites hand them a broken one.
The rules are simple and absolute. One H1 per page. In WordPress, that’s your post or page title — the theme outputs it as the H1 automatically, so don’t add another one in your content. Then H2 for your main sections, H3 for subsections, H4 if you go deeper — in order, never skipping a level. An H2 followed directly by an H4 tells the listener a level is missing, like a building with no third floor.
And here’s the mistake I see everywhere: using headings for appearance. Someone wants big bold text, so they make it a heading. Someone wants a subtle section label, so they bold a paragraph instead of using a heading. Both break the map. Headings are structure, not styling. If the text introduces a new section or topic, it’s a heading at the correct level. If it’s emphasis inside a paragraph, it’s bold text. The block editor makes this easy — use Heading blocks for headings, and the font-size controls for visual sizing.
Write headings that work as a standalone outline. A screen reader user often reads just the heading list to decide what to read fully. “Our Services” tells them nothing; “Web Design Services for Small Businesses” tells them everything. Front-load the meaning: put the important words first, because some users navigate by first letters.
In WordPress specifically: check that your theme outputs a proper H1 for the page title (most do), never add a second H1 in your content, and use the Heading block — not bolded paragraphs — for every section title. The complete guide to the WordPress block editor covers heading blocks in detail if you want a refresher. I once fixed a 40-page site’s headings in an afternoon, and the client’s blind tester called it the single biggest improvement we’d made. Structure is everything.
Rule 2: Write Alt Text With Purpose (and Skip It When There’s None)
Alt text — alternative text — is the description a screen reader reads in place of an image. It’s also what appears if the image fails to load and what search engines use to understand the picture. Writing good alt text is pure writing skill, no code involved, and it’s one of the highest-value things in this guide.
The core principle: describe the purpose, not just the appearance. Ask what the image is doing on the page, then describe that. A team photo on your About page isn’t there to document “five people standing in an office” — it’s there to introduce the team. Good alt text: “Our five-person support team smiling in the Lisbon office.” Bad alt text: “Image of people.” (Never start with “image of” or “picture of” — the screen reader already announces that it’s a graphic.)
Keep it to one sentence, ideally under about 125 characters — some screen readers truncate longer descriptions. Don’t repeat nearby text: if the caption says it, the alt text shouldn’t say it again. For images that contain text — a sale banner, an infographic headline — include that text in the alt text, because it’s information the listener would otherwise miss entirely.
For complex images like charts, summarize the key insight: “Bar chart showing sales doubled from 2024 to 2025.” If the details matter, link to a full text description of the data nearby. The listener needs the takeaway, not a cell-by-cell recitation.
And the equally important flip side: decorative images get empty alt text (alt=""). Dividers, background flourishes, stock photos that add no information — mark them empty and screen readers skip them in blessed silence. Announcing “decorative swirl graphic” helps nobody. In WordPress, you set this in the image block settings or the media library; leaving the alt field empty on a decorative image is a deliberate, correct choice — not laziness.
One more WordPress trap: linked images. When an image is a link, its alt text becomes the link text. A logo linking to your homepage shouldn’t say “Company logo” — it should say “Home,” because that’s where the link goes. Think destination, not depiction.
Rule 3: Links Must Make Sense Out of Context
Screen reader users often navigate by pulling up a list of all links on the page — just the link text, no surrounding sentences. Now imagine that list from your site: “click here,” “read more,” “click here,” “learn more,” “here.” It’s a menu with no dish names. Useless.
Descriptive link text is the fix, and the rule is simple: the link text alone should tell the user where the link goes or what it does. Not “click here to read our accessibility guide” — just “read our accessibility guide.” Not “click here” — “download the 2026 pricing PDF.” The words “click here” add nothing; screen reader users aren’t necessarily clicking, and sighted users can see it’s a link.
This also means link text shouldn’t be unnecessarily long — a whole sentence as a link is tedious to hear — and links close together shouldn’t all start with the same words, because navigating by first letter becomes useless. Vary the openings: “Download the report,” “Read the methodology,” “See pricing.”
In WordPress, this mostly means breaking the “Read More” habit. Archive pages and blog listings love “Read More” links — make them descriptive instead: “Read more about accessible forms” or use the post title as the link. It helps screen reader users, and it helps your SEO too, because search engines also read link text without full context.
Note: Avoid wrapping links in extra punctuation like brackets or parentheses in your visible text — some screen readers announce the punctuation, adding noise. And never use a bare URL as link text (“https://example.com/page…”) unless you have no choice; hearing a URL spelled out is miserable. Link the descriptive words instead.
Rule 4: Structure With Lists, Not Fake Formatting
Lists are a screen reader superpower. When content is marked up as a real list, the screen reader announces “list, 5 items” and the user can jump between items, skip the whole list, or hear their position (“item 3 of 5”). It’s structured, navigable, efficient.
When you fake a list — separate paragraphs with dashes, or line breaks with bullet characters typed by hand — the listener gets none of that. They hear five disconnected paragraphs and have no idea they’re related options or steps.
So: use real lists. In the block editor, that’s the List block — unordered (bullets) for options without sequence, ordered (numbers) for steps and rankings. If you’re presenting steps, use a numbered list; the numbers convey order, which matters. If you’re listing features, use bullets. Don’t hand-type “1.” at the start of paragraphs — use the actual ordered list, so the structure is programmatic, not visual.
The same principle applies to other structure. Don’t fake headings with bold text (Rule 1). Don’t fake tables with tabs and spaces (Rule 6). Don’t convey meaning with color alone — “the red items are required” means nothing to someone who can’t see red. Every piece of structure should exist in the code, not just in the appearance. Screen readers read code structure, not visual design.
This is also why the block editor is your friend: its List, Heading, and Table blocks produce proper semantic HTML automatically. The block editor guide is worth your time if you’re still formatting things by hand. Proper blocks are accessible blocks.
Rule 5: Write in Plain Language and Short Paragraphs
Screen reader users can’t skim the way sighted readers do — they can’t let their eyes drift across a page and land on the interesting part. They listen linearly, which makes dense, jargon-heavy writing genuinely punishing. Plain language isn’t dumbing down. It’s respecting your reader’s time and attention.
Short sentences. Aim for the kind of sentence you’d say out loud — if you run out of breath reading it, it’s too long. Short paragraphs. One idea per paragraph, two to four sentences. A wall of text is a wall of audio: unbroken, unnavigable, exhausting.
Explain jargon on first use. If you must use a technical term, define it in plain words right there: “alt text — the description a screen reader reads for an image.” Don’t make the listener hold an undefined term while they keep listening. This habit helps every reader, including the large number of sighted visitors reading in their second language.
Active voice. “We published the report” beats “the report was published by us.” It’s shorter, clearer, and easier to follow when heard. Contractions (“don’t,” “you’ll”) sound natural when read aloud — because screen readers do read aloud, writing that sounds like speech works better.
Front-load meaning. Put the important words first in sentences, paragraphs, and headings. Listeners decide in the first few words whether to keep listening; don’t bury the point in clause four.
I won’t pretend this is easy — plain language is a discipline. But here’s my test: read your draft aloud before publishing. If you stumble, your readers will too, and your listening readers most of all. The read-aloud test catches more bad writing than any tool.
Rule 6: Tables Need Real Headers
Data tables are common on WordPress sites — pricing comparisons, feature lists, schedules — and they’re a screen reader minefield when done wrong. Here’s how the experience works: the user enters the table, and the screen reader announces the dimensions (“table with 4 columns and 6 rows”). As they move cell to cell, it reads the column and row headers for each cell — but only if the headers are properly marked up.
Use real table headers. In the block editor’s Table block, designate the header row. In HTML terms, that’s <th> elements, not just bold text in the first row. Bold looks like a header to eyes; only <th> is a header to a screen reader. Without real headers, the listener hears a stream of disconnected data cells with no idea what column they’re in.
Keep tables simple. Merged cells, nested tables, and multi-level headers confuse screen reader table navigation badly. If your table needs merged cells to make sense, consider whether it should be a table at all — sometimes a list of sections with headings is clearer for everyone.
Caption or introduce the table. A sentence before the table saying what it shows (“The table below compares our three plans by price, storage, and support hours”) gives the listener context before they dive into the grid. The Table block supports captions — use them.
And never use a table for layout — for positioning content side by side. Layout tables announce as data tables, and the listener tries to make sense of a “data” relationship that doesn’t exist. It’s one of the oldest accessibility mistakes on the web, and it still shows up. If it’s not data, it’s not a table.
Rule 7: Punctuation Is Pronunciation
Here’s something sighted writers never think about: screen readers pause for punctuation. Periods, commas, semicolons, question marks, exclamation points, paragraph endings — each one is a pause in the audio stream. Your punctuation is literally the rhythm of someone’s listening experience.
This has practical consequences. A 60-word sentence with two commas is a marathon of unbroken audio — the listener can’t breathe with it, can’t find the structure, and may lose the thread entirely. Short sentences with clear periods aren’t just style; they’re rest stops.
ALL CAPS is read letter by letter by some screen readers (“S-A-L-E”) or shouted by others — either way, it’s unpleasant. Use it sparingly, if at all. Excessive exclamation points get announced with emphasis each time (“exclamation!”), which gets old fast. And ASCII art, emoticons made of punctuation, and decorative character sequences (“★☆★☆★”) are announced character by character — pure noise.
Abbreviations deserve care too. Most screen readers handle common ones, but the first time you use an uncommon abbreviation, spell it out: “Web Content Accessibility Guidelines (WCAG)” and then “WCAG” after. It’s the same courtesy you’d extend a sighted reader, and it costs one sentence.
The principle underneath: write for the ear, not just the eye. Every punctuation choice is a sound choice. When in doubt, read it aloud — with actual pauses where the punctuation sits — and ask whether it sounds like something you’d want to listen to.
The WordPress-Specific Habits That Matter
Beyond the writing rules, a few WordPress habits make or break the screen reader experience:
Set your page titles well. The page title is the first thing announced on every page load. “Home” as a title tells the listener nothing; make titles descriptive and unique. Your SEO plugin’s title settings are also accessibility settings — treat them that way.
Set the language. Screen readers use the page’s language setting to pick pronunciation rules. WordPress sets this from your site language automatically — don’t break it, and if you publish in multiple languages, make sure each page declares its language correctly. The wrong language setting turns your content into mispronounced gibberish.
Use landmarks. Your theme should output proper landmark regions — header, nav, main, footer. Most modern themes do. These let screen reader users jump between page regions instantly. If your theme is old enough to lack them, that’s a theme problem worth fixing — it’s structural, and it affects every page.
Don’t disable zoom. Some themes and plugins set viewport rules that prevent pinch-zoom on mobile. Many low-vision users browse zoomed permanently. Disabling zoom locks them out. Check that your site allows zooming — it’s a setting, not a feature, and it should never be off.
Mind your page builders. Page builders can produce heading chaos — skipped levels, empty headings used as spacers, divs instead of buttons. If you use one, audit its output with a screen reader, not just your eyes. The theme mistakes guide covers structural problems that often come from builders.
Image optimization and accessibility overlap. Properly sized, well-compressed images with good alt text serve everyone. The lazy loading guide keeps your images fast — and fast pages are more usable for everyone, including people on assistive technology with slower connections.
Your Pre-Publish Screen Reader Checklist
Run this on every post and page before it goes live:
- One H1 (the page title), headings in order, none skipped, none used for styling.
- Every meaningful image has purposeful alt text, one sentence, no “image of” prefix. Decorative images have empty alt text.
- Every link makes sense out of context — no “click here,” no “read more,” no bare URLs.
- Lists are real lists (List block), not hand-typed bullets or numbers.
- Paragraphs are short, one idea each. Jargon is explained on first use.
- Tables have real header rows, simple structure, and a caption or introduction.
- Punctuation is restrained — short sentences, no ALL CAPS passages, abbreviations spelled out first.
- Page title is descriptive and unique. Language is set correctly.
- Read the draft aloud once. If you stumble, rewrite.
Bonus Tip: Make this checklist a template in your editorial workflow — a literal checklist attached to every draft. Content teams forget accessibility rules under deadline pressure; the checklist remembers for them. The sites with the best accessibility aren’t the ones with the most expert writers — they’re the ones with checklists.
Frequently Asked Questions
How long should alt text be?
One sentence, ideally under about 125 characters — some screen readers truncate longer descriptions. If one sentence can’t convey what matters (a complex chart, a detailed diagram), put the key insight in the alt text and provide a fuller description in the surrounding content or a linked page. Brevity serves the listener; completeness serves the content. Do both, in the right places.
Should I add alt text to every single image?
Every meaningful image, yes. Every decorative image, no — decorative images get empty alt text so screen readers skip them. The skill is telling the difference: if removing the image would lose information or meaning, it’s meaningful. If the page works exactly as well without it, it’s decorative. When in doubt, ask what the image is doing there — the answer tells you which kind it is.
Do screen reader users really navigate by headings?
Yes — it’s the primary navigation method, more common than tabbing through everything. Most screen reader users pull up the heading list first and jump to the section they want, the way sighted users scan visually. That’s why heading order matters so much: a broken heading structure doesn’t just look sloppy in code, it breaks the main way blind users move through your content.
Is “click here” really that bad?
Yes, and it’s the easiest fix in this entire guide. In a link list, “click here” repeated five times tells the user nothing about five destinations. Descriptive link text — “download the 2026 report,” “read the setup guide” — tells them everything. It takes seconds to fix per link, helps SEO, and helps sighted skimmers too. There’s no defense left for “click here.”
How do I test with a screen reader if I’ve never used one?
Download NVDA (free, Windows) or press Cmd+F5 on a Mac for VoiceOver. Open your page, close your eyes, and listen for two minutes — don’t try to master the controls, just listen. Then learn three commands: navigate by headings, list all links, and move through a table. An hour of practice gives you enough skill to audit your own content. It feels alien at first; it becomes second nature faster than you’d expect.
Final Thoughts
Ninety seconds. That’s how long I lasted listening to my own site before I turned it off, embarrassed. But here’s what I want you to take from that story: I fixed it. Not all at once, not perfectly — but heading by heading, link by link, image by image. And the writing got better for everyone, because writing for the strictest reader makes you a stricter writer.
You now have the complete guide: understand how screen readers experience pages, structure headings as a real outline, write alt text with purpose, make links self-explanatory, use real lists, write plainly, mark up tables properly, punctuate for ears, and run the pre-publish checklist every time. None of it requires a developer. All of it is writing.
One honest line: your content is probably harder to listen to than you think. Mine was. The good news is that every fix is small, every fix is just words, and every fix makes your writing better for the sighted readers too.
If you listen to your site with a screen reader after reading this, tell me what you heard in the comments. I read every one — and I promise, the first listen is always the most educational.
