How to Audit an Existing Product for Accessibility

Despite increasing awareness, some still don’t invest sufficient time in the accessibility topic. This happens because, historically, accessibility has been treated as an enhancement, something to deal with after the core features are done. And for existing products that have already been launched and matured over time, it can feel overwhelming to even know where to start. 

So if that’s where you are, keep reading because this article can help. We’ll take a look at what accessibility audits are, why they matter, how to run them, and how to build a path forward from the results.

Where to start when your product isn’t accessible?

Let’s say you already have an app on the market, you launched it back in 2019, and everything’s going super well. However, when you first built it, you didn't take all accessibility guidelines into account. So what happens now? 

This is where an accessibility audit comes in. An audit is a structured review of your product that evaluates how well it aligns with established accessibility guidelines, but even more importantly, identifies if the app is suitable for users with disabilities and those who rely on assistive technology. The goal of an audit isn’t just to catch issues; it’s to understand where your product falls short, how it affects real users, and how to fix it. It usually results in a list of issues that need to be addressed to make your product compliant – this allows your team to make informed decisions, whether that’s planning a full accessibility overhaul, fixing things incrementally, or prioritizing high-impact areas first. Think of it as a medical check-up for your app; you want to make sure that people with a wide range of limited abilities, devices, or needs can use the app as intended.

Now, with the EAA being in effect, there’s a certain pressure in the air to get this done as soon as possible. But the good thing is, we’ve been dealt some breathing room – five years to be exact. Meaning, if you have an existing product on the market that doesn’t comply with accessibility standards, you have a five-year grace period to become fully compliant. However, if you’re making any updates, adding new features, or redesigning your app, you have to meet compliance requirements. 

So, what does an accessibility audit actually involve?

An audit typically begins with defining its scope – this means deciding whether it’ll cover the whole product, a specific platform, or certain sections of a site. Once you define the scope, you move into testing, starting with automated scans. For this, we use automation tools like A11YPLAN, axe DevTools, and Stark, which help quickly catch common accessibility issues. What’s important to note is that these tools are used across all roles in the product lifecycle; QA engineers bring a user-centered perspective, designers spot issues with visual design and UX, and developers address the underlying code and tech structure. Collaboration is key – no single team member can cover every angle. After completing the automated scans, a QA engineer will review the results, document them, and tie them to relevant WCAG standards. However, automation can only go so far, and that’s where manual testing takes over. 

Manual checks often begin with something simple, like adjusting the font size to see how the app handles it. This small change often exposes broader accessibility flaws. From there, testing expands into the use of assistive technologies, such as screen readers (VoiceOver for Apple devices and TalkBack for Android), magnifiers, and keyboard-only navigation. For web testing, we prefer native screen readers, like VoiceOver on Mac. You want to make sure that interactive elements are labeled correctly so that the reading order makes sense and the error messages (and other feedback) are accessible. Depending on the context of the app, you may also use additional tools like on-screen keyboards, color adjustment, and contrast-changing utilities.

A full audit includes more than just functional checks – think typography, contrast ratios, interface responsiveness, and overall user experience. Throughout all phases of an audit, every issue is logged, categorized, and linked to relevant standards. Once we finish testing, the client receives a detailed report outlining each issue, its potential impact, and recommendations for resolution. What the audit doesn’t include, however, are direct fixes to design or code, or in other words, it suggests fixes but doesn’t implement them. The report is often followed by a presentation and Q&A session to ensure everyone involved understands the results and next steps.

The reality of retrofitting accessibility

Accessibility efforts in existing products are complicated by technical debt, outdated frameworks, and years of layered design decisions, quick fixes, and custom components. What seems like a straightforward fix often detects deeper issues – from non-semantic code to inaccessible components or libraries that don’t support modern accessibility standards. Because accessibility wasn’t considered from the start, every change carries the risk of unintended consequences, making retrofitting both time-consuming and pricy. In many cases, it feels like doing the work twice. But it doesn’t mean it’s impossible. 

