From Reactive to Proactive: Building a Sustainable Accessibility Program

Okay. So... Welcome, everyone. I'm very happy to be here today.

And talk about how to build an accessible -- a sustainable accessibility program.

There is an image on the screen of people coworking in an office. Just something to bring us there. Okay. So... First of all, before we dive into the content, a little bit about me.

My name is Lina Trifon. I use she/they pronouns. I identify as queer, disabled, and neurodivergent. I help organizations build accessibility programs.

I've done that in several organizations. Currently doing that as Senior Product Manager of Accessibility at Ellevation Education. And previously at Ovia Health.

There is an image of myself on the screen. To those that can see me, I'm a white femme with black straight hair. And large glasses.

So... In today's agenda, we're going to acknowledge the challenges that we have with accessibility programs. We're going to introduce the accessibility maturity model, and how to best use it to inform your program. And then we're going to talk about the dual track strategy that I use for actually creating sustainable practice.

And at the end, we'll have a couple of resources. And time for a Q and A. In the image on the screen, it's a winding road in a colorful field.

All right. Some of the fun challenges with accessibility programs. I'm sure none of you have felt... Or experienced any of these.

Okay. I'm sure all of you have experienced at least one of these. Let's be real. So... First we have overwhelming technical debt.

Usually you start with accessibility. Oh, we need an audit. We have a gazillion issues found, and what do we do with all of them? Don't forget that besides accessibility, we have competing priorities.

So... There are things that our stakeholders like to call strategic priorities. I'm sure none of you have heard these words before either.

That basically... And accessibility, unfortunately, by most, is not considered a strategic priority. Which we hope to change. But... The change is slow.

We have limited resources. Because usually either most of them are working on the strategic priorities, or you're a team of one or very few people that is actually doing the job. The work. There are knowledge gaps.

So...

If they haven't considered accessibility, it means that most likely not a lot of people will know what it is. And why it's important. And there's lack of buy-in. Which is both... When we think of lack of buy-in, we usually think of management.

But it can come from levels of the organization. And it can lead to resistance to change as well. So... If you don't get people on board, they will fight you.

So...

I presented a lot of challenges. And these are not all the challenges. How do we even start tackling them?

So this is... In the image, you see Alice speaking to the Cheshire Cat. It's a paraphrase of Lewis Carroll's Alice in Wonderland and says: If you don't know where you are going, any road can take you there. And the reason I'm showing you this slide right now is because: Really, before we start running, we need to understand where we're going.

We need to understand where we are and what is the state of accessibility of our organization before we proceed forward. So... Introducing the accessibility maturity model.

This model basically gives you a roadmap with very clear next steps to improve accessibility in your organization. And this can work for a lot of different organizations.

It helps set realistic goals and measure progress. Because oftentimes there are so many places you can start from that you don't even know what to tackle first. And another important point is that several different frameworks exist of maturity models. Today we're going to discuss one of them.

Which is the W3C framework. It is directly from the W3C website.

And it has four steps. So the lowest step -- and where often organizations begin -- is inactive. Basically on the inactive level, there is no accessibility program or awareness in the organization.

In the launch state, which is the second step, there is some initial accessibility effort and some awareness beginning. But it's still very new and disorganized. The integrate phase is the third phase, where accessibility becomes part of the standard workflows in the organization. And it's starting to become more normalized.

And optimized is our highest level, which we all strive to achieve, which means that accessibility is deeply ingrained in the organization. And in the company culture. So the way you work with this is actually... You can fill out... On the W3C website, there is I believe a form that you can review.

And fill out for each of the 7 criteria that you have...

Let me rephrase. There are 7 criteria that are measured in this maturity model. You can fill out the form yourself, to see where your organization stands. I am not going to discuss all the 7 aspects today.

I'm actually going to talk about 2 of them, which are the two I most commonly tackle first. Because I come from product management. So we're gonna talk about the information and communication technology development life cycle, or software development life cycle, as you might know it. And knowledge and skill building.

So before we dive into the solution, I'll tell you a little bit about where my journey usually starts. I will try not to touch this, though. So I usually enter the organization at the launch state. Where there is a little bit of buy-in from leadership.

