From WCAG to a publication-ready page: Create a consistent accessibility check

Category: Web accessibility

WCAG can be difficult to apply directly in a busy publishing workflow. The guidelines describe what should be possible, but do not necessarily say how the marketing team, designer and developer should work together before a new page is published.

A more manageable approach is to make accessibility a standard approval check. The goal is not to carry out a full audit of the entire website every time. The goal is to catch common barriers while they are still easy to fix.

The check should follow the actual user task on the page. Can a visitor understand the content, navigate without a mouse, use a screen reader and complete a form without getting stuck? This makes WCAG a practical working tool, not just a list of requirements.

Start with the user task, not the checklist

First decide what the user should be able to do. On a contact page, the task might be to find the right department and submit an enquiry. On a product page, it might be to understand the offering, choose a variant and add the product to the shopping cart.

Describe the task in one sentence and test the entire process. Individual components may work in isolation while the overall journey is difficult. For example, a form may have correct field labels but come after an illogical sequence of menus, tabs and boxes when the page is used with a keyboard.

Also clarify who is responsible for what:

• The editor checks headings, link text, alternative text and clear instructions.
• The designer checks contrast, visual states, order and placement.
• The developer checks semantics, keyboard functionality, focus management and technical feedback.
• The product owner decides whether serious errors should prevent publication.

This division of responsibility prevents accessibility from becoming an unclear responsibility that everyone assumes someone else is taking care of.

Check 1: Is the content clear and correctly structured?

Start without special tools. Read the page from the top and assess whether the headings, paragraphs and action buttons make sense. Headings should describe the content beneath them, not merely serve as large decorative text.

A clear heading structure makes the page easier to scan visually and easier to navigate with assistive technologies. Do not choose heading levels based on the desired font size. The appearance should be controlled by the design, while the level should reflect the content hierarchy.

Also check the following:

• Link text tells users where the link leads, even without the surrounding paragraph.
• Buttons describe the action, for example “Submit enquiry” rather than “Click here”.
• Instructions do not rely solely on colour, placement or shape.
• Images that convey information have alternative text serving the same purpose.
• Decorative images are not read aloud unnecessarily.

Alternative text should describe the function of the image in context. A portrait next to contact information may identify the person. The same portrait used purely as decoration does not need a detailed description of the clothing, background and lighting.

Check 2: Can the page be used with only a keyboard?

Put the mouse aside and use the Tab key, Shift+Tab, the arrow keys, Space and Enter. Go through the entire task from start to finish.

Pay particular attention to where the keyboard focus is. A visible focus indicator is necessary to know which element will be activated. The indicator must stand out clearly against the background and not disappear because a design rule has removed the default styling.

Check that:

• All links, buttons and form fields can be reached.
• The order follows an understandable path through the page.
• No component traps the keyboard so that the user cannot continue.
• Dropdown menus, dialog boxes and accordions can be opened and closed.
• Focus moves sensibly when content is opened, closed or updated.
• Hidden content does not receive focus.

Do not approve a component simply because the Tab key reaches it. The user must also be able to understand what the component does, activate it and move on afterwards.

Check 3: Does the design meet real contrast needs?

Low contrast often occurs in muted body text, placeholder text, secondary buttons and text over images. The problem is often greater on mobile, in sunlight or on screens with different settings from those used by the designer.

As a practical starting point, regular text requires a contrast ratio of at least 4.5 to 1, while large text can have a ratio of at least 3 to 1. But the check must cover more than text. Can users see the boundaries around form fields, selected states, error messages, icons and focus indicators?

Colour should not be the only means of conveying information. An invalid field should have an explanatory error message, not just a red border. A chart should use labels or patterns in addition to colour differences.

Build approved colour combinations into the design system or template. This saves editors from having to assess the contrast of every button and information box from scratch. At the same time, limit the ability to choose arbitrary text and background colours in the publishing tool.

Check 4: Does the page make sense with a screen reader?

A screen reader test reveals problems that are not visible. Elements may look correct but be presented with the wrong role, a missing name or an incomprehensible order.

Test the most important task with a screen reader suited to the operating system you use. Listen for whether the page has a clear title, whether the heading list provides an understandable summary, and whether buttons and links have meaningful names.

Pay particular attention to dynamic changes. If a product is added to the shopping cart or a form is rejected, the feedback must be accessible without requiring the user to search through the entire page again. Visual text alone is not always sufficient if focus and technical notifications are not handled.

The screen reader test should not, however, be reduced to a sighted tester listening once. For important services, feedback from users who actually use assistive technology is valuable. They often discover friction that a technical check does not reveal.

Check 5: Can the form be completed and corrected?

Forms are common stopping points because several requirements come together: language, contrast, keyboard access, labels, validation and feedback. Therefore, test both a successful submission and a submission containing errors.

Each field must have a visible, programmatically associated label. Placeholder text is not a substitute for a label. It disappears when the user types, often has weak contrast and can make it difficult to remember what the field was for.

When something is wrong, the message should explain both the problem and how it can be corrected. “Invalid value” is not very useful. “Enter the phone number using eight digits” provides a concrete way forward.

Also check that:

• Required fields are clearly marked using more than colour alone.
• Fields use the correct type and support the expected input.
• The error message is placed near the field and can be detected by a screen reader.
• The user does not lose previously entered information after an error.
• Focus is moved to or directed towards the error summary in an understandable way.
• The submit button does not remain without clear feedback.

Also test zoom and small screens. A form that works on a large screen can become difficult to use if labels, fields and error messages overlap or require horizontal scrolling.

Make the findings possible to prioritize

A long list of issues is of little help if no one knows what needs to be fixed first. Describe each finding in terms of the user, action and consequence.

A good finding could be phrased as follows: “A keyboard user can open the menu but cannot proceed to the submenu links. This prevents access to the product pages.” This makes both the problem and its impact clear.

Divide the findings into three practical levels:

1. Blocks publication: The user cannot complete the central task, understand critical information or exit a component.
2. Should be fixed quickly: The task can be completed but requires an unnecessary amount of effort or creates considerable uncertainty.
3. Improvement: The change makes the experience clearer and more robust, but the current solution provides a functioning way forward.

Severity should be assessed based on the consequence and how many pages or tasks the error affects. An error in a shared menu or form component is more important than the same type of error on a rarely used page, because the component error is repeated throughout the website.

A publishing check that is actually used

Keep the check short enough to be carried out and clear enough to identify real barriers. A practical routine can consist of five steps:

1. Describe the page’s most important user task.
2. Check the content, headings, links and alternative text.
3. Complete the task using only the keyboard.
4. Check contrast, zoom, mobile display and the form’s error states.
5. Test the main flow with a screen reader and document any stopping points.

Save the result alongside the page’s other quality assurance records. Note which template, component or content type the error concerns. This allows the team to fix the cause instead of repairing the same error page by page.

Accessibility is most effective when it is part of the definition of done. It should be included in design decisions, component development, content work and approval. A regular accessibility check before publication does not automatically produce an error-free website, but it makes barriers visible early and places responsibility where the errors can actually be fixed.