Accessibility Regression Checks: Protect Working Website Journeys

Protect tasks that already work

Accessibility regression testing asks whether a release has broken an established journey. Start with concrete tasks: locate a service, open a menu, read an article and send a valid enquiry. Identify components shared across those tasks. A new design token or dialog can affect several pages at once. Record the last reviewed behaviour and the conditions under which it worked. Without that baseline, a team may debate appearance while failing to notice a lost keyboard route.

Choose fixtures that expose variation. Include a long heading, several menu levels, an invalid form and a status change. Shared components can behave differently with real text or a narrow layout. Keep the test pages representative rather than using only an idealised component gallery. Component checks are useful, but they do not prove that the assembled article or contact journey preserves meaning and usable interaction.

Separate automated findings from task evidence

W3C evaluation guidance describes the need for a considered testing approach. Automation can identify particular issues quickly, but it does not replace human judgement about a complete experience. Agree which checks run routinely and which manual tasks accompany significant changes. Keep their conclusions separate: a tool reporting no detected violations is not the same statement as a reviewer successfully navigating every required journey.

Map affected changes to tests. A menu update needs open, move, close and destination checks. A typography change needs long-text and zoom review. A form refactor needs labels, errors and status verification. Do not run an enormous undirected checklist after every tiny change while omitting the specific task most likely to break. The regression set should focus effort while preserving a documented broader evaluation process.

Observe focus through state changes

Use the keyboard to enter a dialog, operate its controls, dismiss it and continue. Check visible focus and its location after closure. Review menus that appear on hover to ensure the intended keyboard route exists. Inspect whether a new sticky element obscures the focused control. Test a validation failure without a pointer. A visually polished message can still leave a user unable to locate the field requiring correction or understand the next action.

Review structure and text presentation

Inspect heading relationships, meaningful labels and the order of the information. A refactor can preserve the look while changing markup or removing a useful label. Check larger text and narrow presentation using the supported review method. Essential headings should not disappear under fixed-height clipping. Images and icons need an appropriate text treatment for their role. Decide whether a symbol is decorative or carries information before choosing its accessibility implementation.

Hypothetical case: a new global contact panel

Imagine a shared contact component adds floating call and chat actions to every page. The desktop screenshot looks good, but the mobile button overlaps the last form control and the keyboard focus indicator is obscured. Review the actual form task, not only the component isolated in a story. Correct positioning and repeat the route on an older long article as well as the new contact page. This scenario illustrates the reach of a shared regression.

Include the panel disabled or unavailable state when testing. If its chat action fails to open the expected destination, the visible label should not imply a sent enquiry. Check the adjacent address and email presentation for wrapping and reading order. Preserve the previously usable alternative route. The regression record should identify which failure was reproduced and which release corrected it, rather than simply marking the entire site accessible after a cosmetic fix.

Keep evidence tied to the release

Record version, test fixture, input method and observed result. Triage barriers separately from visual preferences and assign remediation ownership. Repeat affected tasks after the fix. Where specialist evaluation identifies broader issues, keep them visible rather than allowing a passing automated run to erase them. A maintained regression workflow is especially valuable when code is generated or refactored quickly: production speed does not remove the need to preserve working user journeys.

Preserve the regression task record when a component is replaced. The new implementation may need different test steps, but the customer goal remains. Do not discard a useful keyboard journey simply because the underlying framework changed.

Practical checklist

• Choose representative navigation and enquiry tasks.
• Map component changes to relevant tests.
• Review focus, labels and text presentation manually.
• Record findings against the actual release.

Frequently asked questions

Related Articles