Your developer fixed the menu, the contact form and the focus outlines last spring. Since then, three people have been adding pages: the office manager posts news, someone in marketing uploads event flyers, and the owner writes the occasional blog post. Nobody told them what to watch for, and slowly the site has started to fail the same checks again.
That is normal. A large share of what makes a site usable for people with disabilities sits in the hands of whoever types into the editor, not whoever wrote the theme. This guide covers accessible web content from the editor’s side: the habits that keep pages readable by screen readers, keyboard users, people who zoom, and people who simply read slowly.
What editors control, and what belongs to the developer
The theme, the menus, the way the contact form is built, the focus outline you see when you press Tab, the skip link, the cookie banner: those are code. If they are broken, an editor can report it but not fix it. Everything you put inside a page or post is yours: the words, the heading levels you pick, the link text, the images and what you say about them, the files you attach, the videos you embed, the colors you choose in the block settings, the tables you build.
WCAG 2.2, the W3C standard most US accessibility work is measured against, does not care who made the mistake. A missing image description fails 1.1.1 Non-text Content whether the developer or the intern caused it. So a site that passed an audit can drift out of conformance within a few months purely through new content. That is the part this post is about.
Headings that build an outline, not a font size
Screen reader users often jump through a page by its headings, the way a sighted reader skims bold lines. If the headings are real and in order, they can find the section they want in seconds. If headings were chosen because “Heading 4 looked about right”, the outline turns into nonsense.
The rules are short:
- The page title is usually the only H1. In WordPress most themes print the title as the H1, so the content starts at H2.
- Main sections are H2. Subsections inside them are H3. Do not jump from H2 to H4.
- Do not fake a heading with a bold, enlarged paragraph, and do not use a Heading block just to make a sentence big. Structure has to be in the code, which is what 1.3.1 Info and Relationships asks for.
A quick test: read only your headings, top to bottom. Do they work as a table of contents? If one says “More” or “Details”, it will mean nothing out of context, and 2.4.6 Headings and Labels expects headings to describe what follows. Our separate guide on structuring H1, H2 and H3 for search covers the SEO side; the accessibility rules happen to point the same way.
Links that still mean something in a list
Many screen reader users pull up a list of every link on a page and pick from it. On plenty of small business sites that list reads “click here, click here, read more, learn more, here”, and nobody can choose from it.
Write the link around the words that say where it goes. Instead of “To see our fall hours, click here”, write “See our fall opening hours” and link those words. A few more habits:
- If a link opens a PDF or another site, say so in the link text or right beside it.
- Do not paste bare web addresses into the text. A screen reader spells them out, character by character.
- Two links with the same text should go to the same place. Five “Read more” links pointing to five different posts confuse everyone.
The relevant criterion is 2.4.4 Link Purpose (In Context). It allows the surrounding sentence to carry some of the meaning, but link text that stands alone is kinder and safer.
Images: decide the job first, then write
Every image you add is doing one of three jobs. It carries information (a photo of the product, a chart of opening hours), it does something (a linked logo, an image used as a button), or it is decoration (a texture, a stock photo that repeats what the text already says). The job decides what goes in the alt text box: a description, the destination of the link, or nothing at all so screen readers skip it.
That decision is where most editors go wrong, more than the writing itself. We go through the gray cases in our post on when an image should have empty alt text. For where the box lives in WordPress and how to word a good description, see how to add alt text in WordPress.
Two content traps that are worth knowing here. First, text baked into an image: an event flyer uploaded as a JPEG, with the date and address only inside the picture. A screen reader gets nothing, and someone zooming in gets a blurry mess. Put the details in real text on the page as well. Second, an image used as a background, as in a Cover block, is usually skipped by screen readers, so the text you place on top has to carry the whole message.
Color, emphasis and how text looks
The block editor lets anyone pick text and background colors, which is where a lot of contrast failures sneak in after launch. WCAG asks for 4.5:1 between body-size text and what sits behind it, and 3:1 for large text (1.4.3 Contrast (Minimum)). Pale gray on white and white text on a light photo are the usual suspects. If the theme offers a fixed palette, stick to it; someone probably checked those pairs already.
Color should not be the only way you say something. “Items in red are sold out” fails for anyone who cannot tell red from brown, which is why a word or a symbol should go with the color. That topic has its own post on designing for color blindness.
Readability goes beyond color. Long stretches of italics, text set in all capitals, justified paragraphs with ragged gaps between words, and tiny captions all make reading harder for people with low vision or dyslexia. Most of that is a theme decision, but editors often override it one paragraph at a time. Our post on readable fonts and type sizes explains what to keep and what to avoid.
Documents and downloads
Many sites carry a long tail of PDFs: menus, price sheets, newsletters, forms, board minutes. Each one is content, and each one has to be accessible too. A scanned PDF is just a picture of a page; a screen reader finds nothing in it.
Before anyone learns to tag a PDF, it is worth asking whether the file needs to exist in that format. A restaurant menu, a list of services, or office hours read far better as a normal web page, on a phone and with assistive technology. Keep PDFs for things people really print or file, and make those properly tagged. We cover that decision and the tagging basics in our guide to accessible PDFs on a website.
Video and audio
If a video has speech, it needs captions (1.2.2 Captions (Prerecorded)). Automatic captions from video platforms are a starting draft, not a finished job: they mangle names, numbers and product terms, and they skip the sounds that matter, like a phone ringing or applause. Someone has to read them through and correct them. How to do that for embedded and self-hosted video is in our post on closed captions for website videos.
Audio on its own, such as a podcast episode or a recorded talk, needs a text version people can read instead. A transcript also helps people who are in a quiet office without headphones, and people who would rather skim. What a useful transcript contains and where to put it is covered in transcripts for audio and podcasts.
One more habit: leave autoplay off. Sound that starts on its own talks over a screen reader, and a looping clip beside your text distracts anyone trying to read. If a video or animation does run automatically for more than five seconds, 2.2.2 Pause, Stop, Hide expects a visible way to pause it.
Writing accessible content in plain language
Writing accessible content is mostly about words, and it is the cheapest fix there is. It helps people with cognitive disabilities, people reading in a second language, and most customers on a phone.
- Put the main point first. “We are closed Monday, July 4” before the paragraph about the holiday.
- Use the words your customers use. “Teeth cleaning”, not “prophylaxis appointment”.
- Keep sentences short and one idea per paragraph.
- Explain abbreviations the first time you use them.
- Write instructions as numbered steps when the order matters.
The US federal government has a long-running plain language practice, and its habits work just as well for a dental office or a hardware store. Our post on plain language website content goes into sentence and word choices, and why readability scores should be treated with caution.
Tables, lists and the shape of a page
Structure is information. A list of steps should be a real numbered list, built with the List block, not lines that start with typed numbers. A screen reader then announces “list, five items” and the listener knows what is coming.
Tables are for data with rows and columns, such as a class schedule or a comparison of plans. They need a header row marked as a header, which the Table block offers in its settings, and they should not be used to lay out a page into columns. A table with merged cells and empty rows for spacing is very hard to follow by ear. Our post on building accessible tables covers the details.
A pre-publish routine for accessible web content
None of this sticks unless it becomes a habit. Here is a short routine an editor can run on every new page or post before pressing Publish or Update. It takes a few minutes once it is familiar.
- Headings: in the editor’s Document Overview panel, the Outline tab shows every heading. Check the levels run without skips and each one names its section.
- Links: read every link on its own. Would you know where it goes? Is any PDF or external site flagged?
- Images: click each one. Is the job decided and the alt text box filled in, or deliberately left empty for decoration? Is any text trapped inside the picture?
- Color: did you change any text or background colors? If so, check the pair in a contrast checker.
- Files: is every attached document either a real page or a tagged PDF?
- Media: do videos have corrected captions, and does any audio have a transcript?
- Reading: read the first paragraph aloud. Is the main point there?
- Preview: open the preview and zoom the browser to 200 percent. Does anything overlap or disappear?
A free scanner such as WAVE from WebAIM will catch missing alt text, empty links and contrast problems on the published page. It will not tell you whether your alt text is any good or whether your headings make sense, so the routine above still matters. For the wider site, beyond content, our small business accessibility checklist lists what else to look at.
If you manage a team, pin this accessible web content routine where everyone sees it and spot-check a few recent pages each month. Checking five pages in March is a lot less work than discovering in December that forty of them have unlabeled images.
When editing is not enough
Sometimes good content habits run into a wall. The theme forces every post title into an H3, the brand colors fail contrast everywhere, the page builder wraps every image in a link, or the blog template has “Read more” hard-coded under each excerpt. Those are template problems: note them and pass them to whoever maintains the site. If you are working through a backlog of old images, captions and documents, our page on alt text, captions and document accessibility describes how that cleanup can be handled, and the wider picture of audits, fixes and monitoring is on our website accessibility services page.
Frequently asked questions
Do I need to fix old pages, or just write new ones properly?
Both, but in order. Start new habits today so the problem stops growing. Then work through old content by importance: the home page, service or product pages, contact and booking pages, and the posts that get the most visits. Old news posts nobody reads can wait, or be removed if they no longer serve anyone.
Is writing accessible content different from writing for SEO?
They overlap a lot. Clear headings, descriptive link text, accurate image descriptions and captions help both screen reader users and search engines understand a page. They differ where SEO habits go too far, such as stuffing keywords into alt text or headings, which makes pages worse for people listening to them. Write for the person first.
Can a plugin check my content as I write?
Some WordPress accessibility checker plugins flag missing alt text, skipped heading levels and low contrast inside the editor, and they are useful reminders. They cannot judge whether your alt text describes the image well, whether a heading makes sense, or whether your writing is clear. Treat their warnings as prompts to look, not as a pass or fail.
Does every editor need training, or can one person check everything?
Every editor needs the basics, because the choices about headings, links and images happen while writing and are slow to fix later. On top of that, one person, often the office or marketing manager, should check a sample of new pages each month and keep the routine written down. If nobody is named for that, the checks tend to fade out.
Good content habits keep a site usable, but they cannot rescue a theme built without accessibility in mind. If your editors keep fighting the template, it may be time to look at an accessible website redesign that builds headings, colors and layouts right from the start, so the people writing pages are working with the site instead of around it.
All guides in this section
- Alt Text for Decorative Images: When to Use Empty Alt
- Video Captions for Accessibility: Get Them Right
- Transcripts for Accessibility: Podcasts and Audio
- Accessible PDF Files on Your Website: What to Fix
- Accessible Fonts: Size, Spacing and Readable Type
- Color Blind Friendly Website: When Color Can’t Carry Meaning
- Plain Language Writing for Your Website: A US Guide
- Accessible Tables: Headers, Captions and Phones
- Buttons vs Links: Which to Use for Accessibility
- Animation Accessibility: Parallax, Video and Reduce Motion
- Accessible Icons: SVG, Icon Fonts and Social Links
Next in this series: Alt Text for Decorative Images: When to Use Empty Alt
