In today's digital age, creating an inclusive and accessible online experience is not just a moral (and, soon, legal) obligation but also a business imperative. For e-commerce applications, where user experience can directly impact sales and customer loyalty, ensuring accessibility must be a top priority.

Automatic testing tools are the first essential step towards accessibility that should not be underestimated. They can help identify some accessibility issues, but they are not all-encompassing. Our team recently embarked on a project on a complex e-commerce platform, which included a specific high standard for accessibility for the final product. Through this journey, we discovered that more than relying solely on automatic testing is required. In this blog post, we'll share our insights and lessons learned, highlighting the importance of combining automated tools with manual testing to create a truly accessible shopping experience for all users.

Automated Accessibility Testing – Tools, Comparisons, and Limitations

The first, most basic way to check the accessibility of your product is through automated testing, using software tools to automatically scan and analyze web applications for common accessibility issues, such as missing alt text, improper heading structures, and color contrast problems. These tools quickly provide insights into how well basic accessibility guidelines (such as the WCAG - Web Content Accessibility Guidelines) are met. Because of their speed and ease of integration into development workflows, automated testing is often used in the early stages of web development to catch and address simple, straightforward issues before they escalate into larger, more complex problems later in the development process.

Let’s have a look at the automated tools we've used in our accessibility testing process, along with our thoughts on their strengths and limitations:

• Axe by Deque Systems: an open-source, robust tool available both as a library and a browser extension.
  • Pros: Open-source, highly accurate for detecting issues, integrates well with major browsers and CI/CD pipelines, and provides clear documentation on how to fix issues.
  • Cons: Limited in detecting complex accessibility issues like keyboard navigation and screen reader compatibility; false positives can occur for edge cases.
• Lighthouse by Google: an open-source tool available as part of Chrome.
  • Pros: Built into Chrome DevTools, easy to use, provides a comprehensive accessibility score and includes performance and SEO audits in addition to accessibility.
  • Cons: Limited scope in detecting all accessibility violations, results can be inconsistent, doesn’t catch nuanced issues like focus management or dynamic content accessibility.
• AQA by UsableNet: an all-inclusive accessibility management platform
  • Pros: Highly customisable, allows for the definition of user flows to test complex pages, integrates in CI/CD pipelines, provides detailed and comprehensive reports.
  • Cons: Paid tool, requires careful setup of user flows to avoid errors, execution and reporting can be time-consuming.

While automated testing is an important first step, it cannot fully replace manual testing. Learning to use tools as AQA it was an interesting and useful experience, helping our team identify a baseline set of accessibility issues efficiently. However, achieving full accessibility compliance requires a more comprehensive approach beyond automation: a static analysis by these tools cannot simulate how a real user will interact with a page or uncover the challenges they may face during their experience. In the next section, we’ll explore the importance of manual testing to address the gaps that automated tools often miss.

Manual Accessibility Testing – Putting Yourself in the User’s Shoes

Manual testing involves developers directly interacting with the app using assistive technologies or simulating the experiences of users with disabilities. This hands-on approach reveals usability issues and gaps that automation cannot catch.

This step in accessibility testing truly shifted my perspective, allowing me to experience the app through the eyes of a user with disabilities. It highlighted challenges I hadn’t previously considered and led me to rethink aspects of UI/UX design, that’s why I highly recommend other developers try this approach.

The most impactful and easily adoptable manual testing methods are as follows:

• Keyboard navigation only
  • Developers can try to navigate the app entirely without a mouse, relying only on keyboard inputs (e.g., tabbing through elements). This approach helps uncover issues with focus order, the accessibility of interactive elements, and the overall usability of the app for keyboard-only users.
• Simulating Low Vision or Color Blindness
  • Developers can adjust their display settings or use browser plugins (such as Silktide) to simulate different vision impairments, allowing them to evaluate color contrast and font readability for users with visual impairments.
