Making Accessibility the Default: Continuous Accessibility Practices
CSUN Assistive Technology Conference
March 13, 2026
A presentation at CSUN Assistive Technology Conference in March 2026 in Anaheim, CA, USA by Andrew Hedges
Making Accessibility the Default: Continuous Accessibility Practices
CSUN Assistive Technology Conference
March 13, 2026
Introductions
Devon Persing Digital Accessibility Consultant
Andrew Hedges COO, Assistiv Labs
What will people learn in this session?
TL;dr, Achieving great outcomes is far easier when accessibility (a11y) is integrated across an organization. It takes people organized around smart processes & practices using tools that support rather than distract or detract from the goal.
Speaker: Devon
What is “Continuous Accessibility” (CA)?
“Continuous accessibility is defined as the approach to ensuring that code intended to be displayed in browsers can be continuously checked and monitored for digital accessibility requirements through a novel application of existing software engineering concepts and Web Content Accessibility Guidelines (WCAG).” Melanie Sumner Temple
Speaker: Andrew
Melanie Sumner Temple has been arguably the most consistent proponent of Continuous Accessibility over the last several years. She’s provided this useful definition of the concept.
We want to broaden that to include:
Non-developer roles
– UX design ^1 – Project and program managers – Cross-functional roles and teams
Organizations lacking
– Strong tooling programs – Program management for a11y – Leadership support for a11y
Speaker: Devon
Why is CA what we want? (1 of 5)
CA promotes better outcomes across UX, risk, ROI, and your brand.
Speaker: Devon
These are things we believe based on our experiences doing this work, and we have some resources at the end to back this up.
Why is CA what we want? (2 of 5)
CA promotes better outcomes across UX, risk, ROI, and your brand.
Speaker: Devon
What we want is integration of accessibility into the user experience as the default, ideally including actually testing with disabled users and taking their needs and experiences into account.
Why is CA what we want? (3 of 5)
CA promotes better outcomes across UX, risk, ROI, and your brand.
Speaker: Andrew
Risk is hard to quantify because it’s hard to measure the absence of something—in this case, accessibility lawsuits. It takes effort to ramp up on any new processes or tools, but it’s less risky to do consistent accessibility work all the time instead of having to drop everything to fix features that have already shipped and might be adversely affecting users. You’re more likely to get sued if inaccessible work makes it out into the world, so CA helps reduce risk.
Why is CA what we want? (4 of 5)
CA promotes better outcomes across UX, risk, ROI, and your brand.
Speaker: Devon
CA also means a11y is being considered at all phases of the product lifecycle from initial requirements, through design, to dev and QA so a11y issues are identified earlier in the process when they’re cheaper to address.
Why is CA what we want? (5 of 5)
CA promotes better outcomes across UX, risk, ROI, and your brand.
Speaker: Andrew
Have folks here seen Apple’s “I’m Not Remarkable” ad? It’s really good and I think it shows that disability is having a bit of a cultural moment. Other similar ads include Google’s “Javier in Frame”, Nike’s ad “The Relay”, Amazon’s “Morning Ritual” ad in the UK, and Microsoft’s “We all win” Xbox ad from a few years ago. These are some of the most brand-conscious companies in the world and they’re all trying to show that they’re making life easier for people with disabilities because consumers are paying attention to whether companies are doing the right thing, arguably more than ever before.
Devon note: Dare we say that in the current economy differentiating yourself from the horde of bootlickers is a good move to preserve your humanity?
The audit/repair cycle
Speaker: Devon
The biggest barrier to CA is the audit/repair cycle that most organizations get into. Usually this is in response to legal or regulatory changes. On this slide we have a graph showing 2 trends of bug counts over a 3-year period. A blue line labelled ‘Conventional, yearly audits’ depicts large, yearly spikes in the number of bugs reported. To contrast that, a purple line labelled ‘Continuous Accessibility’ depicts a large spike in initial bugs filed, followed by a steady, but manageable stream of bug reports over the remaining time period.
Episodic versus continuous work
Episodic work interrupts, aggravates and creates resistance. It’s like swimming upstream.
Continuous work flows with processes & practices. It’s like swimming with the current.
Speaker: Devon
To help us think about the difference, organizational psychology has the concept of episodic and continuous work. Episodic work, for example, interrupts regular process flows. It creates resistance. It’s like swimming upstream. Continuous work, instead, flows with processes and practices. It’s like swimming with the current.
Episodic accessibility work examples
Individuals and teams have periodic, often unplanned-for engagement with accessibility.
– Audits focus on already-released products – A11y work is focused on redesigning, repairing, retrofitting, and refactoring to address audit results – Code red/emergency shipping to put fixes into place – Occasional, “emergency” training that lacks context ^1 – Testing happens after work is already “done”
Speaker: Devon
On vendors: Not shitting on vendors (we are vendors!) but the information that’s taught is usually generalized. It’s rarely specific enough to be actionable without follow-up training that has more context into the organization’s specific roles, tools, processes, and practices.
Continuous accessibility work examples
Individuals and teams have ongoing engagement with accessibility activities.
– Testing happens during each phase of the software development lifecycle (SDLC) – Accessibility work is done all the time (i.e., not just during twice a year sprints) – Accessibility issues are prioritized and fixed alongs with other bugs – Training is informed by individuals’ roles and contextual to the work that people are doing
Speaker: Devon
Episodic versus continuous work in practice
Speaker: Devon
Typically any accessibility work starts with urgent, episodic activities. The idea is to gradually, over time, identify ways to fit accessibility work into continuous activities so that the stress, resistance, and frustration that builds up in the face of all this episodic work decreases. On this slide we have a diagram showing episodic and continuous activities like audits, remediation, training, systems work, and the creation of an accessibility team over the course of a year. At the beginning and middle of the year, the activities are all episodic, creating an increase in resistance over time. As activities become more continuous later in the year, resistance decreases.
In summary: Doing accessibility work reactively is doing episodic work by default.
Speaker: Devon
If you’re always playing catch-up on accessibility work and never making efforts to make activities more continuous, you will never, ever catch up.
Episodic/reactive accessibility work others disabled people.
Speaker: Devon
I also want to note that only treating accessibility work as episodic or reactive says that disabled people are not the norm, and we should only engage with or address their needs when someone or something forces us to. This actively others disabled people.
“Requirements” for CA
There is no one way or one solution to do any of these things.
Continuous accessibility is a system that works best with at least three parts:
– People – Processes & practices – Tools
Speaker: Devon
The goal of the system is to gradually reduce resistance and move from primarily doing episodic work to primarily doing continuous work. There will always be stones in the stream that create resistance, but we can create the most sustainable continous s continuous accessibility system.
People
– Different roles – Different experiences and backgrounds – Community with disabled people
Speaker: Devon
Processes & practices
– Process: What are people supposed to be doing? – Practice: What are people actually doing?
Setting realistic a11y goals and measuring maturity requires knowing both of these.
Speaker: Devon
Tools
– Need to support accessibility goals across the SDLC – Need to fit with processes instead of forcing them – Need to be held to a high standard
Speaker: Devon
Asana case study
Based on “End-to-end testing leveled up the way Asana engineers think about accessibility”
– People – Processes & practices – Tools
Speaker: Andrew
I’m going to share a real-world example using the framework Devon just established of People, Processes & practices, and Tools that support instead of detract from the work. This is all based on an article on the Assistiv Labs website that we co-published with our friends at Asana. It’s titled “End-to-end testing leveled up the way Asana engineers think about accessibility.”
Asana case study
People
Asana invested in building out a cross-functional accessibility team including program management, product management, engineering leadership, accessibility specialists, and QA.
Speaker: Andrew
Over the last few years, Asana invested heavily in accessibility— building out a cross-functional team including program management, product management, engineering leadership, accessibility specialists, and QA—all with the support of executive leadership. It was kind of a best-case scenario to get so many specialized resources dedicated to the problem, but there are always challenges when an organization builds out a new, influential team this quickly, especially when its objective is to make change. Thankfully, in this case the group had a clear mandate and the authority to carry it out. The people part they nailed pretty early on.
Asana case study
Processes & practices
– Started with automated scanners + manual QA – Made a distinction between audit bugs and regressions
Speaker: Andrew
Initially, Asana followed fairly typical practices that included deploying automated scanners and ramping up manual QA to identify accessibility bugs, as one aspect of the program. These efforts helped, but with a couple of caveats: First caveat: Scanners such as axe are fast and can be integrated into the software development process, but are limited in terms of what bugs they can identify. Cameron Cundiff, technical lead for accessibility at Asana, estimated that their automated tooling covered only about 30% of WCAG success criteria. Second caveat: Manual QA can be high quality (though that’s not a given), but is always time consuming due to it involving humans, which leads to bugs being reported sometimes only after work has shipped, which is not ideal. More germane to CA, it only finds problems. It doesn’t record working states of the software, which limits your options for prioritizing the bugs it does find. Asana early on smartly adopted processes that made a distinction between bugs found during audits (whether via automated testing or manual QA) and bugs that were true functional regressions. An audit bug is one where you don’t know when it happened, but you know there’s a problem, whereas a regression bug is one where you know it was working at one time and now it’s not. Audit bugs typically got screened for severity & impact and were prioritized (or not) by product teams as they saw fit, whereas regression bugs were assigned a time-based service-level agreement or SLA. Having an SLA means the organization agrees that the bug needs to be fixed within a certain timeframe. There was a gap, though, which is that when triaging bugs, it wasn’t clear whether they were regressions or not. Figuring that out required a lot of investigation. Sometimes they could figure it out and sometimes they couldn’t, so it was a little more hit-and-miss than they wanted whether they could categorize something as a regression or not. By improving tooling (which we’ll talk about next), Asana was able to change the dynamic around accessibility regressions, specifically.
Asana case study
Tools
Assistiv Labs’ Evergreen Accessibility Audits service delivered 2 unique capabilities:
– Every regression now has a recorded “before” and “after” state. – The speed of bug reporting means developers are often still in the context of the work that caused the bug.
Speaker: Andrew
A little over 2 years ago, Asana signed on as an early customer of the Evergreen Accessibility Audits service from Assistiv Labs. That engagement began with an expert human audit of their high-priority user flows. Those audits were encoded into end-to-end tests that ran (still run, actually) multiple times every day, repeating the human audit in an automated way, allowing for direct attribution of regressions to specific changes in the codebase. The real game changers from Asana’s perspective were that: The system records the state of the system with each test run, which effectively provides a “before” and “after” state showing exactly when the bug was introduced. By knowing exactly what code change caused the bug, it was far simpler for a product developer to go in and fix it. The speed at which bugs now get identified means the developer who shipped the regression is usually in the same product context. Because it’s not 2 sprints later and they’ve moved on to some unrelated part of the codebase, they can more easily jump back in and fix the problem. A lot of times they’ll do so within a day or so of a regression being identified. To read a couple of sentences from the article on assistivlabs.com on the subject of the speed of bug reporting: “In practice, this means that regressions are usually flagged within 24 hours of a deployment and documented in a way that is easy for engineers without a background in accessibility to understand. That allows Asana’s accessibility team to set an SLA for addressing regressions and leave product teams to it. No one has to make the case for which regression comes first or second or last. They’re just bugs that need attention.”
Asana case study
Conclusions
– People: Having a team covering the several roles involved in the work is key to making progress in a big organization working on a complex product. – Processes & practices: It’s important to understand what systems & parameters are going to make sense within your organization’s culture. – Tools: Integrating great tools can unlock stepwise improvements in effectiveness.
Speaker: Andrew
In summary: Having the right people focused on improving accessibility is key both to making progress and ensuring people don’t burn out on the work by, like, the second week. A lot of organizations set people up for failure by trying to find a unicorn, someone who can do everything from program management to fixing a date picker, which is too much scope for any one person at any large organization. That was one thing Asana did well was to have several people focused on accessibility, each with different skills and specialties. Early on, the Asana team recognized that the distinction between audit bugs and regressions was going to be an effective lever in their organization for motivating their product teams to take action. And then, having tools in place that allowed them to make that distinction meant they could change the culture around accessibility bugs and have confidence that—at a minimum—the product wasn’t ever getting worse. They could set a floor and know that they were making incremental progress. However fast or slow the progress, they knew that they could count on consistently improving their accessibility posture.
Starting CA
CA requires changing people, processes & practices, and (sometimes) tools.
Speaker: Devon
…so let’s talk about getting CA started at your organization.
“How can I make change in my organization without a mandate from senior leadership?”
– Impact climate instead of culture. – Go where people already are. – Build competence, not expertise.
Speaker: Devon
One of the first questions you’re probably asking is…
Organization structure
Speaker: Devon
On this slide we have a diagram showing an organization’s structure in a pyramid shape. The majority of the pyramid is made up of individual contributors, followed by a smaller number of PMs and POs, followed by a very small number of people in leadership at the top. The top of the pyramid is the seat of culture and authority, and the bottom of the pyramid is the seat of climate and grassroots support for accessibility work.
Culture versus climate
Culture
– Set by leadership – Official missions, values, and goals – Official policy and procedure
Climate
– Set by the majority – Unofficial missions, values, and goals – Unofficial policy, process, and practice
Speaker: Devon
Next steps (1 of 4)
There is no one way or one solution to do any of these things.
– Enable people – Engage with existing process and practice – Use tools you already have
Speaker: Devon
Next steps (2 of 4)
Enable people
– Identify allies – If you don’t have a community of practice around accessibility, start one – Influence your climate – Encourage information literacy so people can think critically and make their own decisions
Speaker: Devon
Next steps (3 of 4)
Engage with existing process and practice
– Find out what people are doing right now so you can build a picture and benchmark to start tracking maturity – Put information in places people already go, such as role or team handbooks, design systems, and component libraries – Prioritize accessibility work that prevents harm and blocks users from completing tasks
Speaker: Devon
Next steps (4 of 4)
Use tools you already have
– Use what you have available—using something is better than nothing—and use it consistently to set a baseline – Automate what you can automate – Gradually introduce other testing tools and manual testing
Speaker: Devon
What’s one thing you can do starting tomorrow to move towards CA?
Speaker: Andrew
Thank you!
Find us online!
Speaker: Andrew
Resources/references
– Apple: I’m Not Remarkable (video) – Assistiv Labs: Creating accessibility systems to fix accessibility issues – Assistiv Labs: End-to-end testing leveled up the way Asana engineers think about accessibility – Devon Persing: The Accessibility Operations Guidebook – Forrester: Accessibility Is Still Vital For Businesses – Melanie Sumner Temple: Continuous Accessibility: Strategies for Success at Scale – ResearchGate: Integrating Software Assurance into the Software Development Life Cycle (SDLC) – RTI: The Economic Impacts of Inadequate Infrastructure for Software Testing (PDF) – Scope: Attracting more disabled customers and the Purple Pound – TestParty: 15 Digital Accessibility Statistics That Prove ROI in 2025 – WAI: Accessibility Maturity Model – WAI: The Business Case for Digital Accessibility
