At Evinced, we believe prudent, harnessed AI coding is the best path to embedding accessibility consistently into your product development process.
But teams differ on their attitudes and capabilities toward agentic coding. How can a company that doesn’t yet use AI coding change the way it makes things to ensure what it makes is always accessible?
The answer is people, tools, processes, and promotion.
Understanding the software development lifecycle
Software development is much like a factory, in that it proceeds along a kind of line. First there are product managers, then designers, the developers, then QA – each handing off to the next. Accessibility issues tend to get caught (or missed) at every one of those handoffs.
To build a truly accessible development process, you’ll need tools, systems, and internal promotion at each step of that line.
Why? Because catching bugs once they are in production is expensive. And risky.
Building such a process takes time. And doing so without disrupting your teams requires some strategic thinking. Here’s how to realistically get there in 21 months.
Phase 0 – Build the foundation
Months 0-3
The first three months are exclusively about people.
Start by hiring one or two Accessibility Subject Matter Experts (SME). These aren’t auditors, they’re internal advocates who will teach, support, and champion accessibility across the organization. Announce both the hire and the program company-wide, so every team understands that this is a company priority, not a side project.
Alongside that, develop an Accessibility Champion program within engineering. You need someone established and familiar with each team who can answer quick questions, spot patterns, and keep momentum going between formal training sessions. A good goal is roughly one champion per 25 developers. Aim to have this program fully staffed by Phase 4 (13–15 months in).
This phase is also the right time to establish an education and help process. Get your engineering and design teams through the relevant role-based courses on Evinced Learn so they can start training right away. And for support, hold office hours, start a Slack channel, and host a recurring Lunch and Learn series. Engineers who are curious but unsure where to start need a low-friction way to ask questions. Create that on-ramp now, because you’ll need it when the tools arrive later.
Phase 1 – Start manually, with key flows
Months 4-6
Before layering in any technology, your accessibility team needs to develop a hands-on understanding of your product. Pick the ten most important user flows (the paths your users actually take through your product) and analyze them manually, every month.
Your accessibility team should lead the first few analyses themselves. This builds institutional knowledge that no tool can replace. Depending on your team’s bandwidth, you may want to bring in a third party (or hire more subject matter experts) to help with the heavier lifting.
Be selective about the feedback you share with the broader organization at this stage. The goal is early credibility, not comprehensive coverage. Surface one or two problems that are completely blocking screen reader or keyboard users; these are issues so clear that no one can argue with their severity. Fix those and build trust.
Phase 2 – Introduce tools and measure against a baseline
Months 7-9
This is when you bring Site Scanner into your accessibility team’s toolkit. The first order of business is collecting compliance data across your entire digital footprint. You’re not going to fix everything at once, but you need to establish a baseline you can measure against. A useful starting metric: the number of critical issues per page, or the percentage of pages with at least one critical issue.
Evinced will work with you to help prioritize issues and ensure reports are delivered to your engineering teams in their preferred format (a spreadsheet, JIRA tickets, etc.).
From there, focus on Components analysis (provided in nearly every report from Evinced) to generate a prioritized punch list of the ten highest-impact problems – the fixes that will move your score the most for the least engineering effort. Work with your engineering team to knock those out.
Over two to three months, you should see substantial improvement. Report those wins loudly and often. We can’t emphasize enough that momentum is a huge motivator. Think of it as island-hopping. Your program needs to go, in the early days, from success to success.
Phase 3 – Expand flows, add mobile
Months 10-12
With a baseline established and early wins on the board, it’s time to scale your coverage beyond the manual testing that your accessibility folks were doing in Phases 1 and 2. Now you need to put some key tools into the hands of people outside your accessibility team. That most likely means, at this stage, developers and QA.
Web Flow Analyzer (“WFA”) can be used by QA or developers to test flows by themselves, all with centralized, de-duplicated reporting that will flow into your company’s web accessibility dashboard on Evinced. You could easily, in this way, expand your web flow coverage to 50 flows.
On the mobile side, Mobile Flow Analyzer (“MFA”) enables easy testing of flows, as well as our pioneering whole-app scanning capability. With one click, a tester can set MFA to test flows without requiring SDK installation or code-level access. Any tester who can run the app can test it, across iOS and Android, with unified reporting.
We will help you train your team on these tools. Keep in mind, however, that we have made them extremely easy to use, so training should go very quickly indeed.
Phase 4 – Introducing automation
Months 13-15
This is the inflection point of the program.
By this stage, your engineering team has had real exposure to Evinced’s tools and the accessibility mindset behind them. That foundation matters; automation introduced too early, before developers understand what they’re looking at, tends to backfire. A failing test that engineers can’t interpret or trust is worse than no test at all.
If your engineering team already runs functional test automation, this is when you add Evinced’s Automation SDKs directly to those tests. Start with a light touch: results are reported to the cloud and reviewed by your accessibility team first, rather than immediately failing builds. This gives your team the chance to catch false positives, calibrate thresholds, and ensure engineers only see issues they can understand and act on. Accessibility checks stop being a separate activity and become part of the build pipeline your developers already trust.
If test automation isn’t in place yet, this is a good moment to train your QA teams on the Web Flow Analyzer and Mobile Flow Analyzer so they can start owning flow-level accessibility testing themselves.
Now is also the right time to introduce #EvincedClear as a soft standard for promoting releases and features through the pipeline. At minimum, define it to mean no critical defects. This isn’t a hard gate yet (that comes later) but establishing the language now means engineers start thinking in those terms.
Refine your use of the Evinced dashboard so you have company-wide visibility: critical defect counts in pre-production versus post-production, and an aggregate accessibility score across all digital assets.
Phase 5 – Focus on components, for prevention
Months 16-18
The most durable accessibility improvements happen at the component level. If every new reusable component is accessible from the moment it’s designed and built, the overall system gets better automatically, without requiring a retroactive audit of every page.
This phase introduces two tools that enforce that standard.
Design Assistant, a Figma plugin from Evinced, works at your designers’ fingertips, validating new components for accessibility before a line of code is written. Unit Tester is for component developers, so that any component can be thoroughly tested before it even reaches QA.
Make the standard clear, that all designs and executed components must be #EvincedClear before moving to the next stage of the pipeline.
Now, your accessibility team can shift into an exceptions-review role. They’re no longer the people running every test, they’re the people handling the edge cases that need expert judgment.
Phase 6 – Scaling up
Months 19-21
The final phase extends the #EvincedClear standard from components to every release.
As the program scales, request volume to your accessibility team will grow. To keep that from becoming a bottleneck, consider deploying our Chatbot to put accessibility expertise in the hands of everyone in the product development cycle.
Schedule an annual manual review to serve as a backstop: an expert-led audit that catches anything the automated tools missed and validates that the overall program is working as intended.
The goal is closer than you think
Twenty-one months is a real investment. But the alternative – more cycles of audits, reports, and recurring problems – costs more in the long run.
The services-led model asked companies to buy accessibility. The technology-led model helps them build it. And when accessibility is built into every stage of how software gets made – from the designer’s Figma file to the engineer’s Chrome DevTools window to the automated pipeline – it stops being a program your team runs. It’s just how your team ships.
That’s the goal. And it’s closer than you think.