How To Bake Layers Of Accessibility Testing Into Your Process — Smashing Magazine

Why One Testing Method Is Never Enough

Most teams approach accessibility testing in one of three ways: running automated tools against their code or interface, manually testing by changing how they use their own computers (for example, keyboard-only navigation, zooming to 200%, or enabling Windows high contrast mode), or working with assistive technology users to uncover usability issues. The problem is that far too many organizations rely on a single one of these methods to validate their product. No one tool or process can provide confidence that a site truly works for the widest possible range of people.

Taking a layered approach—using all of these methods at different points in the product lifecycle—catches issues early, when they are cheaper and easier to fix. It also improves overall usability, which expands your customer base and cuts down on customer service inquiries. Accessibility specialists Kate Kalcevich and Mike Gifford have both seen this work in practice: Mike focuses on technical testing and compliance scanning early in development, while Kate concentrates on user experience. Combining these types of testing throughout the development lifecycle, they argue, is the most reliable path to an accessible product.

Securing Executive Buy-In

Before you can implement any testing strategy, you usually need leadership to prioritize accessibility. If you don't have that support yet, several arguments can help build the case:

• Check for legal requirements. Search for "Accessibility Act" or "Disability Act" to find laws relevant to your country. Highlighting legal risk is often the most persuasive angle for executives.
• Look at your competitors. Check their sites for accessibility statements. Most organizations want to stay ahead of the competition, and knowing others are investing in accessibility may provide the necessary push.
• Surface customer complaints. Connect with your customer service team to see if accessibility issues have been raised. If possible, talk to affected customers directly and share their stories with leadership. A recorded demo of a user struggling with your product can be especially compelling.
• Make the financial case. Accessibility is much more affordable when integrated into daily workflows rather than applied as an afterthought. There is also untapped revenue: people with disabilities represent over three trillion dollars in disposable income globally.
• Find a champion. Someone in leadership likely already advocates for diversity, inclusion, or social responsibility—or may have a personal connection to disability. Making them aware of accessibility concerns may be all that is needed to get a powerful ally.

Setting Up for Success at the Start

Accessibility needs to be part of the conversation before development begins. The procurement process is an excellent place to start: incorporate accessibility criteria when reviewing any technology you're buying or building. Look for vendor accessibility statements or VPATs, and consider running a quick scan with automated tools before signing a contract. Not all software is equally accessible, so it pays to work with vendors who treat accessibility as an ongoing priority.

If you're creating or updating a design system, choose a component library that's been built with accessibility in mind. A clear accessibility statement and an open issue queue where you can review known problems are good signs. Several well-known libraries are leading the way here:

• Material UI for Angular offers accessible components out of the box. The radio button component, for example, uses a radio group with an aria-label, each button announces its checked state to screen readers, arrow keys work for selection like standard HTML radio buttons, and focus states are clearly visible.
• Reakit for React includes an accessibility warning feature that alerts developers when an aria-label is required.
• Lion web components tag accessibility issues with an a11y label in their GitHub repository, so you can see what's being addressed and file your own issues when needed.

Another low-effort way to embed accessibility early is to update your team's personas. Create at least one persona with multiple disabilities—many people have more than one—to keep that audience in mind during design discussions. The International Association of Accessibility Professionals highlights the importance of remembering participants with multiple disabilities in personas.

To make that persona realistic, talk to real people with disabilities, including those with temporary and situational limitations. One in five people has a permanent disability, but 100% of the population will experience a vision, hearing, motion, or cognitive limitation at some point. Personas might reflect people with allergies or broken bones, people using outdated technology or working outside, or people who adapt their usage based on location—like disabling images to save bandwidth. Framing this change as making personas more reflective of actual users—which is their entire purpose—can help pitch it to leadership.

Co-design is another powerful way to involve people with disabilities. Australia offers a free training toolkit on co-designing with people with disabilities, and a case study from the UK government shows how effective sessions can be when run with people who have learning disabilities.

What to Do With Existing Legacy Systems

Most organizational IT decisions were made long before you began reading this article, and accessibility is typically just one of many factors weighed in those decisions. Even passionate organizations inherit legacy technology that doesn't meet current standards. If you're facing this situation, several strategies can help:

Raise awareness with the vendor or internal team. If you can document specific accessibility issues using automated tools, it may help a vendor prioritize fixes in their issue queue. There isn't always an official community portal, but Twitter or Reddit communities can sometimes bring concerns to light.

Look for workarounds that don't require a full rebuild. A customizable theme might address some visual or contrast issues. Some solutions expose an API that a developer could use to build an accessible interface on top of the existing system.

Highlight the competition. If a vendor has competitors, point out the accessibility features those products include. Reminding vendors that you have alternatives can be an effective motivator.

