The web accessibility launch gate: Six tests before publishing the website

Accessibility is often checked too late. The design has been approved, the solution has been developed, the content has been added, and only just before launch does someone discover that the menu cannot be used with a keyboard or that form error messages are not read aloud.

A better approach is to establish a fixed launch gate. No new page type, component or important customer journey is published until it has passed a small set of accessibility tests. This makes WCAG work more concrete and reduces costly fixes after launch.

WCAG must be translated into verifiable requirements

WCAG describes what an accessible web solution should achieve. The guidelines are necessary, but they work poorly as the only project checklist. Designers, developers, content creators and product owners need requirements that can be verified on the actual website.

A general requirement such as “the website must comply with WCAG” should therefore be supplemented with acceptance criteria such as these:

• All interactive elements can be accessed and operated with a keyboard.
• It is always visible which element has keyboard focus.
• Text and important graphical elements have sufficient contrast.
• Headings, links, buttons and form fields have understandable names.
• Form errors are identified and explained in text.
• The content makes sense when read with a screen reader.

Such criteria can be used during design reviews, development, content work and final checks. They also make it easier to determine whether something is actually ready for publication.

Test 1: Put the Mouse Aside

Start with the keyboard. Reload the page and use Tab to move forward. Use Shift and Tab to move backward. Enter and the spacebar should activate relevant links, buttons and controls. Arrow keys are used in some components, including menus, tabs and selection groups.

Check three things along the way. First, all functions must be accessible. Next, the order must be logical. Finally, focus must be clearly visible. A weak outline that disappears into the background is not sufficient for a user who needs to see where they are on the page.

Pay particular attention to drop-down menus, dialog boxes, search, filters, carousels and custom selection components. These are areas where solutions designed for mouse clicks often fail.

When a dialog opens, keyboard focus should move into the dialog. The user must be able to operate its content and close the dialog without a mouse. When it closes, focus should return to the element that opened it.

Test 2: Check contrast in real-world states

Contrast checking is about more than regular body text on a white background. Also test small text, text over images, menu items, help text, placeholders, icons and graphics that convey information.

The check must cover all states. A button may have good contrast before it is activated but become difficult to see when it receives keyboard focus or is disabled. A link may be clear initially but nearly disappear after it has been visited.

Do not use color as the only signal. A red field around a form control says little to someone who cannot perceive the color or who uses a screen reader. Combine color with text, an icon or another visible indicator. The same applies to status messages, charts and selections in an ordering process.

Contrast should be measured with a suitable tool, not judged by eye. At the same time, the overall visual experience must be tested on real screens and mobile phones. Reflections, low brightness and small screens can make an apparently clear solution difficult to use.

Test 3: Listen to the page with a screen reader

A screen reader test reveals problems that are not visible. Users receive information through structure, names and order, not through positioning and visual design.

Start with the page title and headings. Do they provide an understandable overview? Then move between links. Link texts such as “read more” and “click here” often lose their meaning when presented without the surrounding text. Instead, use descriptions that explain where the link leads.

Check buttons, images and icons. A button must have a name that describes its action. An icon that opens search on its own must be announced as search, not as a file name or an incomprehensible symbol. Informative images need a text description, while purely decorative images should be ignorable.

Also test whether the content is read in a logical order. Visual positioning with CSS can create a different order from the one in the code. The result may be that an explanation is read after the button it was meant to explain.

Test 4: Submit the form incorrectly on purpose

It is not enough to fill out the form correctly. The most important accessibility problems often appear when the user makes a mistake.

Submit without filling in required fields. Enter an incorrect format in the email field. Select a combination that is not allowed. Then check whether the error is detected, explained and associated with the correct field.

An accessible form needs visible labels that explain what each field is for. Instructions must appear before the user needs them. Requirements for date format, passwords or organization numbers should therefore be displayed next to the field, not shown for the first time after an unsuccessful submission.

When the form is rejected, the user should receive a brief summary and specific messages next to the relevant fields. Keyboard focus must be managed so that the error is easy to find. The message “invalid value” is rarely enough. Explain what needs to be corrected.

Finally, check the confirmation. It must be clear that the submission has been received, what happens next and whether the user needs to do anything else.

Test 5: Zoom in and change the view

An accessible page must withstand users enlarging the text or the entire interface. Therefore, test the page at significant zoom on a standard computer screen and check it in a narrow mobile view.

Look for text that becomes hidden, buttons that end up off-screen, horizontal scrolling and menus that cover the content. Also check that users do not have to scroll in two directions to read ordinary text.

Components with fixed heights often cause problems. A short button label may fit in the design mock-up but be cut off when the text is enlarged or replaced with a longer formulation. Flexible surfaces and sufficient space around the content make the design more robust.

Test 6: Check language and comprehension

Technical accessibility is not enough if the content is difficult to understand. Use clear headings, short paragraphs and concrete action words. “Submit request” is more precise than “Continue” when that is what the button actually does.

Explain technical terms that the target audience cannot reasonably be expected to know. Avoid hiding important choices behind internal terminology. Information about pricing, commitment periods, deadlines and consequences should appear close to the action it relates to.

Also read the page without looking at the images. If important information is available only in an illustration, video or colour code, it must have a textual alternative. Videos with speech need captions, and important visual content must be understandable to people who cannot see it.

Assign responsibility before testing begins

The release gate only works when someone is responsible for each area. The designer should check contrast, focus indicators and visual states. The developer should test semantics, keyboard operation and technical support for assistive technologies. The content creator should check headings, link text, image descriptions and language. The product owner must decide whether critical errors should block publication.

Record deviations with a screenshot, the page or component involved, how the error can be reproduced, and who is affected. Prioritise problems that prevent users from completing a task. A button that cannot be activated with a keyboard is more critical than a minor unevenness in the text.

Make the gate small enough to be used

A comprehensive audit has its place, but daily quality assurance must be feasible. Create a fixed checklist for new templates, components and key customer journeys. Run it before the first publication and after major changes.

Automated tests can find some errors, but they cannot determine whether the focus order is logical, whether an error message is understandable, or whether the screen reader experience is coherent. Therefore, combine tools with manual use of the keyboard, screen reader and magnified view.

The goal is not to collect as many checkmarks as possible. The goal is for more people to be able to understand the content, navigate the page and complete the task without unnecessary barriers. When this check becomes a real release gate, accessibility becomes part of the deliverable instead of a cleanup exercise afterwards.