But that's about it.

There is some awareness that accessibility is needed. But what exactly is the need? Do we need a team? Do we need one person?

What are the jobs to be done? Is a lot more flexible, a lot of times.

I have been a team of one. I have been also working with a team of my own. So different organizations will have different resources. Resource allocation for that.

But usually we start with launch. And my first goal is to get to integrate.

Okay. Now that we've covered the maturity model, and we know where we are starting from, and where we're going, let's talk about how we get there. So...

What I propose is really the dual track strategy that I use. And we have two tracks there. One is reactive and one is proactive. The reactive track is all about making sure that your existing product, your existing accessibility gaps, are handled.

Are addressed. To the best of your ability, of course. And the proactive track is about making sure that accessibility becomes part of your day-to-day workflow, and becomes embedded in your processes. So that going forward, you don't create more accessibility problems.

And we're going to now dive into each of those areas.

So... The reactive track...

Usually where we start... Or where I find myself starting... Is addressing legacy debt. In organizations that I've been in, there was usually either already an audit done, or we needed to do an audit to understand... What is the status of our product.

Usually we do that on the client-facing product, of course. Because it's much harder to get buy-in on internal products. And we need to start somewhere. And that is a good place to start.

In audits, obviously there are internal versus external audits, manual versus automated. My two cents... In that space is... I usually prefer external audits, because they read as more reliable for clients.

Especially in fields like education, healthcare, finance, or highly regulated fields.

Additionally, when I select a vendor, it's really important to me that they're really focused on manual testing. And the manual testing is the main aspect of what they do. Because this is how we catch the most... This is how we make sure that we cover our bases and catch any potential accessibility gaps that we may have in our product.

In terms of prioritization, there are many different ways to prioritize them. Also... Side note... Each of these steps can be its own conversation.

So...

I understand that. I'm giving more of an overview. So in prioritization, what I like to consider is the frequency of use. How many... Is this your homepage?

Or is this the page that maybe 2% of the population of your user base is using? The severity of impact. Is this a blocker for users with assistive technology, for example? Or for some other user group that prevents them from actually completing their task?

Or is this just an inconvenience? Which takes them more time, and obviously we want to fix, but... They can still use the product. And your product roadmap.

Which means that if a feature is planned to be retired or rebuilt in the next, let's say, year, you probably are not going to invest in fixing the old product. Because it's going to be retired. And you're probably not going to get buy-in to fix the old product. Because it's going to be rebuilt.

So thinking instead of putting a bandage on something that doesn't work anyway, instead shifting the focus to: Let's embed accessibility from the get-go in the requirements for the new product. For the rebuild.

The prioritization part is really important, especially for leadership level. This is where you basically package the tens or hundreds of issues found from the audit into something palatable of a roadmap for your teams to be able to say: Oh, we understand. We're not overwhelmed. And we can potentially do this.

Because if you show them a spreadsheet with hundreds of bugs...

They might freak out.

A little bit. So after you've gotten the prioritization out of the way, you got the alignment. You know what you're doing in terms of road mapping. Consider the remediation part.

I prefer to address issues in batches. By component or user flow. And I find that a lot of the audits have, like, for one component, they will have a list of issues. And addressing each of them separately is going to just take more time from a developer, designer, product manager, and everyone involved.

So... Collapsing them into batches makes the most sense. Okay.

One important element that I would be remiss not to mention is component libraries. So component libraries are a really great asset to leverage, when doing remediation.

Component libraries, to those who are not familiar, are a collection of prebuilt, reusable UI elements. User interface elements. Like buttons, forms, and icons, that help developers and designers build digital products more efficiently. So in some organizations, the component libraries are part of a design system, and they live in both the designer and the developer space.

But in other organizations, sometimes it's just... The developers will have that information. But it's not gonna be visible to other stakeholders. So if you don't know if you have a component library, or if you're using shared components, ask your developers.

I think it's really beneficial to prioritize component library remediation early in your reactive work. Basically one component fix will solve the issues for all the locations this component exists in your product. So it would have a lot of impact.

