Accessibility is part of every design and release decision. Build a service that people can understand, navigate and complete with different devices, input methods, languages and assistive technologies.

Start with a clear, inclusive journey

Give every page one clear purpose. Use familiar language, meaningful page titles and a sequence that matches the way people think about the task. Ask only for information the service needs. Standard Builder components and patterns provide a sound starting point because their labels, errors and interactions are designed to work together.

Do not treat a standard component as automatic proof that a service is accessible. Your wording, content order, validation, conditions, actions, styling and integrations can still create barriers. Check the whole journey from the participant’s point of view.

Write content that works for everyone

• Use a descriptive heading and label for every question or input.
• Use hint text for useful supporting detail, not as a replacement for a clear label.
• Write errors that identify the problem and explain how to correct it.
• Use headings, paragraphs and lists to show structure; do not rely on bold text or spacing alone.
• Make link text meaningful when read out of context.
• Do not rely on colour, position, shape or an icon alone to communicate an instruction, status or error.

Choose components with care

Choose the simplest component that matches the answer. For example, use a focused text input for a short answer and visible choices for a small set of options. Avoid a rich interaction simply because it looks impressive. Uploads, maps, signatures, drag-and-drop controls, complex tables and custom HTML can introduce barriers or require an alternative route.

When a specialist interaction is necessary, explain what is required before the person starts, provide an equivalent way to complete the task where possible, and test that alternative with the people who need it.

Make navigation predictable

Continue, Back, task-list links, review-page change links and conditional routes should do what people expect. A person should not lose work or be taken to an unrelated page because an answer changes. Test the normal route and every significant alternative route, including going back after an error or review.

Use conditions to remove irrelevant questions, not to conceal essential information. When a route changes, make sure the next visible page explains what the person needs to do and that any validation applies only to questions they can see.

Test beyond the Builder canvas

Use User view and QA to test the rendered service. Automated checks are useful, but they do not find every issue. Combine them with manual checks and, where possible, research or testing with disabled people and people who use assistive technology.

Important: Test generated PDFs, emails and connected-service pages as part of the participant journey. A service is not fully accessible if a required document, message or downstream step creates a barrier.

Accessibility testing lifecycle

flowchart LR
    A["Design the journey"] --> B["Build with standard components"]
    B --> C["Test in User view"]
    C --> D["Keyboard, zoom and assistive technology checks"]
    D --> E["QA end-to-end testing"]
    E --> F["Publish or update the accessibility statement"]
    F --> G["Monitor and improve after release"]

Publish an accurate accessibility statement

In Service settings, open Accessibility statement. The Builder offers options to use a platform-provided template, enter custom text, link to a statement hosted elsewhere, or omit the statement. You can also open the statement in Prototype to review what people will see.

Choose the approach that fits your organisation’s responsibilities, then keep the statement accurate. It should explain the service covered, its current accessibility status, known issues, contact route for accessibility feedback, any available alternative formats, and when the statement was prepared or reviewed. Update it after a significant change or new test finding.

Accessibility release checklist

1. Check the content, labels, headings, hints and errors in User view.
2. Test keyboard use, focus order, zoom and narrow screens.
3. Run suitable automated checks and investigate every meaningful result.
4. Test with assistive technology and, where possible, with the people who will use the service.
5. Check documents, emails, downloads and integrated steps.
6. Publish or update the accessibility statement and record the evidence.

Related guides

• Add and configure components
• Use Markdown and HTML
• Test, deploy and maintain a service