Maintain accessibility: regression tests after updates and ownership

Accessibility does not automatically survive an update. To keep navigation, forms and essential tasks accessible, you need a maintenance programme with three mandatory elements: risk-based testing before release, clearly assigned ownership and documented retesting of fixes. Automated checks provide quick signals; keyboard tests, screen reader checks and editorial reviews supply additional coverage. What matters is not how many tests run, but whether relevant user journeys and their error states are actually examined.

This article describes such a programme for websites and digital services. All workflows and failure examples presented here are hypothetical. They show how to turn a one-off audit into a reliable maintenance practice without mistaking a clean test report for complete legal compliance.

1. Establish the testing target and scope first

Document which website, applications, documents and integrated services your programme covers. Include the languages, authenticated areas and mobile views that belong in scope. From a customer's perspective, an online shop does not end at the handover to a payment provider. Your maintenance programme must therefore show which parts you can change directly and which depend on external suppliers. A list of URLs alone is insufficient: variants, states and complete tasks also belong in the testing scope.

WCAG 2.2 at conformance level AA can serve as a technical testing target. This includes applicable requirements at levels A and AA. However, WCAG 2.2 and EN 301 549 are not interchangeable, and a technical audit is not a complete legal compliance assessment. Austria's BaFG has applied to covered services since 28 June 2025, not automatically to every website. For scope, exemptions and distinctions, consult our guide to accessible websites in Austria. Record the agreed technical target in your maintenance plan separately from this legal assessment.

2. Distribute ownership across the release process

Appoint someone to coordinate the maintenance programme, but do not make that person the sole testing checkpoint for every change. Product ownership determines scope and release decisions. Development teams protect behaviour and semantics. Quality assurance organises manual checks and evidence. Editors review new content and documents. External services need an owner who follows up defects with the supplier. Every responsibility needs a deputy so that holidays or staff changes do not create gaps in testing.

In a hypothetical team, the release owner might check that all required evidence is available before each release. They do not need to perform every screen reader test themselves. Their job is to identify missing checks, make unresolved risks visible and apply the release rule. Record these responsibilities in the same system as other release tasks. A separate document disconnected from tickets and deadlines is easily overlooked in daily work. Decisions to postpone work also need a named owner, a rationale and a date for reconsideration.

3. Assess changes by risk, not just size

A small code change can block many people, while an extensive text correction may introduce little interaction risk. Assess which functions and shared components are affected. Navigation, authentication, search, forms, dialogs, payment flows and global design settings deserve particular attention. Updates to a CMS, extension or consent service can also change focus order and accessible names even when your team has not modified its own functionality. Put these triggers directly into your change template.

Assign a traceable testing requirement to each change. A correction to article copy might require an editorial review of the affected content. A change to a shared form component additionally requires automated component tests and manual checks of representative forms. Replacing a booking service requires a complete booking journey, including errors and confirmation. If the effects are unclear, investigate dependencies first rather than assuming a narrow testing scope. The rationale for your chosen coverage belongs in the release evidence.

4. Define release gates with verifiable conditions

A release gate is a condition for approval, not an optional reminder. State precisely which evidence must be available: successful automated checks within the agreed scope, completed manual tests for affected journeys and resolved decisions on new findings. An internal rule might require blocking a release when a new defect prevents completion of an essential task without an accessible alternative. This rule should also apply when the defect originates in a library rather than your own code.

A hypothetical security hotfix needs a predefined exception process. This might permit a reduced testing scope followed by mandatory additional checks. Document the omitted tests, the accountable decision, any rollback plan and a specific deadline. Internal acceptance of a risk does not make an existing barrier technically conformant or legally permissible. After deployment, also check the production environment: configuration, cached assets and the third-party scripts actually loaded can differ from the test system.

5. Build automated coverage deliberately

Automate repeatable checks at several levels. Component tests can verify expected labels and states. Integration tests examine assembled forms. Browser-based tests open key pages and relevant states before an evaluation tool examines the rendered document. Test the dialog when open, not only when closed; test the form with error messages, not only when empty. A scan reaches only the states that your test setup actually creates.

The W3C WAI guidance on selecting evaluation tools explains the limits of automated assessment. A tool may detect that an image alternative exists, for example, without reliably determining whether it is appropriate for the content. Similarly, a scan without findings does not prove that a booking process is understandable and usable. Document the boundaries of your coverage alongside its results. Track known findings individually: suppressing entire rules can hide new regressions. Updates to testing tools themselves also need a controlled introduction.

6. Make short manual smoke journeys mandatory

A smoke journey is a short, representative user path for detecting serious failures early. It does not replace a full audit. Choose journeys based on the actual tasks your users perform and keep their steps stable enough for comparisons. Also specify which browser, device and screen reader combinations will be used. This selection should suit the application and its users, and should be reassessed after fundamental technical changes.

1. Starting on the home page, use only the keyboard to reach search, enter a term, open a result and return to navigation.
2. Complete a form while deliberately omitting a required entry, locate the error, correct it and perceive the confirmation.
3. Open a dialog, operate its contents, close it and continue from a meaningful starting point.

Supplement these journeys with targeted screen reader checks and text-resizing and reflow tests. Functionality must remain available when text is resized to 200 per cent; reflow is tested at 320 CSS pixels wide for the relevant requirements, with their specified exceptions. Record the expected behaviour and result for each step. “Keyboard tested” is inadequate evidence if it remains unclear whether the error message, focus behaviour and task completion were included.

7. Explicitly test error states and focus

Suppose an update adds client-side validation to a contact form. Invalid fields subsequently receive only a red border, and previously entered information disappears on submission. A test limited to successful submission would miss both problems. The correction should provide understandable error messages, a clear association with each field and preservation of input that can reasonably be reused. The W3C WAI Forms Tutorial provides guidance on labels, grouping, instructions and feedback. Acceptance evidence should show how users identify the error and correct it without unnecessary repetition.

