From user journeys to inclusive experiences: A11Y as a part of end-to-end testing

When people think about software quality, they often focus on functionality, performance, and security. Yet there is another equally important aspect that directly impacts millions of users, which is accessibility – often abbreviated as “A11Y”, where the number 11 represents the eleven letters between “A” and “Y” in the word accessibility.

According to the World Health Organization, approximately 1.3 billion people worldwide live with some form of disability, which equates to around one in every six people. Accessibility is therefore no longer a niche concern. It is a business necessity, a compliance requirement, and most importantly, a commitment to creating inclusive digital experiences. 

Many organisations have already adopted accessibility standards such as WCAG 2.2 and incorporated accessibility testing into their development and quality assurance processes. However, a critical question remains. Does testing individual pages and components alone provide enough confidence to ensure that an application is truly accessible?

Accessibility is more than page-level compliance

Traditional accessibility testing typically focuses on individual screens, forms, buttons, and interface elements. These tests verify whether a page meets accessibility standards and whether assistive technologies such as screen readers can interpret the content correctly. While this approach is essential, it provides only a partial view of the user experience. 

Similarly, traditional end-to-end (E2E) testing is designed to validate complete business processes and user journeys. These tests commonly focus on mouse clicks, touch gestures, and visual interactions. They provide confidence that a typical user can complete a journey successfully. However, they often miss how users relying on keyboards, screen readers, voice navigation, or other assistive technologies experience the same workflow. 

An application can pass every accessibility check on every page and still deliver a frustrating or unusable experience for users with disabilities.

Why accessibility testing should extend across user journeys

Consider focus management as an example. A page may have perfect accessibility compliance when tested independently. However, after navigating from one screen to another, keyboard focus may unexpectedly move to a footer, menu item, or browser address bar, creating confusion for screen reader users. This issue occurs during page transitions and therefore can only be identified through E2E accessibility testing.

The same principle applies to system processing and validation messages. A page may correctly display an error, but if focus remains on the submit button, a screen reader user may never hear the message explaining what went wrong. Traditional testing confirms the existence of the error. Accessibility focused E2E testing ensures users can discover, understand, and recover from it.

As these examples show, Accessibility isn’t experienced one page at a time. It is experienced through user journeys. When users log in, search for information, submit forms, complete transactions, recover from errors, or navigate across integrated systems, they encounter a sequence of interactions rather than isolated screens. Accessibility issues frequently emerge during these transitions. These defects often remain invisible during component-level testing and only become evident when an entire workflow is exercised from start to end.

Real risks hidden inside end-to-end journeys

Modern digital platforms are increasingly complex. They include multi-step onboarding processes, authentication flows, integrations with external systems, real-time updates, and dynamic content. Each of these introduces accessibility risks that cannot be fully evaluated in isolation.

Take multi-step wizards as an example. A customer onboarding process may span several screens, including personal details, addresses, tax information, reviews, and submissions. If the current step isn’t announced, the progress indicator isn’t accessible, or focus locations are inconsistent, users can quickly lose their sense of navigation. To reiterate, individual pages may pass accessibility testing, but the overall journey can still fail.

Authentication and multi-factor authentication (MFA) flows present another challenge. WCAG 2.2 introduced additional considerations surrounding authentication and cognitive accessibility. Issues such as incorrectly announced OTP fields, blocked password managers, or unpredictable focus order often emerge across the complete login process rather than within a single screen. 

Similarly, session timeout scenarios represent significant accessibility risks. If users spend time reviewing information and receive a timeout warning that assistive technology doesn’t announce, they may lose both context and entered data. Testing this effectively requires recreating an entire journey with realistic timing and workflow state conditions.

Enterprise platforms face even greater challenges

For many large organisations, user journeys extend across multiple applications and integrated systems. Financial services platforms, healthcare systems, government portals, and enterprise ecosystems frequently require users to navigate between different technologies and vendors.

In such environments, each system may pass accessibility assessments. However, inconsistencies in keyboard navigation, heading structures, focus behaviour, or screen reader interactions can create accessibility barriers when users move between systems. These integration-related issues can only be discovered through end-to-end accessibility testing.

Dynamic interactions also introduce challenges. Search results, portfolio updates, shopping baskets, and real-time notifications may be fully functional yet fail to announce critical information to screen readers. Users may not realise that results have refreshed or totals have changed. Accessibility in these situations depends on how information is communicated throughout the interaction lifecycle, not merely how it appears on the screen.

Making accessibility part of everyday end-to-end testing

To make accessibility a genuine part of end-to-end testing, in addition to page-level testing, QA teams need to focus on validating complete user journeys. Start by identifying the organisation’s most critical workflows, such as onboarding, authentication, transactions, searches, and service requests, then map these journeys from beginning to end through the lens of accessibility. Success should be measured not only by whether the process works, but by whether users relying on assistive technologies can complete it independently and efficiently.

This shift also requires combining automated accessibility checks with Human-Centred Testing. Automated tools can quickly identify WCAG violations, but they cannot fully assess how a journey feels when navigated using a keyboard, screen reader, voice controls, or other assistive technologies. Incorporating live user evaluation of complete workflows helps uncover issues with focus management, navigation continuity, status announcements, and error recovery that page-level testing often misses.

Over time, accessibility should become a standard quality attribute within E2E test design, execution, and reporting. When teams evaluate accessibility outcomes alongside functional, performance, and security results, they gain a more complete understanding of whether a digital journey is truly usable for everyone.

Leveraging AI to strengthen accessibility across user journeys

AI is also emerging as a valuable ally in accessibility integrated E2E testing. By analysing user journeys, AI-powered testing tools can help identify accessibility risks across complete workflows, prioritise areas with the highest user impact, and detect patterns that may be missed during user reviews. When combined with automated accessibility scanning and human-assisted testing, AI can accelerate coverage, provide earlier feedback, and help QA teams focus on the journeys most critical to users. However, AI should be viewed as an enhancement rather than a replacement for real assistive technology testing, as users’ lived experience remains the ultimate measure of accessibility.

The business value of accessibility driven end-to-end testing

Embedding accessibility into end-to-end testing delivers benefits far beyond compliance.

It reduces legal and reputational risk by identifying accessibility gaps before they reach production. It improves customer satisfaction by ensuring all users can complete critical journeys independently. It strengthens brand perception by demonstrating a commitment to inclusion and social responsibility. Most importantly, it expands market reach by enabling access for an often underserved segment of the population. 

From a quality perspective, accessibility focused E2E testing also encourages teams to think about real human experiences rather than purely technical outcomes. It shifts testing from asking, “Does this user journey work?” to asking, “Can everyone successfully complete the user journey?”

Conclusion

Accessibility is not a checkbox exercise, nor can it be fully validated by testing individual screens in isolation. True accessibility is achieved when every user, regardless of ability, can successfully navigate an entire journey from start to end.

As organisations continue to invest in digital transformation, accessibility testing should evolve beyond page-level validation and become an integral part of end-to-end testing strategies. The most inclusive digital experiences emerge when accessibility extends beyond individual screens and supports users throughout their complete journey.

And ultimately, that is what users remember, whether they were able to achieve their goal independently, confidently, and without barriers, rather than the individual pages they visited along the way.