Make the Right Thing the Easy Thing: Accessibility Controls Inside Your CMS

Accessibility statements are useful. They tell people what to expect, how to report a problem and who is accountable. End-of-project audits are useful too. They catch issues that have accumulated. But neither of them makes a page accessible on a wet Tuesday afternoon when a content editor is trying to publish a service update before a meeting.

That is why accessibility has to live inside the CMS, not in a PDF attached to a project closure document. The CMS is where headings get chosen, links get written, images get uploaded and tables get pasted in from Word. If the tool makes the inaccessible option easier, people will take it. Not because they do not care, but because they are busy.

The PDF-at-the-end problem

Many UK organisations still treat accessibility as a compliance artefact. The statement gets published, the audit gets commissioned, the PDF gets filed. Then everyday publishing carries on exactly as before. New pages arrive with vague link text, empty alt attributes and heading levels chosen for font size. The next audit finds the same problems in new places.

Public-sector expectations in 2026 are not just about having a statement. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 still set the baseline, and WCAG 2.2 AA is the working benchmark for most teams. Procurement questionnaires increasingly ask how accessibility is maintained, not just whether an audit once happened. Private organisations feel the same pressure through tenders, supplier reviews and customer expectations.

The practical question is not 'Do we have an accessibility statement?' It is 'Can a busy editor publish an accessible page without needing a specialist to review it every time?'

Make the right thing the easy thing

The best CMS accessibility work is unglamorous. It is a required field here, a sensible default there, and a pre-publish prompt that catches the obvious mistakes before they go live. Here are the controls worth building into everyday publishing.

Required alt text, with a proper escape hatch

If alt text is optional, it will be skipped. Make it required for images that convey information, but give editors a clear 'decorative image' option. That way you are not forcing people to write meaningless descriptions for spacer graphics or purely visual flourishes. The CMS should explain the difference in plain English, next to the field, not in a training slide from six months ago.

Heading structure guardrails

Headings are one of the most common failures we see. Editors pick H3 because it looks right, or paste from Word and inherit a structure that makes no sense. A good CMS can show the heading outline, warn when a level is skipped, and make the page title the H1 by default. It can also stop editors using bold text as a fake heading. Guardrails are better than a telling-off after publication.

Meaningful link labels

'Click here' and 'Read more' are still everywhere. The CMS can help by prompting for a link purpose, showing the destination in the editing interface, and warning when the label is generic. For cards and listings, use the page title or a clear action phrase. Screen reader users often navigate by link list, so the label has to make sense out of context.

Accessible table blocks

Pasting a table from Word is a classic route to missing headers and merged cells that collapse on mobile. Provide a table block that asks for column headers, row headers where needed, and a caption. Do not let editors create layout tables for visual spacing. If the CMS has a table component with sensible defaults, most of this problem disappears.

Pre-publish checks

A short checklist before publishing is not bureaucracy if it is fast. Ask: does every image have the right alt text? Is there one H1? Are links descriptive? Is the table marked up properly? Is there any text in an image that should be real text? The CMS can automate some of this and prompt for the rest. Keep the list short enough that people do not click through it blindly.

Editor training that matches the tool

Training should show the actual CMS, not a generic slide deck. Cover the controls above, explain why they matter, and give editors a way to ask for help. New starters should get the same session, not inherit habits from whoever sat next to them. Refreshers are useful when the CMS changes or when audit findings show a pattern.

Do not make accessibility a punishment

There is a balance. If the CMS blocks publishing every time an image lacks alt text, people will find workarounds or give up. Good controls explain themselves, allow a legitimate exception, and do not treat every missed field as a disciplinary matter. The aim is to make the accessible path the path of least resistance, not to turn content editors into compliance officers.

What to measure

Track the things the CMS can see: pages with missing alt text, pages with skipped heading levels, generic link labels, tables without headers, and pre-publish checks completed. These are not perfect accessibility measures, but they are useful leading indicators. Combine them with user feedback, manual testing and periodic audits. The CMS data tells you where to look; it does not replace listening to disabled users.

Who owns it

Accessibility is not a single person's job. The CMS product owner should own the controls. Content leads should own the publishing habits. Senior owners should sign off the accessibility statement and make sure fixes are resourced. In 2026, that is a reasonable expectation for any UK organisation that publishes services online.

The statement and the audit still matter. But they are the backstop, not the strategy. The strategy is a CMS that nudges people towards good headings, real alt text, clear links and proper tables every time they hit publish. Accessibility is a feature of the publishing workflow, not a document at the end of it.