Accessible Content Checklist for Editors

Accessibility is shared work. Your developers build accessible templates and components; you make sure the content you put into them is accessible too. A well-built site can still fail people if an image has no alt text, a heading is skipped, or a link just says "click here".

This checklist covers the parts of accessibility that editors control. It is based on the W3C's Web Content Accessibility Guidelines (WCAG) 2.2, and each section names the success criteria it relates to, so you can read more. It's a practical starting point, not a legal compliance review: your organization decides which WCAG level you must meet.

The checklist

Copy this into your team's definition of done.

• Every meaningful image has alt text that describes what it shows or does.
• Images of text are avoided, or the alt text repeats the text.
• Headings are real headings, used in order, with no skipped levels.
• Link text makes sense on its own.
• Videos have captions; audio has a transcript.
• Tables are used for data only, with a header row.
• Nothing relies on color alone to carry meaning.
• The page title and meta description describe the page.
• The text is as plain as the subject allows.
• You've checked the result in Preview.

The sections below explain each item and where it applies in Agility.

Images and alt text

WCAG 2.2: 1.1.1 Non-text Content (Level A), 1.4.5 Images of Text (Level AA).

Alt text is read by screen readers and shown when an image doesn't load. In Agility you add it in two places:

• Image fields. An image you attach to an image field carries its own alt text, which your developers' code uses as the image's alt attribute. Your developers can set an image field to Require Alt Text, so an item can't be saved without it. If your important image fields don't require it, ask them to turn it on. See Fields.
• Images in rich text. An image you insert into a rich text field needs alt text too. The Rich Text Editor lets you view the HTML, where you can check that each image has a meaningful alt attribute.

Writing good alt text:

• Describe the purpose, not just the picture. For a product photo, "Blue waterproof jacket with a hood, front view" is more useful than "jacket".
• If the image is a link or a button, describe where it goes or what it does. "Download the 2026 price list (PDF)", not "PDF icon".
• Keep it short. A sentence is usually enough. Put long descriptions, such as the data in a chart, in the body text.
• Don't start with "Image of". Screen readers already announce it as an image.
• Decorative images that add nothing to the meaning don't need a description, according to the W3C. How your site marks an image as decorative depends on how it's built, so ask your developer before you leave alt text empty, especially where an image field requires it.
• Avoid images of text. Text in a picture can't be resized, translated or read by search engines. If you must use one, the alt text should contain the same words.

The W3C's alt text decision tree helps with harder cases.

Headings

WCAG 2.2: 1.3.1 Info and Relationships (Level A), 2.4.6 Headings and Labels (Level AA).

Many screen reader users move around a page by its headings. They only work if they reflect the structure.

• Use the heading styles in the rich text editor, not bold or larger text. Text that only looks like a heading is just a paragraph to assistive technology.
• Go in order. Under a level 2 heading, the next level down is 3. Don't skip from 2 to 4 because 4 looks the right size.
• One main heading per page. On most sites, the page or item title is shown as the main (level 1) heading, so headings in your body text start at level 2. Your developer can confirm how your site does it.
• Make headings descriptive. "Opening hours" helps; "More information" doesn't.

Link text

WCAG 2.2: 2.4.4 Link Purpose (In Context) (Level A).

Screen reader users often pull up a list of links. "Click here", "read more" and "learn more" repeated five times tell them nothing.

• Link the words that describe the destination. Write "Read our 2026 accessibility statement" with the link on "2026 accessibility statement", not "Click here to read the statement" with the link on "Click here".
• Say when a link opens a file, and what kind: "Annual report (PDF, 2 MB)".
• Keep call-to-action fields specific. If a component has a button label field, write what the button does.
• Don't use a raw URL as link text unless the URL itself is the point.

Video and audio

WCAG 2.2: 1.2.2 Captions (Prerecorded) (Level A), 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A).

• Captions for every video with speech. Captions are added in the video platform where the video is hosted, so check them there before you embed the video. Automatic captions are a start; review them, especially names and product terms.
• A transcript for audio-only content such as podcasts. A transcript can live in the body text below the player.
• Describe important visual information. If a video shows something the speech doesn't explain, such as a chart or on-screen steps, cover it in the narration, the description or the transcript.

Tables

WCAG 2.2: 1.3.1 Info and Relationships (Level A).

The rich text editor can create tables. Use them well:

• Tables are for data, not for laying out columns of text or images. Layout tables are hard to follow with a screen reader and break on small screens. If you need a layout, ask for a component that provides it.
• Give every data table a header row, so each cell can be announced with its column name.
• Keep tables simple. Merged cells and tables inside tables are hard to navigate. Split a complex table into two simpler ones.
• Introduce the table in the text before it, so readers know what it shows.

The W3C tables tutorial explains header cells in more depth. You can check a table's header cells in the rich text editor's HTML view.

Color and contrast

WCAG 2.2: 1.4.1 Use of Color (Level A), 1.4.3 Contrast (Minimum) (Level AA).

Your site's design sets most colors, and your designers and developers are responsible for its contrast. As an editor:

• Don't use color alone to carry meaning. "Required fields are in red" fails people who can't see red. Add a word or symbol too.
• Avoid coloring text by hand in rich text. Custom colors may not meet the contrast WCAG asks for (at least 4.5:1 for normal text and 3:1 for large text at Level AA), and they can clash with your site's themes.
• Check text on images. If a component puts your text over a photo you choose, pick an image that keeps the text readable, and check it in Preview.

Page titles and descriptions

WCAG 2.2: 2.4.2 Page Titled (Level A).

The page title is the first thing a screen reader announces and what appears in the browser tab. Give each page a unique, descriptive Page Title in its SEO settings. See Managing SEO for Editors.

Plain language

WCAG 2.2: 3.1.5 Reading Level (Level AAA).

Clear writing helps everyone, including people with cognitive disabilities and people reading in a second language.

• Put the most important information first.
• Use short sentences and common words. Explain terms you can't avoid.
• Use lists for steps and options.
• Write instructions that don't depend on seeing the screen: "Select Save", not "click the green button on the right".

The U.S. government's plain language guidelines are a good, free reference.

Find and fix gaps across your content

You don't have to check every item by hand:

• Audit with an AI assistant. An assistant connected to Agility can list image fields with no alt text and rich text images with an empty or missing alt attribute, without changing anything. See Audit Your Content with AI. Review any alt text an assistant drafts before it's published: it can't always tell what an image means in context.
• The SEO Analysis app, if it's installed on your instance, checks images (including alt text) and that a page has a single main heading. See SEO Analysis.
• Make it part of approval. Add this checklist to what reviewers check before they approve. See Approvals and Workflows.

Automated checks catch missing alt text and skipped headings, but not whether alt text is accurate or a link makes sense. A person still needs to read the content.

Related articles

• Writing for Structured Content
• Rich Text Editor
• Managing SEO for Editors
• Audit Your Content with AI
• A Content Operations Playbook