By Mindaugas Vaupšas
Zedge strives to make our apps and websites accessible for all users, including those with impaired eyesight or hearing. But regulations about accessibility can vary from country to country, so ensuring we’re compliant with all of them is a never-ending challenge. That’s why we’re very pleased with the results of our recent implementation of the PreGame Web AI Scanner, from a company called TestParty.
Regulatory compliance is hardly a party, but TestParty’s tool definitely made us feel like celebrating.
Zedge.net is a complex site, as we use it to receive artist applications, and to sell items from those artists to customers. So we have to verify tax forms, process payments, and enable content downloads in addition to making our massive catalog of wallpapers and ringtones easy to navigate. Keeping all those features running smoothly AND accessible to all is complicated.
The Challenge: Manual Vendors, Duplicate Tickets, and Lack of Clarity
We began our accessibility efforts years ago with a manual testing vendor, but their workflow quickly created bottlenecks. We were frustrated by repetitive issues, unclear remediation paths, and a lack of control. Plain text informing us of an issue isn’t very helpful if we then have to go isolate the problem ourselves. And our vendor would report the same issue 100 times because of component reuse, which gave us an inaccurate understanding of where we actually stood with compliance.
Worse, that vendor used automated scripts that flagged issues and then created tasks in JIRA, the tool our developers use to assign and track work, which flooded the team with multiple different tasks for what was often just a single problem.
We needed more clarity, and better prioritization.
The Solution: TestParty’s Developer-First Accessibility Platform
With TestParty’s PreGame Web AI Scanner, our engineers can now run accessibility scans on demand – during development, before production pushes, or whenever it makes the most sense for their workflow. This shift enabled our team to choose when and what to test, fix, and re-test, rather than being bombarded with confusing JIRA tickets.
Unlike other solutions, TestParty provides immediate, easily understood explanations for accessibility issues. Developers now understand not only what the issue is, but where it’s occurring and why it matters. Summary reports break down issue severity, recurrence, and impact, making it easy to brief leadership with minimal translation or technical overhead.
We were also deeply impressed by TestParty’s responsiveness. When we flagged an issue, the TestParty team addressed it promptly. This kind of partnership is rare, not just in accessibility tooling, but across all vendors. Compared to any service provider, TestParty has been the smoothest collaboration I’ve managed.
The Results: Confidence, Clarity, and Control
During the initial rollout, we tried TestParty on a web project we already believed to be in strong shape, accessibility-wise. The results validated that belief: TestParty caught the same issues our team had previously identified…and more. That apples-to-apples comparison gave us confidence in the tool’s accuracy and effectiveness.
Now we own the process of resolving and verifying accessibility issues. We can prioritize issues during development, test, rescan, and do that repeatedly.
TestParty’s reporting capabilities also transformed communication with the rest of the company, because they provide plain-language summaries rather than paragraphs of legal jargon common with many other vendors. Their summary list is very clear: how many issues we have, and which are critical. We can easily export and present the information to anyone who needs it.
The Road Ahead: Expanding to Mobile Accessibility
With the web rollout deemed a success, we’re now preparing to expand our use of TestParty to cover our iOS and Android mobile apps. So our collaboration will continue at an even bigger scale.
For us, TestParty aren’t just a vendor; they’re a partner in building a more inclusive web.