Accessibility in a website relaunch: requirements and acceptance

Plan accessibility in a website relaunch as a dedicated quality workstream: with a defined scope, testable requirements, accountable people and acceptance checks throughout the project. A technical test shortly before launch can reveal problems, but it cannot replace accessible planning, procurement and implementation. What matters is whether users can complete entire tasks, not merely whether individual pages pass an automated test.

For custom corporate websites, this means examining the most important user journeys early, translating requirements into components and CMS rules, and agreeing on the necessary evidence before commissioning the work. This roadmap explains how to establish useful decision points. All project examples and failure scenarios below are hypothetical; they do not describe outcomes from actual client projects.

Content reviewed on 7 November 2026.

1. Establish the project objective and scope

Start with a scope decision that covers more than the main domain. Which language versions, subdomains, forms, downloads and embedded services belong to the relaunch? Are job applications handled externally? Will an existing customer portal remain unchanged? Document transitions to systems outside the delivery scope as well. Excluding a service does not remove it from the user journey; someone must still take responsibility for the associated risk.

A technical project objective could be WCAG 2.2 Level AA, including all applicable Level A and AA success criteria. The W3C’s WCAG 2.2 provides the normative foundation. EN 301 549 is not interchangeable with it, and a technical assessment does not establish complete legal compliance. Austria’s BaFG has applied to covered services since 28 June 2025, not automatically to every website. Our guide to accessible websites in Austria explains scope and exemptions; clarify that position before writing the technical specification.

2. Structure discovery around complete user journeys

An inventory of page types is useful, but insufficient. Also describe tasks through their entry point, decision, interaction and completion. One hypothetical journey could involve a prospective customer finding a service through search, comparing options, opening an enquiry form and receiving an understandable confirmation. Another could lead from a job advertisement to an external recruitment portal. Both journeys might use the same navigation while presenting very different risks.

For each journey, record the information required, the components involved and the evidence of successful completion. Consider keyboard operation, screen readers, magnification and mobile layouts. Interviews or moderated testing with disabled people can uncover usability barriers, but do not replace systematic assessment against the criteria. Discovery should produce a prioritised testing map: which tasks are business-critical, which technical patterns recur, and which dependencies need clarification before design begins?

3. Translate requirements into testable work packages

“Make it accessible” is not an adequate instruction for development or acceptance. Each relevant requirement needs a defined subject, expected behaviour, testing method and responsible role. Connect those details to the user journey and relevant success criterion. This turns a general intention into a backlog item that can be estimated, implemented and verified.

For a hypothetical enquiry form, the requirement could state that all inputs have programmatically associated labels, required information is explained before submission, and invalid values can be corrected without re-entering data that was already valid. Acceptance then involves more than a screenshot: it includes keyboard operation and checking the labels and messages exposed to assistive technology. Distinguish mandatory criteria from additional quality objectives. A fully visible focus indicator is a useful objective, for example; WCAG 2.2 AA’s Focus Not Obscured criterion specifically requires that focused components are not entirely hidden by author-created content.

4. Clarify responsibilities and procurement early

Appoint someone to coordinate the accessibility workstream without assigning every specialist task to that person. Design owns areas such as states and visual specifications, development owns technical behaviour, editorial teams own content, and project management owns decision points. Accessibility reviewers need access to work in progress and sufficient time to provide feedback. The person correcting an issue should not be the sole decision-maker on its final acceptance.

Include concrete evidence, test access, correction cycles and handover documentation in the procurement scope. Ask suppliers for more than a general accessibility statement: request verifiable information about the intended product version and integration. For a booking service, for example, it matters whether you can test the calendar, time selection, error messages and confirmation. Also agree who communicates with the manufacturer and what alternative is available if a significant barrier cannot be resolved in time.

5. Test the design system before expanding into pages

Check reusable patterns before they spread across numerous templates. Navigation, accordions, dialogs, cards, form fields and notifications need more than a default state. Specify focus, errors, selected options, disabled functions and long content. Text contrast must be at least 4.5:1 for normal text and 3:1 for large text; large means at least 18 points, or 14 points when bold. Relevant graphical information and component boundaries have separate contrast requirements where the criterion applies.

A hypothetical filter dialog illustrates why early interaction prototypes matter: it looks correct, but lets keyboard focus move behind the dialog. The correction concerns behaviour, not just appearance. The dialog pattern in the WAI-ARIA Authoring Practices addresses appropriate initial focus, keeping focus within the modal dialog, dismissal with Escape and meaningful focus restoration. ARIA attributes alone do not implement these functions. Evidence should include a reproducible interaction test on the component actually being used.

6. Develop CMS templates and editorial controls together

An accessible prototype does not protect against problematic CMS content. Define which heading levels, link variants, image fields and content combinations editors can use. Good templates enable meaningful semantic structures without requiring everyone to understand HTML. For example, avoid allowing the visual size of a heading to automatically create an inappropriate hierarchy. CMS help text should explain decisions rather than merely identify required fields.

Test each template with realistic edge cases: long headings, missing images, multiple links, translations and extensive tables. Check text resizing to 200 percent, reflow at 320 CSS pixels subject to the relevant exceptions, and the specified text-spacing adjustments without loss of information or functionality. That spacing test does not prescribe the default visual design. A template is ready for acceptance only when its permitted content variations also work. Document its limits and editorial rules, not just its ideal state.

7. Treat third parties as part of the user journey

