Accessibility testing has become a core part of building responsible and usable digital products. As applications grow more complex and release cycles become faster, teams need a structured process that combines automation, manual validation, and consistent accessibility scheduling to maintain compliance and usability over time.
Here, I will share my experience with accessibility testing.
My Approach to Accessibility Testing
From what I’ve learned, accessibility testing teaches you pretty quickly that simply meeting technical requirements doesn’t guarantee your product will actually work for all users. I always start by figuring out who will be using what we’re building. Before I run any automated scans, I take time to identify our different user groups. This includes people who depend on screen readers, users who can only navigate with a keyboard, individuals with low vision who need to zoom their screens to 150% or higher, and those dealing with cognitive or motor challenges.
Once I have that picture, I tackle the testing in stages. I start with automated tools because they’re great at quickly spotting common, recurring problems. Next, I manually work through the main user journeys, navigating with just my keyboard and testing with screen reader software.
After that, I compare what I’ve found against the relevant guidelines – typically WCAG 2.1 AA – and write up my results so developers can understand and fix the issues without having to translate technical accessibility language.
This step-by-step method works because each approach has its blind spots. Automated testing tools only catch about half of the accessibility problems that actually exist. Manual testing picks up what the automated tools miss, but it takes much longer and requires someone who really knows how assistive technologies function in practice.
Understanding Accessibility Standards and Guidelines
Before testing anything, you need to know what you are testing against. The Web Content Accessibility Guidelines, or WCAG, are the foundation. WCAG is organized around four principles: content must be perceivable, operable, understandable, and robust. Each principle breaks down into specific success criteria rated at Level A, AA, or AAA.
Level AA is the target for most projects. It is what the ADA in the United States and the European Accessibility Act reference. Section 508 applies to federal agencies and contractors in the United States. AODA applies in Ontario, Canada. Understanding which standard applies to your project is the first step, because the required criteria differ slightly across frameworks.
In practice, I always aim for WCAG 2.1 AA as a baseline. If the client operates in a jurisdiction where 2.2 is becoming the norm, I layer those additional criteria on top. The newer criteria in 2.2, such as focus appearance and dragging movements, address interaction patterns that are increasingly common in modern applications.
Automated Accessibility Testing Tools I Have Used
Automated tools are not a replacement for manual testing, but they are an important first pass. They catch high-volume, repeatable issues fast, which saves a lot of time in the manual phase.
- TestMu AI (formerly LambdaTest): I have used TestMu AI when projects required accessibility validation across multiple browsers and real devices. Instead of limiting testing to a local setup or relying only on a browser-based accessibility extension, it provides cloud access to 3000+ browser and operating system combinations. This helps in running automated accessibility checks at scale and identifying issues that may appear only in specific environments.
- WAVE is a browser extension I use for quick, visual checks. It overlays icons directly on the page to show where issues are, which makes it easier to communicate problems to designers and product owners who may not be reading technical reports.
- Siteimprove, I have used on projects where the client needed ongoing monitoring rather than a point-in-time audit. Its reporting dashboard tracks accessibility health over time, which is useful for showing progress to stakeholders and catching regressions after content updates.
- Lighthouse, built into Chrome DevTools, gives a quick accessibility score alongside performance and SEO metrics. It is useful for getting a fast read on a page, but the score can be misleading. A page can score well on Lighthouse and still have serious accessibility failures that only manual testing reveals.
Integrating Accessibility Testing Into CI/CD Pipelines
One of the most impactful changes I made to my testing process was pushing automated accessibility checks into the CI/CD pipeline so issues get caught before code reaches production.
The setup I have used most involves running axe-core as part of the test suite. axe-core is the underlying engine behind axe DevTools, and it integrates with testing frameworks like Jest, Cypress, and Playwright. You write tests that load a component or page, run the axe scan, and fail the build if any violations above a set severity are found.
This approach means that a developer gets an accessibility failure in the same place they get a failing unit test. It removes the separation between accessibility and quality, which is where the cultural shift happens. Accessibility stops being an afterthought that comes up in a late-stage audit and becomes a condition of merging code.
The key to making this work is setting realistic thresholds at the start. If you run axe-core on an existing codebase and fail every violation immediately, you create a wall of red that teams ignore. A better approach is to baseline the existing violations, prevent new ones from being introduced, and chip away at the backlog over time.
Common Accessibility Issues I Have Identified
Across projects of different sizes, certain issues come up again and again. Missing or generic form labels are the most common. Inputs labeled only with placeholder text fail as soon as the user starts typing, because the placeholder disappears and the field becomes anonymous to a screen reader.
Low color contrast is the second most frequent finding. Text that looks fine on a designer’s calibrated monitor often falls below the 4.5:1 ratio required for normal text under WCAG AA.
Missing or inaccurate alt text on images is a persistent issue, especially on content-managed sites where editors upload images without following any guidelines. Alt text that says “image” or repeats the filename is nearly as unhelpful as no alt text at all.
Keyboard traps appear regularly in modal dialogs and custom dropdown components. The user tabs into the element and then cannot get out without using a mouse. Focus management on modals, meaning moving focus into the dialog when it opens and returning it to the trigger when it closes, is something many component libraries still get wrong.
Inaccessible error messages are another common finding. An error that appears visually next to a field but is not associated with that field programmatically is invisible to a screen reader. The user submits the form, nothing happens, and they have no idea why.
Challenges Faced During Accessibility Testing
The biggest practical challenge is dynamic content in single-page applications. Components that update without a page reload can change the DOM in ways that break the accessibility tree. Testing these states requires time and a solid understanding of ARIA live regions and focus management patterns.
Getting teams to act on findings is another real challenge. A 40-page audit report is easy to file away. I have had more success writing findings as developer tickets with clear acceptance criteria, placing them directly in the project backlog, and prioritizing them by user impact rather than volume.
Third-party components are a recurring headache. A charting library or a rich text editor embedded in an application often has accessibility problems that the team cannot fix directly. You can choose an accessible alternative, create a custom wrapper that fixes the most serious issues, or formally document the limitation and treat it as an exception.
Conclusion
App accessibility testing has taught me that real usability comes from consistency, not one-time audits. Automated tools, manual validation, and CI/CD integration each solve different parts of the problem. When combined with clear standards and structured accessibility scheduling, they help teams catch issues early and reduce long-term rework.
