A Consistent Accessibility Check Before Publishing

Category: Accessibility

A website can be built with good, accessible components and still develop new barriers every time someone publishes. A heading is used as decoration, a link is given the text “Read more,” an image contains important text, or a new form displays an error without explaining what the user needs to do.

That is why accessibility should be part of the publishing process, not just a check at launch. The solution is not for editors to conduct a full WCAG audit of every page. It is to establish a short, risk-based accessibility check that catches common errors before publishing.

Distinguish Between the Technical Foundation and Editorial Responsibility

WCAG includes requirements relating to design, code, content and user interaction. Responsibility therefore cannot all be assigned to one role. Developers and designers must ensure that components have the correct semantics, visible keyboard focus, sufficient contrast and support for assistive technologies. Editors must use the components correctly and publish clear content.

A practical division of responsibilities could look like this:

• Developer: code quality, keyboard functionality, focus order, names and roles for interactive elements.
• Designer: contrast, focus indicators, readable typography, zoom and clear states.
• Editor: heading structure, link text, alternative text, plain language and correct use of components.
• Form owner: field labels, instructions, error messages, confirmations and an understandable process.

The publishing check should not compensate for inaccessible components. If editors repeatedly have to check whether a button can be used with a keyboard, the problem lies in the solution and should be fixed centrally.

Adapt the Check to the Risk

Not all changes require the same level of testing. Correcting a typo is low risk. A new campaign page with a form, menu, video and several call-to-action buttons carries greater risk. The check should therefore have levels.

Low risk

Common text changes, replacing a single image and minor content adjustments can be checked by the editor. Pay particular attention to headings, link text, alternative text and readability.

Medium risk

New pages, landing pages and major revisions should also be tested with a keyboard, at increased zoom and with a basic check of contrast and structure.

High risk

New forms, dialog boxes, menus, booking flows and other interactive features should be checked by someone with accessibility expertise. The test should cover keyboard use, screen reader support, error handling and task completion.

This approach ensures that effort is focused where the consequences are greatest. At the same time, it prevents a comprehensive checklist from being skipped because it seems unrealistic.

Conduct a Consistent Six-Step Check

The check should be carried out in preview or a test environment before publishing. For a standard content page, it can be completed quickly once the process is established.

1. Read the page without the design perspective. Check that the purpose is clear, the headings describe the content, and important information is not conveyed solely through colour, placement or imagery.
2. Go through the page using a keyboard. Use the Tab key to move forward and the relevant key combination to move backward. Activate links and buttons without a mouse.
3. Check contrast and states. Look at regular text, buttons, links, focus indicators, error messages and text over images.
4. Zoom in. Check that the content can still be read and used without text or functionality disappearing or overlapping.
5. Perform a basic screen reader check. Listen to the page title, headings, links, images and interactive elements.
6. Complete any forms. Test both successful submission and deliberate errors, such as empty required fields and invalid formats.

The Keyboard Test Must Focus on the Task

It is not enough to see that a focus outline moves. Users must be able to understand where the focus is, the order in which elements appear and how the functions are activated.

Choose one specific task, such as finding contact information, opening a menu or submitting an enquiry. Put the mouse aside and complete the entire task. Check the following as you go:

• Is it always clear which element has focus?
• Does the focus order follow an understandable sequence?
• Can all buttons, links and options be activated using the keyboard?
• Does focus become trapped in a menu, dialog or component?
• Is focus moved to a sensible place when something is opened or closed?

If you discover that the focus order is incorrect or that a function cannot be operated, this is normally a development issue. An editor should not attempt to fix such problems with creative formatting.

Check contrast where the content actually varies

Colour contrast is often assessed in the design system, but editorial content can change the result. Text may be placed over a lighter image than planned. An editor may choose a low-contrast background colour, or a button may be given a different colour in a campaign module.

Therefore, check more than ordinary body text. Also look at small text, links, button text, field borders, help text, error messages and focus indicators. Remember that information should not depend on colour alone. For example, an invalid field should have a clear textual error message, not just a red border.

Be especially careful with text placed directly on photographs. Even if the contrast looks good at one screen size, the crop may change on mobile. A solid-colour background or a controlled contrast overlay provides a more robust result.

Use a screen reader as a listening test

A short screen reader test can uncover problems that are invisible on screen. The goal of the publishing check is not to master every feature of the assistive technology, but to verify that the page can be understood without the visual layer.

First, listen to the heading list. Do the headings form a meaningful outline, or are there gaps and headings used merely to make text larger? Then listen to the links. Several links with the text “Click here” or “Read more” make little sense when presented without the surrounding paragraphs.

Also check images. An informative image needs alternative text that conveys its purpose in context. A purely decorative image should not create unnecessary noise. If the image contains important text, the same information should be available as ordinary text on the page.

For buttons, menus and form fields, the screen reader should convey both what the element is and what it is called. If it only reads “button” or “text field”, it is difficult to know what the user should do.

Test the form when something goes wrong

The most useful form test is often to enter something incorrectly. Leave required fields empty, enter an invalid format and try to submit. Check that the error is detected, explained and associated with the correct field.

A good error message says both what is wrong and how it can be fixed. “Invalid value” is not very helpful. “Enter the telephone number using eight digits” gives the user a clear way forward.

Also check that:

• All fields have visible and precise labels.
• Instructions appear before the user needs them.
• Required fields are marked in an understandable way.
• Error messages do not disappear when the field receives focus.
• Keyboard focus moves to the error summary or the first relevant error when needed.
• The confirmation after submission explains what happens next.

Make the findings actionable

Do not collect all issues in one large list without an owner or deadline. Record what happens, where it happens, who is affected and how the error can be reproduced. It is also useful to include which task could not be completed.

Prioritise errors that block actions. A form that cannot be submitted using the keyboard is more critical than a minor inconsistency in heading levels. Next come problems that make content difficult to understand or use, followed by cosmetic and isolated issues.

If the same error appears on several pages, look for a common cause. It may be a component, a template or an unclear editorial choice. Fixing the root cause is better than repairing each page individually.

Build checking into the publishing workflow

The accessibility check only works if it is clear when it should be used and who approves it. Include it as a specific step before publishing new pages and major changes. Keep the checklist short enough that it is actually used, and provide a clear way to report technical errors.

Also monitor which issues recur. If editors often write unclear link text, they need better examples. If contrast is repeatedly too weak in campaign modules, the options in the publishing solution should be limited. Accessibility becomes more robust when the right practice is the easiest practice.

A regular publishing check does not replace thorough audits and user testing. It does, however, reduce the number of new barriers introduced in day-to-day work. It is often the most practical way to keep an accessible website accessible.