Consent management, videos, maps, chat and recruitment platforms can block an otherwise well-implemented relaunch. Maintain a register identifying the product, version, integration method, responsible owner and affected user journeys. Test the actual integration: an accessible supplier demonstration does not prove that your configuration, theme or interaction with other scripts will work equally well. Include states before and after consent is given.

Suppose a hypothetical consent window entirely covers the focused submit button. The interaction must then be tested and corrected, perhaps through adjusted positioning or different window behaviour. A general reference to the external supplier is not sufficient for technical acceptance. Where an accessible alternative is necessary, it should enable an equivalent task as far as possible. A telephone number alone is not automatically an adequate replacement for a digital process intended to work at any time and without spoken communication.

8. Migrate content, forms and documents early

Plan content migration as quality work, not simply an import. Prioritise by usage and importance: service information, contact options, essential downloads and frequently used forms first. Review link purposes, text alternatives, table headers and language changes. Decorative images do not need descriptive alternative text; functional images must communicate their purpose. A blanket character limit for every text alternative is not a useful quality criterion.

The WAI Forms Tutorials provide practical guidance on labels, grouping and feedback. In a hypothetical failure, an invalid email address receives only a red border, and submitting clears the entire form. The correction adds an understandable, associated error message and preserves valid inputs. For migrated PDFs, also examine reading order, structure and table relationships where relevant. OCR can extract text, but does not create a complete document structure. Assign each critical document a decision: remediate it, replace it with accessible HTML or remove it from the new site for a documented reason.

9. Agree on a definition of done at several levels

A shared definition of done prevents “development complete” from being confused with “accepted”. At component level, it includes implemented states, documented operation and completed checks. At template level, content variations and responsive presentation are added. At journey level, the entire task must work, including external transitions and feedback. These levels need different evidence, but should feed into one shared status model.

Define in advance which unresolved findings block a decision point and who decides on remaining risks. An unreachable form submission has a different impact from a minor editorial ambiguity; the classification must be explainable. Internal approval despite a known deviation does not make that deviation conformant. Explicitly record exceptions, effects, owners and correction deadlines. Avoid blanket claims such as “passed WCAG” when only selected components or pages have actually been assessed.

10. Conduct acceptance testing with reproducible evidence

Agree on the testing environment before acceptance begins: build version, browsers, assistive technologies, screen sizes, test data and access credentials. Select representative templates and supplement them with every unique interaction pattern and critical user journey. A sample-based report must make clear what was examined and what was not. It must not imply a complete assessment of all content if that did not take place.

Automated checks help identify recurring technical errors. However, as the W3C explains in its guidance on selecting evaluation tools, tools cannot assess every aspect of accessibility. Add manual keyboard, screen reader, magnification and content checks. A robust finding includes its location, prerequisites, steps, actual and expected behaviour, affected requirement and supporting evidence. This allows developers to reproduce the problem instead of first having to guess which situation the reviewer meant.

11. Separate corrections, retesting and release

Explicitly reserve time in the schedule for corrections and reassessment. A closed development task is not evidence that a fix was successful. Retesting checks the same issue again under documented conditions, while neighbouring functions are examined for unintended effects. If a central component changes, regression testing must also consider its use in relevant templates.

A hypothetical fix for dialog focus restoration might, for example, point to a button that has disappeared after filtering. The retest must therefore cover the state following a change in results. Track findings using clear statuses such as open, ready for retest and confirmed fixed. Before launch, the responsible project manager receives a concise decision record: tested scope, unresolved barriers, impacts and next steps. Technical release and accessibility acceptance remain separate decisions.

12. Secure handover and ongoing quality

Hand over an operational model, not just files. Include component rules, CMS guidance, known limitations, test records and responsibilities for new content and changes. Train editors and developers using the actual website. An exercise creating a service page with an image, table and form link is more immediately useful than a presentation disconnected from the tools people use.

The WAI guidance on sustaining accessibility emphasises ongoing checks, training and addressing root causes. Establish a risk-based testing routine, for example when introducing templates, making major third-party updates or changing user journeys. WCAG does not prescribe a universal monthly or annual audit cycle. What matters is a reliable response to changes and feedback. A well-planned relaunch therefore leaves behind not just a website, but the ability to keep improving its quality.

Frequently asked questions about relaunch planning

When should the first assessment happen?

During the development of user journeys and component designs. Early checks prevent structural problems from spreading across every template. Assessment of the finished implementation is still necessary.

Is an automated scan sufficient for acceptance?

No. It provides partial findings, but neither assesses every criterion nor reliably evaluates complete tasks. Manual checks and documented evidence are also necessary.

Who is responsible for external services?

Assign an internal owner and establish the supplier’s obligations contractually. Third-party code must not become a reason to leave critical transitions untested.

How do we start if the relaunch is already underway?

First map the scope, critical journeys and reusable components. A focused accessibility audit by Zensations can provide findings for the next decisions. For requirements, implementation and handover, the digital studio founded in Vienna in 2010 offers accessibility services. The objective is a traceable improvement process, not a blanket guarantee of conformity.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 – normative success criteria and conformance requirements.
• W3C WAI: Forms Tutorial – forms, labels and feedback.
• W3C WAI: Dialog (Modal) Pattern – focus and keyboard behaviour for modal dialogs.
• W3C WAI: Selecting Web Accessibility Evaluation Tools – uses and limitations of automated tools.
• W3C WAI: Sustain Accessibility – maintaining accessibility in ongoing operations.