For internally built legacy products, a quick keyboard-only test can reveal a lot. If you can't navigate the product without a mouse—no visible focus or interactive elements that only respond to clicks—improving accessibility will likely be a significant effort. In the meantime, consider offering alternative ways to access the service, such as phone support, in-person service, or email, so users blocked by digital barriers can still accomplish their goals.

Finally, think strategically about your organizational roadmap. If a legacy tool is nearing the end of its life, weigh the cost and effort of making it accessible against that timeline. If other, newer products also have accessibility gaps, your effort may be better spent there.

A Layered Testing Strategy

Building a comprehensive accessibility testing program doesn't require a single massive investment. Instead, you can stack several complementary layers, each catching issues the others miss. The key is determining what fits your budget and gradually expanding your coverage over time.

1. Research user needs. Start by adding questions about assistive technology use to your participant screening questionnaires. This integrates people with disabilities into existing research at no extra cost. If recruitment is difficult, reach out to disability organizations. You can also enrich your personas with details from Gov.UK's user profiles. With budget available, include people with disabilities in prototype and design reviews, either through a vendor or by paying participants directly.
2. Refine your process. Build accessibility checks into the daily workflow of developers, designers and content authors. Free automated tools make this practical: browser extensions like WAVE or Accessibility Insights for page-specific design reviews; Axe Core or Pa11y for continuous integration pipelines; HTML Code Sniffer for WYSIWYG editors to flag issues as content is written; and a crawler such as Purple Hats to regularly scan both staging and production environments.
3. Manual QA. You can integrate accessibility checks into existing QA work without hiring extra staff. The single most effective step is simply removing mouse use during regular testing — you will catch accessibility bugs alongside functional ones. For deeper coverage, add keyboard-only evaluation of new components and content, test with browser magnification at 200% or greater (Ctrl + +), flip to dark mode for light-sensitive users, and run sprint-level testing with free assistive technology like VoiceOver, Microsoft Narrator or NVDA.
4. User testing. For organizations with dedicated budget, paying assistive technology users to test on staging before launch offers the strongest validation possible. Real-user feedback provides certainty that even perfect WCAG compliance can't guarantee. Since people with disabilities are frequently asked to contribute for free — despite often facing economic disadvantage — compensate them appropriately. On personal projects without budget, consider trading equivalent favors within your network.
5. Specialist review. If your organization has an accessibility team, have them perform user acceptance testing pre-release. This final check catches compliance issues earlier layers missed. Effective accessibility teams set standards, provide training, offer guidance and evaluate compliance — they serve as support rather than sole owners of accessibility work, preventing bottlenecks. Without an internal team, hire external accessibility professionals for pre-release reviews.

Finding Your Entry Point

Start where you are and aim for gradual improvement rather than immediate perfection. Implementing all five layers at once isn't necessary; choose one or two that align with your existing strengths and add more as your testing matures.

• Individuals new to accessibility should install a free browser extension like the WAVE Toolbar, learn to fix the errors it surfaces, share useful accessibility resources on social media, and attend webinars or events to build knowledge.
• Teams with strong user-centered design may begin with layer one, interviewing people with disabilities in research. Teams with mature IT compliance processes might instead invest first in automated testing integration or site-wide crawling. Either way, look for opportunities to shift accessibility earlier into the design and development workflow.
• Organizations should publish meaningful accessibility statements that reflect genuine commitment, and build a champions network to cultivate a community of practice.

What Automated Tools Can't Do

Automated tools are useful for catching errors early — use them to identify accessibility issues before publication and to crawl live sites for compliance after ongoing updates. They're only part of the picture, however.

The risk is that teams stop once automated tests report clean results. Since even the best tools detect only about 30 to 40% of WCAG compliance errors, eliminating everything a tool surfaces still leaves most barriers untouched. A tool can tell you an image lacks alternative text, but it cannot judge whether that text is accurate or contextually appropriate — that judgment requires a person.

Accessibility is also not the same as usability. It's the minimum bar ensuring assistive technology works; making content genuinely enjoyable and easy to use for people with disabilities requires real-user testing. Many organizations already conduct usability testing, but most exclude participants with disabilities. If recruitment is a challenge, consider partnering with organizations that maintain communities of assistive technology users and platforms to facilitate testing.

Putting the Layers Together

Adopt a layered approach rather than relying on any single testing method to find barriers. Test ideas with assistive technology users early, integrate automated code checks into your build process, include manual assistive technology testing in QA, validate with real users before launch, and perform comprehensive reviews on staging.

The ultimate goal isn't achieving a high score in a testing tool or checking off a WCAG guideline — it's making content accessible to the widest possible audience, including assistive technology users.

Top off the effort with an accessibility statement containing contact information on your site. This creates a feedback loop where users — the true experts — contribute to continuous improvement.