Bridging the Gap: How Testing Teams Can Lead on Accessibility

When it comes to accessibility, it’s often not about bad intentions—it’s about missing processes. In this session, we’ll explore a real-world-inspired scenario where the testing team takes the lead on accessibility, showing how one test case can spark broader change. We’ll start by comparing two teams in the same organization: Team A – The Development Team They’re moving fast and focused on features, unintentionally pushing inaccessible code into production. They may not realize that using a button instead of a can confuse screen readers, or that missing alt text makes entire sections invisible to some users. Misused ARIA roles and attributes can render interactive components unusable for those relying on assistive tech. Team B – The Testing Team They’ve built accessibility checks into their workflow using Tosca and track issues in qTest. From unlabeled buttons to missing alt text, they not only catch violations but also help educate developers on how to fix them—and why it matters. Then, we’ll dive into a live walkthrough: • Detect the issue in Tosca – We’ll demo how Tosca catches common violations, like an image without alt text, during automated test runs. • Experience the impact – See how a screen reader behaves before and after the fix, bringing the user’s experience to life. • Fix and retest – Collaborate with devs, apply the fix, validate the update, and rerun the test. • Track in qTest – Use qTest to monitor accessibility across pages and releases, gaining visibility into overall site health. Accessibility doesn’t have to be overwhelming. It can start with one fix, one collaboration, and the right tools. This session will show how testing teams can lead the charge—even when development isn’t there yet—and how small wins can drive scalable, meaningful impact.