Web accessibility after launch: Build a publishing routine that lasts

Category: Web accessibility

A website can be well designed for accessibility on launch day and still become more difficult to use over time. New campaign pages are added, editors place text over images, form fields are changed, and links are given names like “Read more”. Each individual change may seem minor, but together they can create real barriers.

That is why web accessibility should not only be a check developers carry out before launch. It must be part of the ongoing publishing routine. The goal is not for every editor to become a WCAG expert, but for the organisation to know which choices affect accessibility, what needs to be checked, and who handles errors.

Translate WCAG into practical tasks

WCAG describes requirements and principles for accessible web content. The guidelines cover, among other things, text alternatives, contrast, keyboard operation, structure, error messages and understandable navigation. For a content editor, the language of the requirements can nevertheless be too technical to work as a daily checklist.

A practical publishing routine should therefore translate the requirements into specific questions:

• Does the page have a clear and logical heading structure?
• Do the link texts describe where the links lead?
• Do meaningful images have a useful text alternative?
• Can the content be understood without distinguishing between colours?
• Are text and important interface elements easy to see?
• Can the page be used with a keyboard?
• Are the form fields, instructions and error messages understandable?

This makes WCAG actionable. The editor gets a manageable check, while designers and developers can own the more technical aspects.

Distribute responsibility between the system, templates and content

Many accessibility errors arise because no one knows who is responsible. A good model distinguishes between three levels.

System level

Developers are normally responsible for code, keyboard order, visible focus indicators, semantic components and support for assistive technologies. An editor should not have to edit HTML to make a button work with a keyboard.

Template and component level

Designers and developers should build components that make the right choices easy. A form field should have space for a label, help text and an error message. A card component should require understandable link text. The colour palette should limit combinations that result in poor contrast.

Content level

The editor owns headings, link texts, image descriptions, tables, video information and clear language. The publishing solution can support this work, but cannot determine whether a text alternative actually conveys the image’s function.

This division prevents the editorial team from being held responsible for technical errors it cannot fix, while also relieving developers of the need to quality-assure every word that is published.

Perform a quick keyboard check

Keyboard navigation is a simple and useful manual test. It reveals problems that automated tools often cannot fully assess. Use the Tab key to move through interactive elements, and try to complete the page’s most important task without a mouse.

In particular, check that:

• it is visible which element has focus
• the order follows an understandable path through the page
• menus, buttons, dialog boxes and forms can be operated
• focus does not become trapped in a component
• hidden content does not receive focus
• the user can continue after a message or dialog has been closed

Test the actual task, not just whether the Tab key moves focus. On a contact page, this means opening any available options, completing the form, handling an error and submitting it. On a product page, it may mean selecting a variant and adding the item to the shopping cart.

If the focus indicator is missing or the order is illogical, this is usually a technical error that should be passed on to a developer.

Check contrast where the content is actually used

Contrast is not just about black text on a white background. Problems often arise in banners, text over photographs, light grey help text, buttons with subtle borders and information that is shown only on mouse hover.

Colour combinations should be quality-assured in the design system. Nevertheless, the editor must check the result when the background varies. White text may be clear over one part of an image and almost disappear over another.

Also avoid using colour as the only means of conveying information. A required field should not only be given a red border. Add clear text explaining what is missing. In a chart, series should be distinguishable through labels, patterns or symbols, not just colours.

A sensible editorial rule is to use approved combinations and avoid freely placing text over images. This reduces the need for manual contrast assessments.

Write and structure content for screen readers

A screen reader conveys content through speech or braille. Users can navigate by headings, links, form fields and landmarks, among other things. Visual positioning alone is therefore not enough to show what belongs together.

Start with a logical heading structure. Headings should describe the content and create an understandable outline. Do not choose heading levels based on the desired font size. The design should control the appearance, while the level should express the structure.

Link text must make sense without the surrounding text. Multiple links called only “Click here” or “Read more” provide little information when read as a combined list of links. Instead, write “See pricing for the business agreement” or “Download the annual report”.

For images, the alternative text must be determined by the image’s function. An image showing an important step in a guide needs a description of the information the user should receive. A purely decorative image should normally not create unnecessary speech. Do not repeat the caption word for word if the same information is already provided next to the image.

A brief screen reader check can provide valuable insight, but the tool requires practice. Start with a few key page types and standard tasks. Listen for unclear button names, repetitions, missing field labels and headings that do not describe the content.

Forms must help users both before and after errors

Forms are often where accessibility problems have the greatest consequences. If users cannot submit an enquiry, apply for a job or complete a purchase, the website has failed at a central task.

Each field should have a visible and precise label. Placeholder text inside the field is not a good substitute because it disappears when the user starts typing and often has low contrast. Instructions should be provided before the user needs them. If a password or organisation number must follow a specific format, this must be explained in advance.

When errors occur, the form should:

• explain what is wrong in text
• identify which field the error applies to
• explain how the error can be corrected
• preserve information that has already been entered
• move or direct attention so that the error is noticed

“Invalid value” is rarely sufficient. “Enter the phone number using eight digits” is more specific. Also test that the error message is perceived with a keyboard and screen reader, not just that it looks right on the screen.

Create a publishing check that is actually used

A checklist with dozens of items is easily skipped. Instead, divide the check into two levels.

Checks during routine publishing

1. Read the page and check the heading order.
2. Review link text and button names.
3. Assess alternative text for new images.
4. Check text displayed on a coloured background or image.
5. Test new or changed forms with invalid input.
6. Perform the main task using a keyboard if the page has interactive elements.

Extended checks for major changes

New templates, components, navigation solutions and integrations should undergo broader testing by people with the appropriate expertise. This should include different screen sizes, keyboard navigation, screen readers, magnification, error handling and technical markup.

Automated tests can find some errors, but they cannot alone assess whether link text is understandable, whether the focus order is logical or whether alternative text conveys the right meaning. Therefore, combine automated checks with manual use.

Treat accessibility issues as ordinary quality defects

Issues should be recorded with enough information to reproduce them. Note the page, component, action, expected result and what actually happened. Also describe the consequence. “Light grey colour” is less useful than “the help text in the order form is difficult to read against the background”.

Prioritise issues that prevent important tasks, hide information or affect many pages. An inaccessible menu or form component is generally more important than a single missing alternative text on a decorative image.

The most robust solution is often to fix the component or template, not just the individual page. This removes the issue in multiple places and reduces the risk of recurrence.

Accessibility must be part of ongoing management

Maintaining good accessibility over time is a matter of governance. The company needs named owners, approved components, a brief publishing check and a clear process for technical issues. New editors should be trained in the choices they actually encounter in the publishing solution.

Start with the most frequently used pages and the most important tasks. Then make the check a regular part of publishing, campaign work and further development. This makes accessibility a feature of ongoing website management, rather than a quality that gradually disappears after launch.