Sloan's Inbox: Any advice on how to advocate for a11y improvements at my org?

Depending on where you are located, or your target audience, there may be legal implications to not conforming to accessibility standards. Try speaking to the legal team at your organization. For example in Ontario, Canada, not having an accessible site can land you in hot water, and can incur hefty fines.

I would hesitate to raise this from either a legal compliance POV (not your paygrade, in essence), or from a "on behalf of others" POV. Difficult to sell the need, when other instances have decided (actively or passively) against it. It may be important to note the point raised, but in terms of getting results, that rarely works.
If you, personally, would benefit from those changes, use that. Most companies appreciate positive change feedback from within. Explain why it would help you (even if you're not strictly the "target audience"), and show how that's the case.

My team is in charge of our CRM, and we often end up implementing a11y-adjacent features because it actually helps most of our "clients" (in-house CSAs) even just by improving workflows, or allowing them to multitask more easily. And in most cases, those are raised by the employees asking for something to make their life easier - and that can very easily overlap with a11y, because the point of a11y is often exactly that: impaired capability in one area made up for by improvements in others.

The challenge you're going to face is that for many products, there is either insufficient ROI or Risk to motivate teams to invest further in accessibility. Most businesses building products today have finite time, money, and resources (labor) to build products and grow their business, so it becomes a game of negotiating priorities. Incorporating a11y may seem (or be) trivial, but so is writing tests, and we all know that's not easily adopted in mass either.

How I would approach adopting enhancements to a11y:

• Develop an understanding of both the problem, and the solution(s). Trying to get buy-in on a vague idea is going to be harder than providing guidance on how a team might be able to incorporate a couple new changes to their development patterns.
• Pick your battles. There may be many different ways to approach a11y, and while the ideal would be to address them all, it may be easier to get partial buy-in on some changes now. If achieving fully-compliant a11y require a re-architecture of a codebase, that's going to require A LOT of political capital and may conflict with revenue-centric objectives.
• Understand the impact of what you're advocating for. Incorporating a11y isn't simply adding code, it's also the subtraction of time away from other tasks. That time could be a few minutes per task, or it could be an epic spanning months or quarters.
• Get buy-in on meaningful metrics. I'm not personally convinced Lighthouse is the best indicator for this, so if you were making this pitch to me, you may have to first educate (and then sell) me on the value of Lighthouse as a metric.

I gave a talk on this for a Codementor event last year! https://www.youtube.com/watch?v=6FtMMXaAJEk&list=PLCc9e300CegTpA_Bq_BieU1Hl3Fe6KzKv&index=5&ab_channel=Codementor

The tl;dr (tl;dw?) is:

Frame your messaging to your audience. Our motivations can be found in moral, legal, and financial areas.

Moral: Making our app accessible is the right thing to do.

Legal: Making our app accessible will help us avoid lawsuits or failing to meet contractual obligations we may have.

Financial: Making our app accessible will open up our user base, unblock potential sales/contracts/deals, and lead to increased revenue.

Additionally, I think most developers want to build accessible content, they just may not have the right resources. Some potential friction points are:

• They don't know how to make accessible content, so they don't. Or, they try, run into issues, and give up. We can solve this by providing trainings, resources, mentoring, and code examples. This can take months or years, so be patient!
• They don't feel like they have enough time to focus on accessibility. This is coupled with a lack of skills, where it takes them too long and they feel pressured to just ship the feature. We can solve this by having everyone in the software development lifecycle committed to building accessible content, from product to design to dev to QA.
• They don't feel like the company values accessibility. We can solve this by having upper management be very vocal about their support for accessibility. And if upper management isn't on board yet, go back to the original talking points for how to get them onboard.

Hey there!

I have been working in the accessibility field for almost 8 years now and The biggest thing to help get folks on board with it is to take small steps for big gains. Leadership buy-in can be tough, however the one thing that tends to get leadership on board, and that is getting them off the argument that "Accessibility is all screen readers". I normally ask folks in the room "how many of you use standard font sizes on your phone?" The answer almost always is none. Guess what that is accessibility! If you want an aging population to care about the content you create and use it, accessibility has to be included. Having an eye opening moment showing accessibility is more than one disability has worked wonders for me

On another note, You mentioned lighthouse, that is a great start! But if you want to build and get buy-in start smaller with dev teams. Getting developer buyin can lead you to showing leadership how simple it is.

Work to push for development teams to use simple thing such as linters with accessibility rules and ensure they are fixed on commit. The next thing to do is begin advocating for accessibility within automated pipelines, this then creates a system of regression.

Each org and situation is totally different from the other. The toughest job accessibility advocates have to deal with, is change management. Keep grinding and keep after it and eventually the moment of impact will happen!

1. Could be illegal.

2. Improves SEO, which may lead to more money for the org.