One learning that is very important, though: It's not a magic solution. So even if you fixed it in the component library, a lot of times you still need to fix the implementation part. So... Sometimes the implementation would be to update to the newer version.

Sometimes it could be to...

That they customize something there. Okay. How are we on time? Okay.

I will fast-forward. Okay.

So... And another very important point is: Don't forget to document all your decisions during the remediation phase.

In a previous organization, we didn't have a component library or a design system. So what we did was we created a design decision log, but we called it -- which was a document, where we put together all the decisions that we made, so that all of the relevant stakeholders that work on new components or new features can go and foresee: What are the decisions that were already made about forms, let's say?

And then take it from there.

And this image is from Mantine Component Library.

This image I found entertaining. It's a woman juggling balls that have the words "debt" on them, while drowning in new bugs and barriers. On the white board next to her, the words "sustainable accessibility program" are crossed out. This of course is an AI image.

Reactive work is great and necessary, but unfortunately it's not sufficient. Because you will keep drowning in more debt. So that's where the proactive work comes into play. In the proactive track, we really are working to shift left.

And by shifting left, I mean: Building accessibility expertise and accountability into the earliest stages of product development. So you want to make sure that they're really part of the process. For everyone. So the three steps that I found helpful first is the training.

Training is great. To make sure that accessibility is understood.

That people understand the need for accessibility. And people understand what it does on a basic level. You also want to do both... This is more of a general training, but you also want to do role-specific training to make sure that people of different roles know what it is they need to do specifically for accessibility.

Also another key point is making training and learning ongoing, and not a one-time thing. Because people will sit in a training, and then they will forget all about it, if they don't practice. The second step is guidelines.

Which is basically to make sure that accessibility is easy to do. Or as easy as possible for them to do. Reduce the friction. So there are so many criteria.

Right? And people get lost in the sauce. So what we want to do is...

What I found useful is actually creating role-based best practices and checklists. For people to go through. I know it's... Some people say yes to checklists.

Some people say no. I found it helpful for my teams to at least start somewhere. And that helps them get in the habit of considering accessibility. And that is also something that is easier to put into a workflow of, like, and put into requirements of...

Check these... Review the checklist. Then other things.

Than...

This is more concrete than just... Make sure it's accessible.

And the final step is process integration. This is to make sure that accessibility is required in the organization. Not just that it's nice to have or we will do it if we can. If we have the time.

If we have the capacity. No. This is required. We have to do this.

And this can be done by introducing accessibility checkpoints at different stages of the development life cycle. For example, in design reviews or code reviews or QA testing.

Also I found it useful to include accessibility design annotations for the design team to be able to produce... To communicate accessibility with the rest of the stakeholders in a clearer way.

All right. Back to our accessibility maturity model. So...

After taking all of these steps, we basically want to get to integrate. And if we took the steps, we're well on our way there. However, we need to remember that there are other components to accessibility. Like procurement.

And HR practices. So those need to be taken into account as well. Unfortunately... We don't have enough time to dive into all of the criteria.

At my...

In my previous organization, in my current organization, we've been working on that track to get from...

To integrate. And in my previous organization, we were successful, to the point where it has become part of the process. And it was just a regular part of the process. No one even considered it to be an add-on anymore.

Which was great. At my current organization... We're still in the process of doing that.

So... In conclusion...

The dual track steps. You want to assess your accessibility maturity. Understand where you're at. And where you're going.

Equip and empower your teams by giving them training, best practices, checklists, anything that would make their job easier to do. Tackle legacy debt. Audit and address existing issues by priority. Shift left proactively.

Integrate accessibility into the software development life cycle. And in other areas of your organization. And the last is: Iterate and optimize. Because no two organizations are the same.

This is meant to provide you with some steps to start the ball rolling. And these I found were...

The steps that produced the least amount of pushback as well to start with. And once you have a foot in the door...

You gain more influence and you get more awareness in the organization. You can expand accessibility further. So... In terms of resources... I just have two on the board here.