With the right approach, you can, step by step, fix a lot of issues. Accessibility audits play a crucial role here, helping you identify and prioritize high-impact improvements, such as fixing missing alt text, ensuring proper keyboard navigation, correcting heading structures, improving contrast ratios, and strengthening screen reader support. These targeted changes can significantly improve usability without destabilizing the product. However, not every product can be salvaged through patches. Legacy CMSs, heavily customized frameworks, and aging libraries often reveal structural limitations that make true accessibility compliance nearly impossible. In these situations, redesigning or refactoring becomes the more sustainable and cost-effective option. Unlike patchwork fixes, a redesign allows accessibility to be integrated from the ground up; aligning design, architecture, and testing with best practices from day one. Integrating accessibility checks into CI/CD pipelines further ensures that compliance isn’t treated as a one-off project, but as a continuous practice where new issues are detected and resolved early in the development process.

Ultimately, the difference between introducing accessibility into an existing and a new app comes down to efficiency and control. Retrofitting means working within constraints and balancing risk against impact, while a fresh build offers the opportunity to create an accessible product by design. Knowing when to patch and when to rebuild is often the most critical decision of all.

Building accessibility into your team’s workflow

You get the idea; however, your experience with accessibility is still pretty limited. If there’s one piece of advice I’d give to any team starting their accessibility journey, it’s this: make accessibility part of the process, not a checklist item. This principle applies whether you’re retrofitting an existing product or building something entirely new. Embedding accessibility checks into the CI/CD pipeline ensures issues are caught before they ever reach production, and shared ownership across teams keeps it from slipping off the radar. 

Of course, this integration takes an upfront investment in tools, training, and time. But the long-term payoffs are undeniable: fewer bugs, happier users, a better overall user experience, and full legal compliance. The goal is to make accessibility part of your daily routine, not something you just occasionally check up on. 

Communicating audit results effectively is a big part of sustaining that culture. Reports should be concise and use plain language. Even if it’s something purely technical, demonstrating how it creates an accessibility barrier will help everyone understand why it matters. That way, developers, designers, and clients, no matter their level of expertise, can see the problem clearly and know how to prioritize fixing it.

After the audit: what comes next?

You’ve completed your first accessibility audit! Yay! Now you have a document that serves as a blueprint for resolving your app’s current issues and maintaining accessibility over time. This is the part when collaboration becomes essential. 

Designers may need to revisit color palettes, adjust spacing, and refine component behavior. Developers will implement code changes, clean up outdated patterns, and test alternative interactions to ensure compliance. QA teams will validate the changes and re-test using the same assistive technologies used during the audit, ensuring fixes truly work for end users.

A strong next step is establishing an accessibility roadmap: a clear, actionable plan for how and when you can make improvements. This roadmap should account for retesting after implementing fixes, ongoing monitoring, and scheduled formal audits. For live products, an annual audit is a solid baseline, with additional checks before any major release.

If you’re just starting your accessibility journey, the best approach is to begin with the basics. Study the relevant accessibility standards, explore available testing tools, and build awareness across the entire team. Start with an automated audit to get a sense of the most common issues, then dive into manual testing by learning to use screen readers – and really learn them. 

For projects already in progress, the best time to start is yesterday. I mean immediately. Begin with small, manageable improvements, such as proper labeling in development or selecting the right testing tools. From there, incorporate accessibility into every stage of the product lifecycle. Treat it as a non-negotiable standard rather than an optional extra. Once the team understands both how accessibility is done and why it matters, it naturally becomes part of the workflow.

If you’re wondering how often you should run an accessibility audit, it really depends on your product’s complexity and where you’re in the lifecycle. Accessibility testing should be part of everyday QA, built into each stage of development. Full, formal audits work best at bigger milestones, like wrapping up a project or prepping for a major release. You don’t need to do a full audit for every single feature, but regular accessibility checks should always be part of your testing flow. Once a product is live, aim for a standardized audit at least once a year, and definitely before redesigns, feature launches, bug fixes, or migrations. You’ll also want to schedule audits whenever new compliance rules come up or if users, clients, or major changes spark the need for a fresh look.

Ready to take the next (necessary) step?

Auditing an existing product for accessibility might feel like a huge lift, especially if accessibility wasn’t considered during initial development. But it’s absolutely doable and it’s worth doing, for your users, your business, and your team.

The real shift happens when accessibility stops being a fix and becomes part of your foundation. And the audit? That’s just the beginning of that transformation.

If you’re not sure where to start, start small. Run a scan. Pick one flow. Learn how your product feels when navigated with a keyboard or screen reader. You’ll quickly see the gaps and the opportunities.