• Using a Screen Reader
  • Developers can try to navigate through the app using only a screen reader, focusing on whether all content, including text, images, buttons, and forms, is properly announced and easy to understand. They should assess whether all interactive elements are labeled correctly and whether any vital information is missing or inaccessible.
  • It’s important to test your app with multiple screen readers, as each may process page content differently and convey varying information to users. The most popular screen readers are NVDA (for Windows) and VoiceOver (for macOS).

Manual testing was a step that, as a developer, I wasn’t accustomed to performing, especially when it came to using screen readers. I knew that optimising pages for screen readers would make a significant difference in usability, but I was genuinely surprised by just how much of an impact it could have.

A simple detail—ensuring the screen reader announces the number of entries in a dropdown upon opening—goes a long way in aligning the experience of visually impaired users with that of sighted users, which ultimately is the goal of accessible development.

In the next chapter, we will take accessibility testing a step further by exploring the benefits of direct testing with users with disabilities and collaborating with professional accessibility testers. Their real-life insights provide invaluable feedback that can enhance your app's usability and ensure a truly inclusive experience.

Accessibility Testing by Professional Testers – Real-World Insights

The final tier in our accessibility testing approach involves engaging professional accessibility testers. These experts bring a wealth of experience in identifying a broad spectrum of accessibility issues and can thoroughly evaluate complete user journeys. They are often users with disabilities themselves or are trained to understand how disabilities affect user interaction with a page, making their insights invaluable for refining an app's usability.

To get the most value from professional accessibility testers, it's important to provide them with detailed information about the app's goals and key user flows, allowing them to focus on the critical interactions that matter most to users. Additionally, collaboration with these testers should be an ongoing process, with regular testing conducted as new features are introduced or changes are made. This iterative approach ensures that accessibility remains a priority throughout the entire development lifecycle, preventing issues from slipping through as the app evolves.

A prime example of how working with a professional tester improved our final app is the implementation of a Google Map component. This component was intended to display the locations of physical stores where customers could find products listed on the e-commerce platform. Initially, we hid the map element from screen readers and tab navigation using an ARIA tag. We believed this approach would benefit users with disabilities by allowing them to skip the map entirely—avoiding the risk of getting stuck navigating through numerous store pins—and jump directly to the list of store details. However, the professional tester offered us a different perspective.

The tester helped us understand that this approach would have significantly altered the perceived structure of the page for visually impaired users, potentially leading to communication gaps between them and sighted users. Their suggested solution was to include a hidden "Skip" button as the first element within the map component, accessible only through tab navigation. This approach would allow visually impaired users to bypass the map and go directly to the store list if they wished, while still being aware of the map's presence on the page.

The tester also provided several other valuable tips:

• For input fields, ensure the label is read before the value. Some screen readers follow the HTML element order, so the label element should appear in the DOM before the input element.
• If an input field includes assistive text other than a label, the screen reader should announce it immediately after the label to ensure the user has all the necessary information to interact with the field effectively.
• If a field offers suggestions on focus, the screen reader should announce this to users, enabling them to explore and utilise these suggestions.

These insights have been invaluable in enhancing the overall accessibility of the app, and we’ll be sure to apply them in future projects. Additionally, we plan to explore closer collaboration with professional testers moving forward.

If you're looking to work with professional accessibility testers but aren't sure where to start, consider reaching out to digital accessibility agencies, which often have a network of certified experts. You can also explore freelance platforms that feature experienced testers or collaborate with advocacy groups for people with disabilities, who can connect you with individuals using assistive technologies daily and offer valuable real-world feedback.

Conclusion

To wrap up, we've explored the critical importance of a comprehensive accessibility testing process for e-commerce applications.

Automated tools, manual testing, and professional testing each have their own strengths and limitations, contributing a fundamental piece to the overall accessibility puzzle. By combining them, developers can create truly accessible e-commerce experiences that cater to all users, regardless of their abilities.

Although establishing such a comprehensive process may seem daunting, we view accessibility as an ongoing journey. While there is always room for improvement, taking actionable steps toward accessibility is far better than doing nothing at all.

If our approach to accessibility testing resonated with you and you’re seeking guidance, feel free to reach out. We’ll be happy to provide the support you need, making your transition to an accessible app smoother and more effective.