A second hypothetical example concerns an updated confirmation dialog. Focus accidentally remains on the page behind it. Check initial focus, tab navigation within the modal, dismissal with Escape and meaningful focus restoration. The ARIA Authoring Practices Guide: Dialog (Modal) Pattern describes this interaction pattern. ARIA attributes alone do not implement the behaviour. Acceptance therefore requires actual keyboard operation and screen reader output, rather than merely checking roles in the source code.

8. Write bug reports around reproduction and impact

A useful ticket contains the page or component, build version, test environment, prerequisites and precise reproduction steps. Then describe the expected and observed behaviour and the impact on the task. Add a relevant success criterion when that mapping is well supported. Screenshots, short recordings or relevant accessibility tree extracts can help, but do not replace a reproducible description. Use test data and remove personal information from supporting evidence.

Prioritise by impact, reach and available alternatives. An inoperable completion button in an essential flow warrants different treatment from an imprecise heading on a rarely used subpage. The WCAG level alone does not determine defect priority: failures of an A criterion can have different practical effects. Keep technical severity separate from the planned order of work. If you offer a temporary alternative, test it too. A telephone contact is not automatically an equivalent solution for every person or task.

9. Include editorial changes and documents

Editorial approval needs its own checkpoints: informative headings, understandable link text, suitable image alternatives and clear table structures. Review content in its actual template, not exclusively in the CMS input field. A hypothetical teaser may appear clear in the editor but produce several identically named links on the page. For images, the appropriate alternative depends on purpose: decoration, information and linked functionality require different treatment. A fixed character limit cannot replace that decision.

Establish a separate workflow for new or replaced PDFs. Visual inspection and text extraction are insufficient to assess reading order, structure or meaningful keyboard navigation. For tables, relationships between headings and data must also be available in an understandable way. In its work for FFG, Zensations evaluated websites and tools and delivered editorial workshops that included PDFs. This connection matters for maintenance: editorial rules need to be practised within the actual publishing process so that the same errors do not return with every new file.

10. Manage the component library and external vendors together

Maintain a documented interaction contract for shared components. It should describe accessible names, states, keyboard behaviour, focus management and permitted variants. A form field should, for example, be demonstrated with help text, a required-field indicator, an error message and a disabled state. This avoids testing only an isolated ideal configuration. Changes to design tokens also require regression testing because they can affect contrast, focus indicators or wrapping in many places simultaneously. Version notes should identify affected consumers of the component.

Bring external suppliers into the same process. Agree on available test environments, change notifications, reporting channels and responsibility for corrections. Request concrete testing evidence for relevant user journeys rather than relying exclusively on general accessibility statements. If an embedded appointment tool changes without notice, monitoring needs to cover that transition too. For unresolved issues, document escalation, any tested alternative and the next decision. A technical dependency explains a problem but does not remove its effect on users.

11. Follow user feedback through to retesting

Provide an accessible reporting channel that is easy to find. Ask about the affected task, page and observed behaviour, with optional details about the browser or assistive technology. Do not require a diagnosis or information about a disability to investigate a defect. Acknowledge receipt and explain what happens next. If your team cannot initially reproduce an issue, the report remains relevant: settings, content, device combinations or a changing service may explain the difference.

Close tickets only after retesting the corrected build. Repeat the original steps and examine neighbouring states: a repaired error message must not, for example, create duplicate screen reader announcements. Record the version, environment, result and tester. For recurring problems, add an appropriate regression test or revise the editorial rule. A second reviewer is useful for complex findings. Tell affected users about the correction without transferring responsibility for technical acceptance to them.

12. Review the maintenance rhythm and its effectiveness

Combine event-driven testing with scheduled checks. Relevant releases trigger agreed tests; major rebuilds require broader reassessment. In addition, your team can sample areas that have remained unchanged for some time and external services at an established interval. This is an organisational recommendation, not a universal monthly or annual audit obligation under WCAG. The W3C WAI recommendations for sustaining accessibility connect ongoing monitoring with publishing checks, root-cause analysis and training.

Do not assess effectiveness solely through open ticket counts. Ask which critical user journeys have documented testing coverage, which defects recur and where ownership remains unclear. Use those findings to revise test cases, components and working instructions. A growing number of identified problems may initially reflect better coverage; an empty issue list may conceal untested areas. The decisive factor is a traceable connection between change, testing, decision and correction. This also keeps the programme workable when team members change.

Frequently asked questions

Does every text update require a full audit?

No. Review the affected content and templates according to risk. If shared behaviour or an essential task changes, expand the scope accordingly.

Is an automated scan before release enough?

No. Automated tools cover only part of the requirements. Manual checks must supplement them, particularly for operability, focus management and understandable feedback.

Who can approve a release?

An explicitly appointed release owner should decide using agreed evidence. Specialist checks remain with the responsible roles, and unresolved risks are documented.

When is a defect genuinely closed?

When the correction has been retested in the relevant build, the result documented and appropriate checks of neighbouring states completed.

Next step: make your maintenance programme concrete

Zensations is a digital studio founded in Vienna in 2010. If you lack a reliable baseline, an accessibility audit can help establish testing areas and priorities. To develop your process further, our accessibility services provide a setting to discuss suitable ownership, release gates and retesting. Bring your release workflow, essential user journeys and known findings to the conversation. The goal is a verifiable process, not a blanket guarantee of conformance.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: Selecting Web Accessibility Evaluation Tools
• W3C WAI: Forms Tutorial
• W3C WAI: ARIA Authoring Practices Guide – Dialog (Modal) Pattern
• W3C WAI: Sustain Accessibility

Content reviewed: 7 November 2026.