Checklists · 21 checks
The Content Editor's Publishing Checklist
Everything here happens in the CMS. None of it needs a developer.
The Content Editor's Publishing Checklist
- Checks
- 21
- Time
- 5 minutes per page once it is habit
- Last reviewed
- August 28, 2026
Anyone who writes or publishes pages in a CMS. No technical knowledge assumed.
A perfectly built template can still produce an inaccessible page, because a large share of accessibility lives in the content rather than in the code. Headings, link text, alt text and plain language are all editorial decisions. Whoever is typing makes them, and no developer can make them for you afterwards.
The good news is that these are the cheapest fixes on the whole standard. Most take seconds. They happen before anybody files a defect, and they cost nothing once they are habit.
Five groups, in the order you build a page. Structure, links, images and video, tables, then the language itself.
Structure on the page
Screen reader users navigate by heading far more often than they read a page top to bottom, so your structure is how anybody finds anything. Five checks. All of them live in your editor's own toolbar.
Use real headings, not bold text.
Apply Heading 2 and Heading 3 from your editor's style menu rather than reaching for the bold button. Bold is styling and carries no structure at all, so a screen reader jumping between headings never lands on it. The line looks identical either way. That is why people get this wrong for years without hearing about it.
WCAG 1.3.1
Heading 2 followed by Heading 4 leaves a gap. Choose the level for its place in the outline, not its size. W3C asks for properly nested headings without making a skip a failure, so this is a defect to fix rather than a rule you break.
Headings say what the section is about.
Read your headings on their own, with the body text hidden, which is roughly what somebody navigating by heading gets. If that list does not summarize the page, rewrite them. Length is not the test here, because one word is enough when it tells a reader what they will find.
WCAG 2.4.6
The page title is unique and descriptive.
Compare it with the pages either side of it in your site tree. Twelve pages titled 'Services' help nobody with a row of tabs open, and the title is also the first thing announced when somebody arrives, so it is doing two jobs before a word of your page is read.
WCAG 2.4.2
Lists are made with the list button.
Hyphens typed at the start of a line look exactly like a list and are not one. A real list is announced with its length. A reader hears that six items are coming and can skip them. A typed one is announced as a paragraph starting with a hyphen, six times over.
WCAG 1.3.1
The link text you write
Screen reader users often pull up a list of every link on a page and read it with none of the surrounding text attached. That list is the test. Four checks, and all four are about what the words say once the sentence around them is gone.
Link text describes the destination.
Read the link on its own. 'Read the 2026 pricing guide' works anywhere. 'Read more' clears 2.4.4 only when the sentence or list item around it names the destination, and it fails the stricter 2.4.9 either way.
WCAG 2.4.4
Do not paste raw URLs as link text.
A screen reader reads the whole address out. In places it reads it character by character. Nobody listening can hold that. Write what is at the other end instead, and keep the address in the href where it belongs.
WCAG 2.4.4
Two links with the same text lead somewhere a reader would expect.
Identical wording pointing at genuinely different things is confusing, so reword one of them. Neither rule asks for identical text to mean an identical address, though. Both ask whether the purpose is identifiable, so two links worded the same for the same purpose can point at different URLs and still be fine. Treat this as a clarity fix rather than an AA failure.
WCAG 2.4.4
Say when a link opens a new window or downloads a file.
Put it in the link text itself, and for a download add the file type and the size. A new window changes where somebody is with no warning, which is disorienting for a screen reader user and worse for anybody using magnification, because the whole visible area has just been replaced.
Images and video
Two questions cover almost every image you will ever publish. Does this one carry meaning, and if it does, what meaning does it carry here? The two video checks at the end cost money. Budget them rather than discovering them.
Meaningful images have alt text.
Describe what the image tells a reader at this point on this page, which is not always what is visible in it. The same photograph of a shop front means the address on a contact page and atmosphere on an about page. The alt text should differ.
WCAG 1.1.1
Decorative images have empty alt text.
Fill the alt field with nothing rather than leaving it untouched, because most editors treat those two states differently. An empty alt tells a screen reader to walk past the image. No alt attribute leaves it nothing to announce. Several screen readers then read out the filename.
WCAG 1.1.1
Do not put text inside an image.
Text baked into a picture cannot be enlarged, recolored, translated or read aloud, so put real text over a background image instead and you keep all four. Logos and brand marks are excepted by name, which means your wordmark can stay as artwork without anybody arguing about it.
WCAG 1.4.5
Watch a minute of your video with the automatic captions on and read along. Names, numbers and technical words are where they go wrong, and those are usually the words carrying the point. Correcting them takes a fraction of the time recording it did.
WCAG 1.2.2
Publish it on the page, not only inside the player, so it can be read and searched. For a video with a soundtrack this is the media alternative 1.2.3 asks for, and 1.2.1 is the rule for silent video and audio-only files.
WCAG 1.2.3
Tables and page layout
Tables are for data, and using one to arrange a page is a habit from an older web that still causes real problems. Three checks, and the first one is the difference between a table somebody can read by ear and a wall of loose numbers.
Mark the top row as headers, and the first column too where that column labels the rows. This is what lets a screen reader announce "Revenue, Q3, 14.2" instead of a bare number, and it is the single change that makes a table usable by ear rather than by eye.
WCAG 1.3.1
Do not use a table for layout.
If what is inside is not data with rows and columns of meaning, it is a layout table and it should be columns instead. A screen reader announces a table with its dimensions before reading a cell, so a page arranged in one starts by telling somebody about a grid that does not exist.
WCAG 1.3.2
Merged cells and tables inside tables are hard to follow by ear, because a listener has to hold the shape of the grid in their head while moving through it. Split a complicated table into two simple ones. They read better on a phone too.
The language you write in
Plain language is a WCAG requirement only at the enhanced level, and it is a usability win at every level, which makes this the group with the best return and the least enforcement behind it. Write for somebody tired, on a phone, reading through a magnified window.
Expand an acronym the first time it appears.
Write the words out and put the short form in brackets after them, then use the short form for the rest of the page. It costs six words once and it saves anybody who arrived from a search result rather than from your homepage, which is most of your readers.
Front-load the point of each paragraph.
Put the message in the first sentence and the supporting detail after it. People scan, some are reading through a magnified window that shows a few words at a time, and a screen reader user gets one pass in the order you wrote it. All three are served by the same habit.
Never let shape, color or position be the only clue.
"The green button on the right" fails for several groups at once. Name the button as well and the cue can stay, because both rules bar sole reliance rather than the cue itself. Shape, size and position sit under 1.3.3, color sits under 1.4.1, and "choose one of the links below" is fine either way because the reading order makes it unambiguous.
WCAG 1.3.3
Mark passages in another language.
Most editors carry a language setting per block, and one quoted paragraph in French needs it. Without it a screen reader reads French words with an English voice, which is not accented, it is unintelligible. Proper names, technical terms and borrowed words that have settled into English need nothing.
WCAG 3.1.2
One honest limit
This list covers the content layer and nothing underneath it. If the template itself has problems, a missing focus indicator or a navigation menu that cannot be opened by keyboard, no amount of careful publishing will reach them, and the pages you publish most carefully will still fail on those.
Keep going
Other checklists
Ticked every box and want it verified?
The full audit tests all 55 WCAG 2.2 A and AA rules with a pass or fail on each, adds an expert review, and puts a real blind screen-reader user on your key journeys. $499, report in 5 business days.