Creating a Culture of Accessibility

[00:00:00]
>> Let's talk about the things that go beyond code, that go beyond assertions. Sometimes the people are what we have. If I couldn't get those tests working in time at work, I'd have to put it down and move on, just like we did right now. And so sometimes, we need to work around that to work together so that we have human power to cover it.

[00:00:26]
The computer wasn't quite there for me to get that test coverage. So I'm gonna write testing, how to reproduce it manually in my PR. If I couldn't get my test coverage in on time, but I needed to ship that fix, I would tell my human colleagues how to reproduce that.

[00:00:43]
So it's actually kind of a teaching moment that our test didn't work, because you might run out of time. And so, we don't wanna just drop it. We definitely want our team members to be able to test out things in PRs. And if you give them testing steps, they might actually follow them.

[00:01:01]
That's the thing. It's kind of like if you never tell anyone how to reproduce a thing, depending on your code review culture, they might just rubber stamp it and not look at it. Like, they'll look at the code, but they won't go very deep. I'm trying to help my teammates.

[00:01:16]
Yeah, careful what you wish for. I'm trying to get my teammates to give me more thorough code reviews, but they're awesome. When it comes to how to reproduce something, we could really help our teammates and our QA friends out by saying like, hey, here's how you get this into the state, here's how how it should work.

[00:01:35]
And that's like documenting that contract in words where we could also use automation. We should try to get there. I would be doing more efforts on Monday to go and fix those text at work. So, when it comes to our organizations, we wanna build up the institutional knowledge so that say I had a medical emergency and I couldn't go back to work for a while.

[00:02:01]
How tough would it be for my team if I'm the only one that knows anything about accessibility? What we really wanna get to is so that more people know about it, so that you're more sustainable with it, because it's not falling on one person's shoulders. It's spread around.

[00:02:20]
And we can do so much better that way, because we have more perspectives, more people who have their hands in it. So we increase our institutional knowledge. Accessibility specialists work very hard to get people to care. Sometimes it can be very difficult, but there's different approaches to this.

[00:02:36]
Training, doing audits, doing hands-on accessibility engineering. But it sometimes feels like boiling the ocean when your efforts could just be deleted with a pull request or a leadership decision. So that's partly why we really need this to be a team sport. The more people we have aware of it, the more successful it'll be.

[00:03:01]
So we want a culture of it. Rather than isolating this to a few people, we want a broader effort. We need a culture around it, just like you might have a design culture or a testing culture. We wanna adopt an accessibility culture, a civil rights culture. It's like that has some weight to it.

[00:03:20]
That's really what this is about. So we started the day talking about that, we looked at all of the technical parts. I really wanna bring us full circle back to what that's all about, and that is that it's about people's civil rights. So how can we do that in a way that's real, but palatable?

[00:03:40]
It's like we wanna balance what's at stake with bringing people along and persuading everyone. So here are some tips. Do user testing. Nothing gets designers attention more than watching someone fail to use something that they've made and they loved. And share recordings. You can record those usually. When I worked with Faible, I had recordings of those calls that I could share with my teammates.

[00:04:06]
So not everyone needs to be present for that particular meeting. You could share those assets and many people could learn from that. And really more than the result of that one user test, the effect long-term is that it can teach your team how people with disabilities use the web and how they use your product, and that is worth its weight in gold.

[00:04:28]
Put an accessibility statement on your website and share the feedback that people give you with the relevant teams. And I have a link here on what goes into an accessibility statement. It's usually on the footer of your site, just like with your privacy statement. It's a place to give people a way to contact you, a way to say, hey, we're aiming to meet WCAG 2.0 [LAUGH] double A, even though it's 20 years old.

[00:04:55]
We are trying to meet WCAG 2.1, whatever standard you're aiming for, document that. And don't be like, we're compliant, probably not helpful. Say, we're working on it. We're aware of it, where it's the standard we're aiming to meet. Because you don't wanna make false claims. You wanna be real about it and invite people feedback.

[00:05:16]
Because any feedback you can get from real users, those are gifts. It's amazing. Include accessibility documentation in easy-to-find places, such as testing tips, user short testing, or sorry, user keyboard shortcuts. Like, are users gonna ever be able to find those? And for your internal folks, are there docs on how to test things?

[00:05:43]
If there's a place that you could share that, that'd be awesome. Have lunch and learns. Maybe you could watch a conference talk or something as a team. Or maybe your team member wrote something for accessibility and they could do a quick demo on it. Make a culture of knowledge sharing.

[00:06:03]
If you're in an office, take a cue from Google. They used to put a printout in the bathroom stalls [LAUGH] to kind of catch people when they're taking some time to themselves. I mean, you could have a tip. Something really bite-size, easy to remember, just like some workflow tip for accessibility, awareness tip.

[00:06:25]
Talk about accessibility in planning, design, and code reviews, bring it up. The earlier the better. But that's how this work gets done. That's where the rubber meets the road is when we bring it up, and we do something about it. Do the best we can there. And make everyone responsible for it, not just the one champion.

[00:06:47]
They're gonna burn out, maybe. That happens. And we wanna take care of our team members, like your tech leads, watch out for burnout. Because it's unfortunately common in accessibility. People have lofty ideals and we wanna do good and we want to make a difference, but it's not always sustainable.

[00:07:07]
It's hard to hear no when you're like, but this is essential. It's a tough place to be in. So watch your team members, try and have those working relationships where they trust you to actually tell you how things are going. And find sustainable improvements that bring joy and satisfaction.

[00:07:24]
Find the things you can control, that you can do, and cross some stuff off your list, get some wins. And of course, these are all my suggestions. These are just things I've seen over time, leading teams, being on teams. And so your mileage will vary. I mean, teams are so diverse and made up of so many different people, and constraints, and all the things that make our teams unique.

[00:07:48]
So you have to kind of find what works for you. But at the end of the day, this stuff matters because it's about improving access. So, we wanna try and do our best and push the limits whenever we get that opportunity. It's like, if we just stretch a little bit, maybe we could get this in.

[00:08:06]
We wanna be civilized about it. We don't need to overwork ourselves or something. But if you can just push a little bit harder to get something in, that would be pretty great.