Who this is for
This guide is for content editors, communications staff, marketing teams, and anyone who writes or publishes content on a website. You do not need to know HTML or WCAG — just practical habits that prevent the most common accessibility barriers.
Your daily editor workflow
Accessibility is not a one-time audit. It is about the small decisions you make every time you publish. Build these checks into your publishing routine:
- Draft: Write content in a logical order with clear section labels.
- Structure: Apply heading levels that reflect the outline, not font preferences.
- Images: Add useful alt text for every meaningful image. Mark decorative images to be skipped.
- Links: Write link text that describes the destination or action.
- Preview: Read the page outline (headings only) and confirm it makes sense.
- Scan: Run the website accessibility checker after publishing or making major edits.
- Fix: Address flagged issues before the next publishing cycle.
Headings: structure before styling
Your CMS probably has a heading dropdown: Heading 1, Heading 2, Heading 3, etc. Do not pick a heading level because you like the font size. Pick it because it is the right level in the page outline.
- One H1 per page: This is the page title. It tells everyone what the page is about.
- H2 for major sections: Use H2 for the main topics on the page.
- H3 for subsections: Use H3 for sections inside an H2. Do not jump from H2 to H4.
- No empty headings: If a heading has no text, delete it or add a label.
- Descriptive text: Avoid headings like "More," "Details," or "Section." Name the actual topic.
Use the heading structure checker to review your outline before publishing. See heading examples for patterns.
Alt text: describe what matters
Every image you add to a page either needs descriptive alt text or needs to be intentionally marked as decorative:
- Informative images: Write alt text that describes the useful content. A product photo, team headshot, chart, or map needs a description.
- Decorative images: Background patterns, visual dividers, and purely aesthetic images should use empty alt text so screen readers skip them.
- Linked images: If the image is also a link, the alt text should describe the destination or action, not just the picture.
- Avoid filename-like alt: "IMG_2049.jpg" is not useful alt text.
- Avoid generic labels: "photo," "image," and "graphic" rarely explain anything useful.
Use the alt text checker to review image descriptions. See alt text examples for patterns.
Link text: say where the link goes
- Write descriptive link text: "Read the 2024 accessibility report" is better than "click here" or "learn more."
- Links should make sense out of context: Screen reader users often browse a list of links. If your link says "read more" five times, nobody knows where each one goes.
- Document links: When linking to a PDF or download, include the format. Example: "Download the accessibility checklist (PDF, 240 KB)."
Documents and PDFs: caution required
Uploading a PDF is not the same as publishing accessible content:
- Scanned image PDFs: A scanned document without text is completely inaccessible. Do not upload scanned documents.
- Tagged PDFs: Most modern PDFs can be tagged for accessibility. If you create PDFs from Word or Google Docs, use the built-in accessibility checker before exporting.
- HTML alternatives: Where possible, provide the same content as an HTML page. It is more accessible, works better on mobile, and is easier to update.
- Clear file names: Name the file something meaningful, not "document-final-v3.pdf."
Embedded media: captions and transcripts
- Videos: Need accurate captions. Auto-generated captions need review before publishing.
- Audio: Needs a text transcript.
- Embeds from other platforms: YouTube, Vimeo, and social media embeds may have their own accessibility settings. Check the embed code and test with keyboard and screen reader if possible.
TABLES: keep them simple
If you add a table to a page:
- Use a header row to label each column.
- Avoid empty cells.
- Avoid nested tables or tables used only for layout.
- Add a caption or heading above the table that explains what it shows.
Plain language: write for real people
Accessible content starts with clear language. Avoid jargon, acronyms without explanation, and unnecessarily complex sentences. Instructions should be understandable on the first read. This helps everyone, including people who read slowly, use translation tools, or process information differently.
Avoiding accessibility regressions
A regression happens when a page that was accessible becomes less accessible after a content update. Common causes:
- Adding images without alt text.
- Changing heading levels for visual reasons.
- Inserting a link with "click here" as the link text.
- Uploading an inaccessible PDF.
- Embedding a third-party widget without checking its accessibility.
Run the website accessibility checker after any significant content change. Treat scans as a quick safety check, not a full audit.
When to ask for developer or reviewer help
You can handle most content accessibility on your own. Call in help when:
- A heading outline problem comes from the template or theme, not your content.
- A form, interactive widget, or custom component is not working with keyboard only.
- Colour contrast issues appear in design-system elements you cannot control.
- You need to confirm whether a page meets formal WCAG, AODA, or ACA expectations.
Useful SiteCheck Canada tools
- Website accessibility checker — scan pages after publishing.
- Heading structure checker — review outlines before publishing.
- Alt text checker — review image descriptions.
- Accessibility issue library — understand common findings.
- Content editor printable checklist — keep at your desk.
- Canadian website accessibility checklist — broader reference.
- What automated checkers miss — know where human review is needed.