# Accessibility as Architecture: More than Acceptance Criteria [Simone Wood](/team/swood) Software Engineer Date September 3, 2026 Categories [Accessibility](/blog/category/accessibility) [Product management](/blog/category/product-management) [Technology architecture](/blog/category/technology-architecture) Too often, the first time accessibility gets serious attention is when a customer requests your VPAT (Voluntary Product Accessibility Template). What follows is a familiar scramble: a perfunctory assessment, quick fixes to code, rushed (if any) accessibility training, and a cursory VPAT that costs significantly more than necessary, if accessibility had been built into the development process from the start. Sometimes this is daunting and frustrating, but regardless of where a project is in its lifecycle, beginning the process of making it more usable, more accessible, more inclusive is always worth starting sooner rather than later. I started my career as a quality assurance (QA) engineer. That means I tested apps and websites to ensure that they didn’t have any bugs before they were released. Since becoming a web developer and specializing in accessibility, I still flex those skills often through the process of assessing, reporting, and remediating accessibility issues. Unlike QA testing, which occurs before a product launches, evaluating websites for accessibility often occurs after, once it's already in use by administrators, educators, or students. Regardless, it has an important similarity to QA testing: being completely frank and honest about the issues and gaps found helps everyone. When accessibility is built into the process from the beginning, flagging issues feels much like finding any other software bug or error during QA testing. This is particularly true for products that weren’t built using an accessibility-first framework, a comprehensive accessibility assessment is a critical step in working towards compliance. And just like QA testing, no release is perfect the first time it’s evaluated for accessibility. It leads to knowing where your product actually stands and having a clear plan for closing the gaps. ## Accessibility Isn’t a Finishing Touch When accessibility gets pushed to the end, the work doesn't disappear, it just gets harder. Every design review, QA pass, and content evaluation that should have happened incrementally now has to happen all at once, under pressure, during the last phase before a major production release, a period normally reserved for documentation and performance tuning. The team is expected to quickly use expertise it never had the chance to learn and apply. And because the accessibility fixes weren’t woven into a regular development cycle, addressing them at the end creates new opportunities for regression issues elsewhere. None of this is insurmountable, to avoid the extra cost and disruption, move accessibility reviews and fixes earlier into the product development process. ## Where to Start? Image Whatever your current state, the first move is the same: get an honest picture of where your product stands. A comprehensive review of your solution for patterns and gaps in accessibility will give you an immediate starting point. Waiting to start this process until there’s a customer request for a VPAT leaves you, at best, looking unprepared. Even if you can’t get the engineering resources to address all the issues found in a comprehensive assessment right away, publishing a VPAT with just partial compliance serves to demonstrate to your customers your commitment to making ongoing improvements and resolving the gaps in compliance. ## What’s the Process Like? Evaluating for accessibility isn’t a one-and-done process; it’s iterative. The first pass creates a baseline. The next pass happens after an initial review of the baseline findings, covering the applicable accessibility standards missed and walking through high-priority and low-hanging fixes. Iteratively after that, you implement and reevaluate, with your engineering team’s capabilities addressing gaps each time, eventually catching up to the most complex issues left to resolve. That’s where we come into the picture. Often the most difficult kinds of accessibility issues require both a technical understanding of the source code and accessibility standards, but also the instructional intent, pedagogy, and interactive learning design being attempted in the solution. Once those are solved then it’s time to publish an accessibility conformance report (ACR). A VPAT is a type of ACR. (Think of VPAT as a brand name version, and ACR as the generic noun for a thing.) ## Accessibility is Architecture Accessibility doesn’t happen in a vacuum. [Building accessibility commitment and expertise across departments](https://www.clarity-innovations.com/blog/building-accessibility-proficiency-across-departments) and stakeholders is the long term process that will make your products and services stronger. Just like software security, accessibility is a field that requires forethought and teamwork. QA testers can’t just assume software developers have made products exactly to specification, they have to test it to confirm. The same is true for accessibility. Everyone from designers to developers to testers and content authors need to know which aspects of accessibility affect their work and address them up front. For example, introducing designers to color contrast requirements and checkers, walking through proper semantic form markup with developers, and learning the basics of alt text writing for content producers. Building this kind of accessibility fluency takes time but is ultimately what saves effort and costs long-term. ## Be Discerning Where AI Isn’t With AI’s growing role on teams, it may seem like an alternative to building internal skills and competency. The accelerating pace of AI-assisted development creates a real tension for accessibility. More code, generated faster, means more places where accessibility requirements can be missed, and more pressure to treat a quick AI review for accessibility as a substitute for a methodical evaluation. However, there’s growing evidence this isn’t working very well. The [2026 WebAIM Million report](https://webaim.org/projects/million/#wcag), which scans the top one million websites annually, found that 96% had accessibility failures of some kind, with an average of 56 errors per page. What’s worse, there’s been a 10% growth in errors since 2025 and a 22.5% growth in page elements. More elements means more complexity and more places to break or cause accessibility errors. The most probable reason for this trend? The use of AI to generate code. Having a team that understands accessibility up front has a better chance of generating accessible code. A team that doesn't will generate inaccessible components at the same accelerated pace, and have a longer QA cycle for fixing all the AI-generated accessibility issues. Building accessibility into the architecture of your product development process will make sure every stakeholder along the way understands the cost and repercussions of non-compliance. If you'd like help figuring out where to start, [take advantage of our complementary one-hour consultation](https://www.clarity-innovations.com/services/package/edtech-consult).