The first is the W3C accessibility maturity model. The second one is actually from the North Carolina Department of Public Instruction. Donna Murray, who is part of the accessibility team there, developed several really great resources on accessibility maturity levels. If you go to that link and the vendor resources on that page, you will find several resources that are relevant.

Not just to vendors, but to all organizations. It also even has a spreadsheet that includes a self-assessment rubric that you can fill out. And it will dynamically populate next steps for you, of recommendations in how to advance in each category. Which I found great.

So thank you. Feel free to connect with me on LinkedIn. And continue the conversation.

Thank you so much. Awesome presentation. So we're gonna be taking questions from online and also here in the room. Anyone have a question here in the room to start off the presentation tonight?

Thank you so much. So you mentioned that you usually join an organization at the launch cycle?

[indiscernible] with W3C maturity? And so... I was wondering if it's... Before that.

When there isn't so much stakeholder buy-in. What can we do from the product design management or development side to proactively get that kind of buy-in?

That is a great question that I feel deserves a whole talk by itself. And there was actually a really good talk here, several months ago, specifically on how to get buy-in.

The things that I would suggest is...

Start small and just... Within your realm. So start by potentially...

Checking color contrast and making sure that colors are accessible of your brand. Or... Doing something... Find a few items where you can really...

If you're a designer, for example. Find a few items that you can really move the needle on. And start talking about it and start bringing it to awareness in every conversation.

Something that... If you've been to a few of these, you've probably heard me say this, because it's kind of my refrain... The best way that I've found, at least in my organization and with companies that we've worked with, to get buy-in for relatively low cost, or at least get people past that first shift in thinking about accessibility as compliance to thinking about accessibility as something worth investing in, is to just... Pay for the time of a few users with disabilities to interact with whatever product you're trying to generate buy-in around making more accessible.

And ask for permission to record those sessions and put that in front of stakeholders. Get a five minute clip or highlight reel of like... Here is a real person who could be our customer, who you have a "do not enter" sign on the door of our business, for a large portion of the population. Because I've spent lots of time giving slides on business cases and all that, and it just kind of goes over people's heads.

If you can have 15 minutes with someone, compensate them for their time, to just showcase what it looks like for the product to not be usable by real people... That is worth way more in generating buy-in and going... Oh, I don't want to build a product that sucks for people. Or I don't want to not have that customer.

That's been the biggest unlock for our team. Just getting real feedback and help stakeholders visualize and understand the impact of that. It's a really low cost way to generate a lot of return. To get people to kind of get that empathy unlock.

Shame is a powerful motivator.

This is a great question from online. What kinds of products were you talking about? And they were curious if it's web-based only. I've worked on both web-based products and mobile apps.

I have also worked on a kiosk. But that's the scope. Would you say the maturity model applies to both? The maturity model applies to... This is from... So... These are parts of the product of the company.

But the maturity model applies to, I think, any organization that wants to know where it stands.

Question in the room?

Thank you. There's just so much information. I have so many questions. I'm sorry.

I don't mean to plug my product, but I actually have a product that helps with ADA compliance and accessibility on websites. And I've found... I haven't found, but I've been telling my salespeople to go out and tell them that it's illegal now to have a website that's not ADA compliant. I'm wondering if you feel like that would help as well.

Like... I know you said shame is a great motivator. But... So is, like, being sued.

Or stuff like that. Legal risk is a great motivator as well. Especially in some industries. So it really depends on the industry.

And that is part of the conversation of getting buy-in. Is mentioning... Unfortunately... That part of the equation.

You're opening yourself to risk. And you're losing customers.

[indiscernible] Yeah. As you mentioned, some of the industries are more at risk than others. Education and healthcare. Yeah.

We got another question here from online. So... How do you recommend getting departments to focus on manual testing versus automated -- and I guess also on the proactive side, versus reactive. That is... The million dollar question.

But basically... Okay. Two parts. So... Manual versus automated.

First... Making it very clear that automated testing does not cover everything. It only covers a small percentage of the issues that we can find. And it's real people that use our products.

So we want to test with real people who use our products.

And if we can test with people... If we can have users with disabilities that use assistive technology, perhaps, to test... Even better. In terms of how to do that, my approach is usually getting a foot in the door.

And giving something manageable to people, to start from. And then potentially expanding. If you start with an hourlong list of items to test, you're probably not gonna have a lot of people engaging. But if you're gonna start with something smaller, like... Just go over it with a keyboard, just go over it with a screen reader, and check what you hear.

That could be a good way to start.

A question here?

Thank you. Hi. I appreciate your insights. I've been doing this for a while.

And to piggyback on the idea of starting with legal risk, it can be initially a really powerful motivator. But it is difficult for that to be a sustained interest that expands beyond the first audit and checklist, into... How do people behave and why does it matter and why does building new things mean new kinds of interactions and opportunity to expand instead of stay in the lane. So it's kind of a double edged sword as a motivator.

Especially if you are in the long haul, somewhere. And I had a question... I've been doing this for a while... About... Things that you may have found successful in terms of integrating, for the long haul, ways to build accessibility in as a core component of someone's success in their role, as a way to draw people in, to make it something they want to be good at, to see it as something that makes them more marketable, and that encourages the prioritization and continued effort -- it's part of quality.

It's part of what you do. And therefore a lot of people want to do it, instead of somebody telling them to do it. That is... A great point.

And I think it's why I did not... What I just realized that I did not mention... In the integration phase, making accessibility part of their KPIs... So...

Accessibility part of the KPIs, meaning that both on a personal level, and on a team level, do we want to produce less than X% of bugs? Or we want to produce... We're not going to market with blocker accessibility issues. Or... Having that part of the workflow as sort of... As you treat security, of like...

This is a non-negotiable. So why is accessibility still negotiable? It should not be. And you make a really good point of actually incorporating it in people's performance reviews.

And in the job descriptions. It's also great.

I am still working on that.

So... That's the answer I have. Thank you. I'll take one last question online and then one last question in the room here.

So... This question... Partially answered. I'll add on to.

Have you ever been able to no longer need to do regular reactive track work, because the company has highly embraced proactive track? I'll just add on... I'm curious as to how long that took. Because you mentioned you did get to an environment where you had that.

So...

Yes. But it's also complicated. Yes, I was able to... At my previous company, we were able to complete most of our reactive work, actually, and make our products accessible...

Like, 95% of our product accessible.

However...

There is a downside to that. So I had a team working on that specifically. So once the team is done, and this is not looked at as a priority, they got dispersed to other priorities. Because the rest of the teams already incorporated accessibility as part of their practices.

So there was no need for additional reactive work. But also now we didn't have dedicated sole accessibility team. So... Bittersweet.

One last question in the room?

Hi. You mentioned before that sometimes you come in solo, or you would work with a team within an organization. I would like to understand the process of handing off work. Maybe when you're thinking about leaving.

Or when you're shifting the responsibility to someone else, because you won't be part of that organization anymore. Is there someone who really takes up the reins on it, when you're working within that team? What happens to the team? Is someone from the team taking on responsibility?

And the reason I'm asking is because my manager and I... We are UX designers. And there isn't a dedicated accessibility person or team within our organization. And so we're kind of volunteering our time, as well as other people within our organization volunteering our time, within accessibility.

So it's very reactive. But the proactivity really isn't there, because the motivation not there. And I would speak to my manager and say... What if my manager and I left the organization?

Nobody is really going to be picking up accessibility work. So what does that kind of sunset look like for you, when you're leaving an organization or shifting responsibility away from yourself? That is a great question. I feel like...

My perfect scenario is that I am no longer needed as an accessibility person to drive everything. Because people have internalized that accessibility is actually part of their work. Across the organization. So it's just getting done.

However...

This is usually not the common situation.

So the sunset or the leaving stage can be... It depends on, obviously...

What you've done and what you leave with. So that's why creating, in your situation, for example, a process of some sort of clear process of... Yes. We take accessibility into account.

And this is part of our process. Then you can just hand it off to the next designer who comes in, and say... This is how we work. And it just being part of the process.

But if there is no process, then it's really hard to do that handoff.

I hope that answered your question. Although... I don't know if it did. All right.

Thank you so much, Lina!