Championing Accessibility: Technical and Non-Technical Tips

[VIDEO PLAYS] Welcome to Saturday Night Live SNL, but the unpaid actor Thursday edition. Tonight stars Skye, a cartoon panda, and Skosha, a cartoon cow. Skye will play a role of a product owner and a designer, while Skosha is an engineer. Lights, camera, action!

Hey, Skosha. I'm Skye, a product panda. Hey, Skye. I'm Skosha, an engineer.

I have an awesome new feature. Super simple. It's just a button to launch a report. We designed a custom button.

Blends perfectly into the page. No border. No label. And it changes color on hover.

Custom? Custom button? Oh, I think I should use a div tag and add-on click event. That would be faster to deliver.

Sure. I don't care. Sounds good to me. Okay, Skye.

I have built it, QA has tested it, and we have deployed it to production. It's live, Skye.

Woo-hoo! Nice! Just in time. Looks just like my mock-up.

Thanks, Skosha. High-five. High-five. One week later Skosha.

Ooh. I got this email from member support. Somebody's saying they can't use the button with a keyboard or a screen reader. Oh.

Read and use a button element. And there is no ARIA label. It's invisible to assistive technology, and the color contrast fails, too. Oop.

Hey, Skye.

I have an idea. There is a NYCNLI meet-up event tonight. Want to go to the event to get some ideas to make it more accessible? Hmm.

Yeah, I'm down. We need all the help we can get. Sure. Let's go.

[VIDEO ENDS] Howdy doodle, everyone! So nice to see everyone. Thank you so much for coming. Thank you, Ben, Meryl, Thomas, Accessibility New York City, baby!

I am so excited to be here. And just a heads up, we will describe any slides as we need to. If there's images, anything like that. But otherwise... We will speak to what is on the slide.

As I said, my name is Kai Wong, and my pronouns are she or they. And I am a principal of digital accessibility at Teladoc Health, the world's leader in global... The global leader in virtual healthcare. Today I am joined by my colleague, Asha, who will introduce themselves shortly.

But first a visual description of myself. I am a nonbinary person, I have short black hair, I have gold glasses on, I'm half Asian, I'm half white, and usually I'm walking around with a big old cheesy smile. Asha? Thank you, Kai.

I'm Asha Sachdeva. My pronouns are she or her. I am a senior manager, software engineering, and championing digital accessibility at Teladoc Health. Visual description, wearing a blue collared blazer, checked one, long black hair.

Not that long. But long earrings, and smiling face. Thank you. Kai and I have led remediation of hundreds of accessibility issues.

Not a hundred, right? More than hundreds of accessibility issues. Trained over 2,000 people. Worked over shift left strategy, and today, we're excited to share some tips on championing digital accessibility.

And I would like to see if there are any engineers in this crowd. Raise your hands or smile. Yeah. I'm sure you feel like a super hero when you deploy some accessible feature to production.

Or some critical accessibility bugs -- I feel so. Over to you, Kai.

Thank you, Asha. Yes. This is Kai speaking. And let's talk about what we all came here to do.

Championing accessibility. And first, it's important to ask: What makes an effective change champion? What makes an influential leader? It's somebody who can rally around a shared interest.

Get others to rally around and move towards that shared interest all together. Somebody who has a big idea and can get others to be sold on that. And today, we're all going to become big, big change champions. Especially of accessibility.

And I want to mention: You don't need a fancy title to be a champion of change. You don't need authority to make ripple effects happen. And huge waves afterwards. What you need is passion and a few other things, which we are so excited to share today.

A little bit more about what has worked for us. First... Believe in yourself. And prioritize learning.

Learn from trusted resources. Don't get lost in the sauce. Because there is so much information out there. It's so easy to just get lost and end up on something that's not that reliable.

But make sure to at least start with the W3C. w3.org. You can look into of course the web content accessibility guidelines. The WCAG.

Any big WCAG fans in here?

Lovely crowd! I love it. Okay. I'm sure the online crowd shut down the internet with that one.

Let's not crash YouTube yet. Not yet. And of course, learn the assistive technologies. Learn the tools that people with disabilities often use, like screen readers and anything else on your phone.

Just easily open it up. Go to settings. And look for your accessibility settings and try out those different features. Get familiar with those.

Become friends with them. Not that far. But get familiar with them. And let's not forget that accessibility really comes down to people.

So get connected. Put yourself out there and meet as many people as you can. Especially those who are different from you. Because the more connections you build, the more allies you can have, and also the more that you build the empathy for yourself.

And empathy is an underrated skill in tech, for sure. Once you have the knowledge yourself, you've got to spread that sauce, baby! Spread that sauce everywhere. Spread it like pizza.

Like the sauce on pizza. Oh, you want a little pepperoni on that? You're going to get that too. Teaching others is so important.

Because it raises awareness. It builds credibility up. And as an accessibility educator and influencer, as a champion of change, do whatever it takes to capture the audience's hearts and minds.

There's a lot of Es of educating people. And I was actually quite surprised when I looked it up. There were so many Es. E, E, E, E, E. But there were three that were my favorite.

One of my favorite ones is very simple. And it ties back to keeping it simple. Which is: Educate. I love this E. But I don't love it as much as the other two.

So don't get too excited yet. But you've got to know your audience. Know what you came in to do. Speak to your audience and know what is important to them.

Explain key terms. Use statistics. But don't overdo it. You know.

We're not in a math class. We don't need to hear stat after stat. And of course, give actionable advice. This next E gets me all riled up.

Engage! Engage. Keep people interested. Or also known as... Well... This one is a little sneak peek on the having fun part.

Ha-ha. That's the third E. So going back to the second E, engage. Keep people interested.

That's one of my favorite... My favorite KPIs. Get it? KPI?

Keep people interested? Okay. Okay. Now we're talking.

Thomas is in on this one. All right. Do polls and quizzes. Who here thinks quizzes are cool?

Thank you. Thank you. Thank you. What about polls?

Who likes to do a little poll? Okay. I don't know how polls started becoming cooler than quizzes. I don't know what happened there.

But make polls and quizzes -- just have fun with people. Add visuals. Of course, use alt text, if you're having images on your slides. And leave time for questions.

Which we'll have plenty of time for later. Don't worry. And this last one. I love this last one.

Entertain! Entertain. You have to bring energy. Be real!

Nobody wants a snoozefest!

That wasn't part of the script. Share stories. Use analogies. And sprinkle some jokes.

But only if your jokes are... Good ones. I ran into somebody at CSUN AT, that other accessibility conference that everyone loves... And I was in line.

We were about to get pizza. And I was telling him... I'm going to do something on KPIs here shortly. A presentation.

He's like... Oh yeah. KPIs. That's a boring topic.

I was like... Yeah. But I'm going to try to approach it from a comedic standpoint. And he was like... Good luck.

You know, one time I gave a lot of jokes in my presentation and they told me afterwards... Those were inappropriate. And I told him... All right.

Well... You know... Probably keep yours to yourself, then. But if you have good jokes, share them.

Sprinkle them. Put them on everything. And of course... What we all love to do is... Have fun.

On this slide, we have an image of me and Asha here as chefs. We did a presentation at our company, where we were dressed up as chefs, and we gave a training on baking accessibility and the software development life cycle. We put on chef hats. We realized this was not our look, but we did it anyway, because it's so much fun to switch things up, if you can.

If that's your vibe. And of course, the background. We did the cartoon kitchen background on this one. So this is just a little flavor of me and Asha having fun.

And... Over to you, Asha. Well said, Kai. I can really relate to this.

I wish I had access to these fun and engaging accessibility trainings a long time back, when I started my career as a developer. A long time back. Especially when I had to fix these accessibility bugs. Right?

It would have made a big difference, for sure. You can relate to this. A long time back. We were fixing literally -- how to literally make it semantic.

You know? We didn't know.

I feel like it's not easy for everyone to read through all those success criteria in the WCAG guideline. Understand them. Read through them. And apply them.

It's not that easy, right? So we need to understand how to, you know, fix that problem. We need to understand how to help them out. How can we help engineers here?

Oh, sorry. So if we want accessibility to be just not the... You know... To be more than just a checklist, we really need to bring it in our team culture.

And that starts with upskilling. And I would say number one, we need to agree on what accessibility means to our... What does accessibility -- good accessibility -- mean to our company in our context? So that means defining best practices.

And making sure we have high quality trainings. Training material. And very well defined training materials with us. That's one, I feel like.

You know? People can be thinking differently. And that material should be easy to understand for everyone. The second one -- this is really working out for us.

Train new hires on best practices, as a part of new hire onboarding. What has literally changed by doing this? By embedding it into onboarding, we create a culture where inclusion is expected from day one. So that's a bigger change we have seen.

And the third one, it helps to have champions. Right? People who are really passionate and knowledgeable. These are people who can help in doing accessibility code reviews, making sure your designs are compliant, helping to respond to the clients who are sending you big emails with accessibility questions.

Making sure -- helping out and giving the trainings. You know. Creating better material. Making sure we have a planned training across the organization.

The fourth one is tailored trainings. Not everyone needs to know everything. Product owner, product designer, content editor, developer, QA -- everyone needs to have a focused guidance. Right?

So tailored training makes it more relevant and more likely to stick. That's what I have experienced. When we give people a focused -- sorry.

When we give people the right tools, trainings, and support, accessibility stops being a burden. And starts becoming a part of how we build better products. Over to you, Kai.

Yes. Asha, great points. And this is Kai speaking. Even the most beautiful design can become inaccessible if it is not coded correctly.

It's all about what's under the hood. And they hold a lot of power, engineers. And QA as well. So it's so important to train your people and tell your team to get things right the first time as much as you can.

And as you are training others, try to build meaningful relationships. Because with accessibility, you need to have everyone in on this. So get to know as many people as you can. Slow down.

Get to know people. Find out what drives them.

Meet people where they are. And in parentheses, it says: Without judgment. And on top of it, there's a word bubble that says: It's okay to not know. What matters is that you're willing to learn.

This has really been extremely powerful for all of the trainings that I think may and Asha have both given. Where the first thing out of our mouth is usually letting people know: Hey. It's okay to not know. You're here to learn.

Thank you for showing up. It really brings people into the same level as everyone. We all start somewhere. Keep that in mind.

Next, this one. Call people in, before calling people out. This one is personal. This one is personal.

I learned this one for sure. And I would definitely recommend this one. One time, I went to another accessibility conference, where I was flying home, and I'm so excited to post this picture from the conference on LinkedIn. So I'm on the Wi-Fi, on the airplane, I'm typing it all out.

I'm like... This is going to be good! I can't wait to fill people in on this conference. I'm putting my alt text up.

And I'm like... Oh, I'm going to put extra... I'm giving it a little extra sauce in this alt text. I'm giving it a little more attention.

Because I had the time. I was on the airplane and the Wi-Fi wasn't that great. But it was able to be fine for alt text. I thought... Great news!

You know? And I can't wait to land and see what people are saying back. Can't wait to get some reactions to this. And then we land.

Right? I'm not flying the plane. Don't worry. But we land.

And I get a message. From somebody who I was at the conference with. Who happens to be blind. And he said... Hey, Kai.

You think you can add alt text to your images? I was devastated! I'm embarrassed. I just came from an accessibility conference, posting pictures about a presentation I gave.

And they're now telling me I don't even have alt text? I was like... Oh! No!

But the thing is... Is that who knows what happened. Maybe I did forget to press save. Maybe the airplane Wi-Fi -- maybe there was a bug.

Whatever it was. All I know is that alt text did not land with the plane. Right? That I know for sure.

But luckily, my friend DM'd me. He messaged me. And he said... What he said to me in private -- he called me in.

He didn't put it out on a reply on the post, saying... Oh, what are you? A fraud? What kind of accessibility professional are you?

Where is the alt text? No, no. He called me in. Before calling me out.

Which gave me the chance to quickly fix it, apologize, and make things better. And most importantly, most importantly, it built trust between the both of us. My respect went up for him. And his respect... Well, I didn't ask him about that.

But we're still friends. Hopefully it's still up there. Who knows. But the point here is... That once you get the knowledge yourself, you get the allies, you're teaching other people, you can start to drive change.

And you will drive change.

First let's talk about bringing accessibility into your own work. First up, talk about it. Easy. Be the person who talks about it everywhere.

When I hang out with my friends, guess what they heard about? Uh-huh. That's right. Accessibility.

I have a few friends in this crowd, actually, who are falling victim. Just kidding. Not victim. But really, though, it is something I'm just always talking about.

I know a lot of people in this crowd are actually always talking about accessibility. That's a champion of change. You're influencing others, just by normalizing it. By making it something at every table, every party, every grocery line.

Okay. You can... You don't need to do grocery line chats. Next, make good decisions.

Make good decisions. Like who you talk to. And who you don't talk to in the grocery store. It doesn't need to be a chatty spot.

But making good decisions is so important. Just like small ones. What colors did we use in this PowerPoint? What colors did we use?

There was something when I had something in there and Asha called me in -- thank you, Asha. Hey, I think this one is not meeting contrast ratio. And I fixed it right away. Thank you.

Just small decisions. Small decisions add up. Just like not brushing your teeth for a few days in a row. One day may be fine.

A few days later... It adds up. Make good decisions. They all add up.

Check your work. Check your work. Run that PowerPoint checker before you send it off. Make sure you test your alt text when the plane lands.

And make it a part of your goals. Bring it into your own responsibility, and make the personal commitment to it.

Let's see what we have to think about for engineers. Asha? Sure, Kai. Thank you.

I'll take your strategy forward for engineers. Bringing a11y to the work... I think following small steps consistently in our day-to-day activities, you know... It makes a difference for a million users.

Without slowing us down as an engineer. If we do it in our STLC process and not as an afterthought.

Linters are the big ones, which I would say -- start it with and make sure you're putting precommit hooks. And by adding linters, you can save 20% to 40% of accessibility bugs going into production. And obviously the automation stuff as well. Okay.

I remember we had Skasha, who was struggling with the div tag, and this is of course Skasha making sure you're writing semantic code. If you're writing semantic code, half of your problem is solved. Make sure while developing it. Not like an afterthought.

Engineers, while doing your testing, unit testing, you can use any kind of screen reader. With different browsers. You don't need to be worried about one particular screen reader. QA will take care of that.

But engineers, make sure you're validating at least one round with your unit testing. Right? And I would suggest... While doing unit testing, make sure you use the keyboard.

Not mouse. No mouse. Put it aside. You can get a lot of functional accessibility issues caught early in the game.

Start writing accessibility unit test cases. No one can break your code. You know? Embed it in.

It doesn't take much time if you get it done while you're writing in functional test cases. You are deciding on your external libraries. You have a feature to be developed. You've got like a chart component.

It will take time to make it custom. You go ahead and browse it on the website and figure it out, which one is good. You check whether it's meeting your requirements or not. You know?

Also check whether that component is accessible or not. And... Plus validate whether they are continuously supporting that library or not. These are the few tips which I would like to share here.

From the engineering side. Thinking about... Before releasing it to production. And I already answered this question.

But I would like to ask you again if you were focusing on the first slide: What percentage of issues can accessibility linters catch with the precommit hook and the good accessibility linter? Anyone from the audience? You want to give the mic? Pass the mic?

Sorry.

2? 2, 20% to 40%? Yes. 20% to 40%, for sure, we can catch it.

If we're using it correctly. By embedding precommit hooks. That's pretty much from my side on. You know.

Accessibility beyond your team. Kai? Nice job, nice job, Asha. I guess we should have done a poll, since everybody in this crowd likes polls more than quizzes.

Let's really scale it up. Let's bring things to the next level. Let's talk about ways to scale accessibility beyond just yourself. First is good communication and advocacy.

One of my main things is: Don't just tell people what to do. Tell them why and how. Don't just tell people what to do. Tell them why and how.

Create a teams channel. Be the person who allows other people to communicate together with other people too. Make it a safe space to talk about it and learn about it. Collaborate with partners.

And partner with groups and allies. This one is extremely powerful. As you are going around, building relationships, you are finding allies. You're giving trainings.

And it's those people who come up to you afterwards who say: Thank you so much. That really impacted me. Because of X, Y, Z. Remember those people.

Because they are your superpowers. And you can amplify your impact through your allies.

One time, I actually had that happen to me. Where somebody came up at the end and said that exact thing. Thank you so much. This meant a lot to me.

Because of X, Y, and Z. And I didn't hear from them for maybe six months or so. I come to find out... They went back to their team and got right to work.

They changed accessibility from being an afterthought to being a mandate for their team. Now going forward, all of the learning and development that all employees get are accessible. The team test it with a screen reader and they test it with a keyboard. They make sure it's color contrast up to par, and accessibility is a part of their team culture.

The point is here: Is that those small relationships, once you start to see the ripple effect, now you're really influencing change. The most influencing happens when you're not looking.

Oh yeah. Give detailed feedback. The good old feedback. That's like... Your app stinks!

No. No, no, no. We can't do anything with that kind of feedback. Give detailed feedback.

For example... You would say: Hey. This button here, X, Y, Z, on this page... Isn't doing what it needs to, for me.

Right? There's very specific feedback. Now that's easy for somebody to go and take action on and fix. So just in general, be detailed about that.

And use metrics and tell stories. Metrics are important for tracking progress. But storytelling drives action.

And of course... Celebrate wins. Be loud about accessibility and pull up an extra chair if you need to, for accessibility to have a spot at the table. Make sure you're giving kudos out to people who are doing a great job.

I know there are several people here from the Teladoc team. We have Gina, Jared, Marissa, and other champions of change who have come across and helped accessibility grow and build and we have John Armstrong in the back as well! Woo! Thank you so much.

And this is so important to celebrate wins. Shout out to all of you who have made such a difference in accessibility at our company and also to all of you for coming here today. Just in general. Now you are here.

This shows you are ready to go make change and don't forget to celebrate wins.

How about engineers? Asha, can we scale a little for the engineers? Mm-hm. Scale accessibility beyond my team?

Yes. Make it part of your company's DNA. And empower every department to contribute. That's what I would say.

But... From a technology perspective, start embedding your tools in the CI/CD pipeline. That helps a lot. That just blocks.

You can't go to production. You have to fix it. You know? Make sure whoever has broken it -- we used to do it in my earlier company.

Whosoever breaks the bill used to get a fine and we used to have a snacks party after a month. So make sure you break it, get a fine, and then enjoy it every month. And add accessibility in your definition of doneness. And acceptance criteria.

That helps a lot. So that people are... Set expectations so people are not just guessing what needs to be done there. Right?

People guess a lot. Oh, that's how it should be working. With screen reader, with keyboard, without tab, with tab, with arrow keys -- make sure it's mentioned in the definition of doneness. Create documentation and checklists and make them role-based and specific to your user tech stack.

This is a good one, and it's working -- this is literally... I love this. Adding the checklist in the PR, the pull request reviews... It is working like anything.

Even if you have a PR review, who is not familiar with accessibility, that person is also looking into it and validating the functional PRs and the actual code reviews. By following those check lists, which are mentioned -- that checklist is not that big. It's just validated with a screen reader. Okay, you have a recording.

Just make sure you have keyboard focused elements. You know? You have all the embedded tools in there, which you automatically get -- break the build. So PR reviewer doesn't need to worry about those specific errors.

But the ones which we directly cannot validate via automation -- those are the things we need to make sure we are validating in code review. Welcome to Saturday Night Live SNL, but the unpaid actor Thursday edition. Tonight stars Skye, a cartoon panda, and Skosha, a cartoon cow. Skye will play a role of a product owner and a designer, while Skosha is an engineer.

Lights, camera, action! Hey, Skosha. I'm Skye, a product panda. Hey, Skye.

I'm Skosha, an engineer. I have an awesome new feature. Super simple. It's just a button to launch a report.

We designed a custom button. Blends perfectly into the page. No border. No label.

And it changes color on hover. Custom? Custom button? Oh, I think I should use a div tag and add-on click event.

That would be faster to deliver. Sure. I don't care. Sounds good to me.

Okay, Skye. I have built it, QA has tested it, and we have deployed it to production. It's live, Skye. Woo-hoo!

Nice! Just in time. Looks just like my mock-up. Thanks, Skosha.

High-five. High-five. One week later Skosha. Ooh.

I got this email from member support. Somebody's saying they can't use the button with a keyboard or a screen reader. Oh. Read and use a button element.

And there is no ARIA label. It's invisible to assistive technology, and the color contrast fails, too. Oop. Hey, Skye.

I have an idea. There is a NYCNLI meet-up event tonight. Want to go to the event to get some ideas to make it more accessible? Hmm.

Yeah, I'm down. We need all the help we can get. Sure. Let's go.

Howdy doodle, everyone! So nice to see everyone. Thank you so much for coming. Thank you, Ben, Meryl, Thomas, Accessibility New York City, baby!

I am so excited to be here. And just a heads up, we will describe any slides as we need to. If there's images, anything like that. But otherwise... We will speak to what is on the slide.

As I said, my name is Kai Wong, and my pronouns are she or they. And I am a principal of digital accessibility at Teladoc Health, the world's leader in global... The global leader in virtual healthcare. Today I am joined by my colleague, Asha, who will introduce themselves shortly.

But first a visual description of myself. I am a nonbinary person, I have short black hair, I have gold glasses on, I'm half Asian, I'm half white, and usually I'm walking around with a big old cheesy smile. Asha? Thank you, Kai.

I'm Asha Sachdeva. My pronouns are she or her. I am a senior manager, software engineering, and championing digital accessibility at Teladoc Health. Visual description, wearing a blue collared blazer, checked one, long black hair.

Not that long. But long earrings, and smiling face. Thank you. Kai and I have led remediation of hundreds of accessibility issues.

Not a hundred, right? More than hundreds of accessibility issues. Trained over 2,000 people. Worked over shift left strategy, and today, we're excited to share some tips on championing digital accessibility.

And I would like to see if there are any engineers in this crowd. Raise your hands or smile. Yeah. I'm sure you feel like a super hero when you deploy some accessible feature to production.

Or some critical accessibility bugs -- I feel so. Over to you, Kai. Thank you, Asha. Yes.

This is Kai speaking. And let's talk about what we all came here to do. Championing accessibility. And first, it's important to ask: What makes an effective change champion?

What makes an influential leader? It's somebody who can rally around a shared interest. Get others to rally around and move towards that shared interest all together. Somebody who has a big idea and can get others to be sold on that.

And today, we're all going to become big, big change champions. Especially of accessibility. And I want to mention: You don't need a fancy title to be a champion of change. You don't need authority to make ripple effects happen.

And huge waves afterwards. What you need is passion and a few other things, which we are so excited to share today. A little bit more about what has worked for us. First... Believe in yourself.

And prioritize learning. Learn from trusted resources. Don't get lost in the sauce. Because there is so much information out there.

It's so easy to just get lost and end up on something that's not that reliable. But make sure to at least start with the W3C. w3.org. You can look into of course the web content accessibility guidelines.

The WCAG. Any big WCAG fans in here? Lovely crowd! I love it.

Okay. I'm sure the online crowd shut down the internet with that one. Let's not crash YouTube yet. Not yet.

And of course, learn the assistive technologies. Learn the tools that people with disabilities often use, like screen readers and anything else on your phone. Just easily open it up. Go to settings.

And look for your accessibility settings and try out those different features. Get familiar with those. Become friends with them. Not that far.

But get familiar with them. And let's not forget that accessibility really comes down to people. So get connected. Put yourself out there and meet as many people as you can.

Especially those who are different from you. Because the more connections you build, the more allies you can have, and also the more that you build the empathy for yourself. And empathy is an underrated skill in tech, for sure. Once you have the knowledge yourself, you've got to spread that sauce, baby!

Spread that sauce everywhere. Spread it like pizza. Like the sauce on pizza. Oh, you want a little pepperoni on that?

You're going to get that too. Teaching others is so important. Because it raises awareness. It builds credibility up.

And as an accessibility educator and influencer, as a champion of change, do whatever it takes to capture the audience's hearts and minds. There's a lot of Es of educating people. And I was actually quite surprised when I looked it up. There were so many Es.

E, E, E, E, E. But there were three that were my favorite. One of my favorite ones is very simple. And it ties back to keeping it simple.

Which is: Educate. I love this E. But I don't love it as much as the other two. So don't get too excited yet.

But you've got to know your audience. Know what you came in to do. Speak to your audience and know what is important to them. Explain key terms.

Use statistics. But don't overdo it. You know. We're not in a math class.

We don't need to hear stat after stat. And of course, give actionable advice. This next E gets me all riled up. Engage!

Engage. Keep people interested. Or also known as... Well... This one is a little sneak peek on the having fun part.

Ha-ha. That's the third E. So going back to the second E, engage. Keep people interested.

That's one of my favorite... My favorite KPIs. Get it? KPI?

Keep people interested? Okay. Okay. Now we're talking.

Thomas is in on this one. All right. Do polls and quizzes. Who here thinks quizzes are cool?

Thank you. Thank you. Thank you. What about polls?

Who likes to do a little poll? Okay. I don't know how polls started becoming cooler than quizzes. I don't know what happened there.

But make polls and quizzes -- just have fun with people. Add visuals. Of course, use alt text, if you're having images on your slides. And leave time for questions.

Which we'll have plenty of time for later. Don't worry. And this last one. I love this last one.

Entertain! Entertain. You have to bring energy. Be real!

Nobody wants a snoozefest! That wasn't part of the script. Share stories. Use analogies.

And sprinkle some jokes. But only if your jokes are... Good ones. I ran into somebody at CSUN AT, that other accessibility conference that everyone loves... And I was in line.

We were about to get pizza. And I was telling him... I'm going to do something on KPIs here shortly. A presentation.

He's like... Oh yeah. KPIs. That's a boring topic.

I was like... Yeah. But I'm going to try to approach it from a comedic standpoint. And he was like... Good luck.

You know, one time I gave a lot of jokes in my presentation and they told me afterwards... Those were inappropriate. And I told him... All right.

Well... You know... Probably keep yours Here's the continued transcript with plain text and bolded speaker names: to yourself, then. But if you have good jokes, share them.

Sprinkle them. Put them on everything. And of course... What we all love to do is... Have fun.

On this slide, we have an image of me and Asha here as chefs. We did a presentation at our company, where we were dressed up as chefs, and we gave a training on baking accessibility and the software development life cycle. We put on chef hats. We realized this was not our look, but we did it anyway, because it's so much fun to switch things up, if you can.

If that's your vibe. And of course, the background. We did the cartoon kitchen background on this one. So this is just a little flavor of me and Asha having fun.

And... Over to you, Asha. Well said, Kai. I can really relate to this.

I wish I had access to these fun and engaging accessibility trainings a long time back, when I started my career as a developer. A long time back. Especially when I had to fix these accessibility bugs. Right?

It would have made a big difference, for sure. You can relate to this. A long time back. We were fixing literally -- how to literally make it semantic.

You know? We didn't know. I feel like it's not easy for everyone to read through all those success criteria in the WCAG guideline. Understand them.

Read through them. And apply them. It's not that easy, right? So we need to understand how to, you know, fix that problem.

We need to understand how to help them out. How can we help engineers here? Oh, sorry. So if we want accessibility to be just not the... You know... To be more than just a checklist, we really need to bring it in our team culture.

And that starts with upskilling. And I would say number one, we need to agree on what accessibility means to our... What does accessibility -- good accessibility -- mean to our company in our context? So that means defining best practices.

And making sure we have high quality trainings. Training material. And very well defined training materials with us. That's one, I feel like.

You know? People can be thinking differently. And that material should be easy to understand for everyone. The second one -- this is really working out for us.

Train new hires on best practices, as a part of new hire onboarding. What has literally changed by doing this? By embedding it into onboarding, we create a culture where inclusion is expected from day one. So that's a bigger change we have seen.

And the third one, it helps to have champions. Right? People who are really passionate and knowledgeable. These are people who can help in doing accessibility code reviews, making sure your designs are compliant, helping to respond to the clients who are sending you big emails with accessibility questions.

Making sure -- helping out and giving the trainings. You know. Creating better material. Making sure we have a planned training across the organization.

The fourth one is tailored trainings. Not everyone needs to know everything. Product owner, product designer, content editor, developer, QA -- everyone needs to have a focused guidance. Right?

So tailored training makes it more relevant and more likely to stick. That's what I have experienced. When we give people a focused -- sorry. When we give people the right tools, trainings, and support, accessibility stops being a burden.

And starts becoming a part of how we build better products. Over to you, Kai. Yes. Asha, great points.

And this is Kai speaking. Even the most beautiful design can become inaccessible if it is not coded correctly. It's all about what's under the hood. And they hold a lot of power, engineers.

And QA as well. So it's so important to train your people and tell your team to get things right the first time as much as you can. And as you are training others, try to build meaningful relationships. Because with accessibility, you need to have everyone in on this.

So get to know as many people as you can. Slow down. Get to know people. Find out what drives them.

Meet people where they are. And in parentheses, it says: Without judgment. And on top of it, there's a word bubble that says: It's okay to not know. What matters is that you're willing to learn.

This has really been extremely powerful for all of the trainings that I think may and Asha have both given. Where the first thing out of our mouth is usually letting people know: Hey. It's okay to not know. You're here to learn.

Thank you for showing up. It really brings people into the same level as everyone. We all start somewhere. Keep that in mind.

Next, this one. Call people in, before calling people out. This one is personal. This one is personal.

I learned this one for sure. And I would definitely recommend this one. One time, I went to another accessibility conference, where I was flying home, and I'm so excited to post this picture from the conference on LinkedIn. So I'm on the Wi-Fi, on the airplane, I'm typing it all out.

I'm like... This is going to be good! I can't wait to fill people in on this conference. I'm putting my alt text up.

And I'm like... Oh, I'm going to put extra... I'm giving it a little extra sauce in this alt text. I'm giving it a little more attention.

Because I had the time. I was on the airplane and the Wi-Fi wasn't that great. But it was able to be fine for alt text. I thought... Great news!

You know? And I can't wait to land and see what people are saying back. Can't wait to get some reactions to this. And then we land.

Right? I'm not flying the plane. Don't worry. But we land.

And I get a message. From somebody who I was at the conference with. Who happens to be blind. And he said... Hey, Kai.

You think you can add alt text to your images? I was devastated! I'm embarrassed. I just came from an accessibility conference, posting pictures about a presentation I gave.

And they're now telling me I don't even have alt text? I was like... Oh! No!

But the thing is... Is that who knows what happened. Maybe I did forget to press save. Maybe the airplane Wi-Fi -- maybe there was a bug.

Whatever it was. All I know is that alt text did not land with the plane. Right? That I know for sure.

But luckily, my friend DM'd me. He messaged me. And he said... What he said to me in private -- he called me in.

He didn't put it out on a reply on the post, saying... Oh, what are you? A fraud? What kind of accessibility professional are you?

Where is the alt text? No, no. He called me in. Before calling me out.

Which gave me the chance to quickly fix it, apologize, and make things better. And most importantly, most importantly, it built trust between the both of us. My respect went up for him. And his respect... Well, I didn't ask him about that.

But we're still friends. Hopefully it's still up there. Who knows. But the point here is... That once you get the knowledge yourself, you get the allies, you're teaching other people, you can start to drive change.

And you will drive change. First let's talk about bringing accessibility into your own work. First up, talk about it. Easy.

Be the person who talks about it everywhere. When I hang out with my friends, guess what they heard about? Uh-huh. That's right.

Accessibility. I have a few friends in this crowd, actually, who are falling victim. Just kidding. Not victim.

But really, though, it is something I'm just always talking about. I know a lot of people in this crowd are actually always talking about accessibility. That's a champion of change. You're influencing others, just by normalizing it.

By making it something at every table, every party, every grocery line. Okay. You can... You don't need to do grocery line chats.

Next, make good decisions. Make good decisions. Like who you talk to. And who you don't talk to in the grocery store.

It doesn't need to be a chatty spot. But making good decisions is so important. Just like small ones. What colors did we use in this PowerPoint?

What colors did we use? There was something when I had something in there and Asha called me in -- thank you, Asha. Hey, I think this one is not meeting contrast ratio. And I fixed it right away.

Thank you. Just small decisions. Small decisions add up. Just like not brushing your teeth for a few days in a row.

One day may be fine. A few days later... It adds up. Make good decisions.

They all add up. Check your work. Check your work. Run that PowerPoint checker before you send it off.

Make sure you test your alt text when the plane lands. And make it a part of your goals. Bring it into your own responsibility, and make the personal commitment to it. Let's see what we have to think about for engineers.

Asha? Sure, Kai. Thank you. I'll take your strategy forward for engineers.

Bringing a11y to the work... I think following small steps consistently in our day-to-day activities, you know... It makes a difference for a million users. Without slowing us down as an engineer.

If we do it in our STLC process and not as an afterthought. Linters are the big ones, which I would say -- start it with and make sure you're putting precommit hooks. And by adding linters, you can save 20% to 40% of accessibility bugs going into production. And obviously the automation stuff as well.

Okay. I remember we had Skasha, who was struggling with the div tag, and this is of course Skasha making sure you're writing semantic code. If you're writing semantic code, half of your problem is solved. Make sure while developing it.

Not like an afterthought. Engineers, while doing your testing, unit testing, you can use any kind of screen reader. With different browsers. You don't need to be worried about one particular screen reader.

QA will take care of that. But engineers, make sure you're validating at least one round with your unit testing. Right? And I would suggest... While doing unit testing, make sure you use the keyboard.

Not mouse. No mouse. Put it aside. You can get a lot of functional accessibility issues caught early in the game.

Start writing accessibility unit test cases. No one can break your code. You know? Embed it in.

It doesn't take much time if you get it done while you're writing in functional test cases. You are deciding on your external libraries. You have a feature to be developed. You've got like a chart component.

It will take time to make it custom. You go ahead and browse it on the website and figure it out, which one is good. You check whether it's meeting your requirements or not. You know?

Also check whether that component is accessible or not. And... Plus validate whether they are continuously supporting that library or not. These are the few tips which I would like to share here.

From the engineering side. Thinking about... Before releasing it to production. And I already answered this question.

But I would like to ask you again if you were focusing on the first slide: What percentage of issues can accessibility linters catch with the precommit hook and the good accessibility linter? Anyone from the audience? You want to give the mic? Pass the mic?

Sorry. 2? 2, 20% to 40%? Yes.

20% to 40%, for sure, we can catch it. If we're using it correctly. By embedding precommit hooks. That's pretty much from my side on.

You know. Accessibility beyond your team. Kai? Nice job, nice job, Asha.

I guess we should have done a poll, since everybody in this crowd likes polls more than quizzes. Let's really scale it up. Let's bring things to the next level. Let's talk about ways to scale accessibility beyond just yourself.

First is good communication and advocacy. One of my main things is: Don't just tell people what to do. Tell them why and how. Don't just tell people what to do.

Tell them why and how. Create a teams channel. Be the person who allows other people to communicate together with other people too. Make it a safe space to talk about it and learn about it.

Collaborate with partners. And partner with groups and allies. This one is extremely powerful. As you are going around, building relationships, you are finding allies.

You're giving trainings. And it's those people who come up to you afterwards who say: Thank you so much. That really impacted me. Because of X, Y, Z. Remember those people.

Because they are your superpowers. And you can amplify your impact through your allies. One time, I actually had that happen to me. Where somebody came up at the end and said that exact thing.

Thank you so much. This meant a lot to me. Because of X, Y, and Z. And I didn't hear from them for maybe six months or so.

I come to find out... They went back to their team and got right to work. They changed accessibility from being an afterthought to being a mandate for their team. Now going forward, all of the learning and development that all employees get are accessible.

The team test it with a screen reader and they test it with a keyboard. They make sure it's color contrast up to par, and accessibility is a part of their team culture. The point is here: Is that those small relationships, once you start to see the ripple effect, now you're really influencing change. The most influencing happens when you're not looking.

Oh yeah. Give detailed feedback. The good old feedback. That's like... Your app stinks!

No. No, no, no. We can't do anything with that kind of feedback. Give detailed feedback.

For example... You would say: Hey. This button here, X, Y, Z, on this page... Isn't doing what it needs to, for me.

Right? There's very specific feedback. Now that's easy for somebody to go and take action on and fix. So just in general, be detailed about that.

And use metrics and tell stories. Metrics are important for tracking progress. But storytelling drives action. And of course... Celebrate wins.

Be loud about accessibility and pull up an extra chair if you need to, for accessibility to have a spot at the table. Make sure you're giving kudos out to people who are doing a great job. I know there are several people here from the Teladoc team. We have Gina, Jared, Marissa, and other champions of change who have come across and helped accessibility grow and build and we have John Armstrong in the back as well!

Woo! Thank you so much. And this is so important to celebrate wins. Shout out to all of you who have made such a difference in accessibility at our company and also to all of you for coming here today.

Just in general. Now you are here. This shows you are ready to go make change and don't forget to celebrate wins. How about engineers?

Asha, can we scale a little for the engineers? Mm-hm. Scale accessibility beyond my team? Yes.

Make it part of your company's DNA. And empower every department to contribute. That's what I would say. But... From a technology perspective, start embedding your tools in the CI/CD pipeline.

That helps a lot. That just blocks. You can't go to production. You have to fix it.

You know? Make sure whoever has broken it -- we used to do it in my earlier company. Whosoever breaks the bill used to get a fine and we used to have a snacks party after a month. So make sure you break it, get a fine, and then enjoy it every month.

And add accessibility in your definition of doneness. And acceptance criteria. That helps a lot. So that people are... Set expectations so people are not just guessing what needs to be done there.

Right? People guess a lot. Oh, that's how it should be working. With screen reader, with keyboard, without tab, with tab, with arrow keys -- make sure it's mentioned in the definition of doneness.

Create documentation and checklists and make them role-based and specific to your user tech stack. This is a good one, and it's working -- this is literally... I love this. Adding the checklist in the PR, the pull request reviews...

It is working like anything. Even if you have a PR review, who is not familiar with accessibility, that person is also looking into it and validating the functional PRs and the actual code reviews. By following those check lists, which are mentioned -- that checklist is not that big. It's just validated with a screen reader.

Okay, you have a recording. Just make sure you have keyboard focused elements. You know? You have all the embedded tools in there, which you automatically get -- break the build.

So PR reviewer doesn't need to worry about those specific errors. But the ones which we directly cannot validate via automation -- those are the things we need to make sure we are validating in code review. +++ Build the guardrails to ensure the a11y best practices. At times, there are few places where I cannot embed my tool.

For example, the content management system. Right? I'm uploading an image. It's getting uploaded and pushed to production.

No one thought of adding alternate text. Make sure you as an engineer can just go and add a required text field, which is going to be an alternate text field, which is a required one for that image. And no one can pass that flow without adding an alt image. Whether that can be a decorative image or an image with an alternate text.

So engineers can think about it, and start implementing it. It doesn't take much time. Right? Lead by example.

Bring engineers and accessibility discussions, which we definitely do with product designers. Content editors. And one of the conversations -- there was an acronym mentioned by the content review team. We were asking: Can we make it a full content here?

Instead of just adding an acronym? And we can add it in brackets. So that people who cannot understand this or at times the screen reader doesn't read these acronyms -- better. It would be helpful for us.

So the content editor agreed. Engineer said -- yeah. This was a good one for me, to implement it. Product designer, product owner, everyone was there.

And we agreed upon it. Fixed it. Early in the game. Before even starting the development.

Work one on one with engineers. At times, people join accessibility meetings. But... The beginners, at times, feel like I might be asking a silly question.

There is no silly question. Go ahead. Ask them. At times, they are... They hesitate to ask it.

So I would suggest: Make a good relation with your engineers. And make sure they are coming to you. And pinging you in private. And just chatting with you.

And give that comfort, you know, to your team. Or beyond your team. That's what I would like to say. And we can also plan a bugathon.

While the company is fixing all the functional issues. Let's see how many accessibility issues we have. We can bring it in a bugathon. So lead by example.

That's what comes to my mind. But there can be more than that.

Awesome. Thanks, Asha. This is Kai speaking. Thank you so much.

I love those. Oh my goodness. We are in for some fun here. We've come to my favorite part here.

Keep in mind that a lot of people might just instantly push back when you talk about accessibility. There is just a lot of times a big knowledge gap, so you have to make it safe to learn about for people. And at times, you might find yourself repeating yourself a lot. Get comfortable with that.

But by responding calmly, by helping people to reframe how they're thinking of it, it will make it a lot easier for them to do the right thing. So here are a few one liners that we like to keep in our back pocket. Asha, let's get started with the engineering ones first. Sure, Kai.

Technical one liners, which I generally have to repeat.

No ARIA is better than bad ARIA. Right? It's not just about ARIA. It's about all accessibility properties you're using while you are developing.

Don't use it if you don't know how to use it. It's better -- know.

First understand it. What's the right way of using it? We can't use the ARIA label everywhere, where I have a button mentioning the very well explained content. Right?

I don't need to use an ARIA label. I can just get rid of it. Remove it. No tabindex is better than wrong tabindex.

At times, people are putting tabindex wherever the focus element is required. Not needed. It will get done automatically. Remove it wherever it's not needed.

So if we follow these things, we can solve so many things while we're developing. Use responsive design to support zooming and text resizing. I know people have started thinking a long time back about mobile first designs. I support accessibility first designs.

And think about that while you are getting the designs from your designers. Think about whether it's just mobile first or it's accessibility first. Okay. This one is my favorite.

You're building a feature. You've got one accessibility bug. Make sure you are not moving it to tech debt. If you move it to tech debt, after one year, you are building one more team with a good amount of people.

Resolving those costs. Reduce that cost while you are building the feature. It's so fast to make your feature accessible than fixing it after one year by some other team. So that's my favorite one.

And obviously everyone knows: Semantic code is accessible code. That's my favorite one. Which, if we follow that, while writing the code, we can do... Like a big shot here.

Over to you, Kai. Nice, nice. Okay! Woo-woo!

Who is ready for some general one liners here? Thank you, Asha. I love those. We're going to go quick on these.

I know we're short on time. I want to give everyone time for Q and A. But these ones are my favorite ones that I actually copy and paste. I use these so often.

Accessible design is good design. This one -- you can even flip it like a pancake and say it the other way around. Good design is accessible design. Accessibility is usability and compliance.

I like this one so much I could kiss it.

How can we make this more inclusive? I love that one. That's such a good question. I love to ask that one.

How would someone who is blind use your product? Oh my gosh. This one gets the people going. Ask that to everyone.

If you have a product person in your vicinity, ask them this question. Accessibility is everyone's job.

Remember... Change happens when people make it happen. You don't need a title to create change. You don't need authority to get started.

What you need is passion. Persistence. And a willingness to invest in what matters. And while the journey might sometimes feel uphill, know that every small action, every small change, contributes to a larger wave of change.

Today we hope that you learned something. But more importantly, we hope that you believe in yourself.

To challenge the status quo and bring others along the way.

Speaking of others... I think it's time for us to check in on Sky and Skasha.

So... Thank you. You heard our SNL. And now it's time for your SNL.

Start now. Lead! Thank you.

Awesome talk. Thank you very much. Stay up. Because we've got Q and A. We've got Q and A.

That's right.

That's right. Cool. So we've got about... I would say five minutes.

For Q and A. So I'll kind of start in the room and I'll take some from online and we'll go back and forth. We'll try to get as many in as we can. In about five minutes.

Any in the room to start? If not, I'll take... Okay. I see one.

Hang on. What do you think about the wave tool? I used that in my last job. It's like a Chrome extension.

Thank you for the question.

This is Kai speaking. The question is about the wave tool. If we like it, or just general feedback? I like the wave tool.

I also really like the aXe tool. You want to add anything on? Rather than wave, I like the aXe tool. You get more things over in aXe rather than wave.

And this is Kai speaking again. I also love to double dip. I'm a double dipper. I'll do both tools.

As an engineer, I prefer one tool.

So following on that one... Are there suggested specific tools for developers? Which linters? Sample PR templates with a short checklist?

With links to easy examples? Any kind of templates or repositories that you like? That are your go-tos? Yes.

ESLint jsx-a11y plugin is the best thing I've seen. One from Deque as well, accessibility aXe linter that's also good. These are the ones I have used. They bring you into the game and you can catch as many issues as you can.

But specific to your code, that's what I mentioned. Writing more accessibility unit test cases you can get in. But if you want to try out -- we had Evinced as well, you know, started this journey. They are also bringing up very good tools here.

Another one in the room? Yeah.

Thank you so much. That was fun. Thank you. I have a question about the actual workflow.

So you said that... Let's say you start with semantics. Right? Then you go into aXe tool.

Like a developer tool. To go through that. And then you go into like a screen reader? Or you do a screen reader first?

What would be the -- First is for writing your code. Making sure you have... Linters added. So that small linting issues can be caught early in the game.

And then you are making sure you have at the same time in your package.json, you have aXe code as well embedded. So that aXe is actually checking your DOM. Document object model. On top of your HTML structure.

Whether anything broke or not. Which the linter cannot catch. So that's why we need another tool to check the DOM. AXe-code?

Is that paid or free? That's the free version. Because I know the developer's tools... Because we actually had an aXe guy here last time.

And so... It's a free tool? But then if you want more... You have to pay for that.

So that's why I'm... So that's why we have embedded aXe into our... This end to end test cases. So we are catching earlier in the game before it even goes to production.

And then you go ahead -- manual testing. Make sure with the screen reader. And if you pay for aXe, you can automatically get your thing done with keyboard navigation. Those are paid.

With aXe. Thanks. Another one from online. How do you help move organizations past the mindset of: We want to get this in people's hands quickly, so we'll just do accessibility later?

This is Kai speaking. And the question is: How to get organizations past... Just thinking you need to ship out products fast. That's a reasonable question.

And a reasonable circumstance to be in, in business. You want to get products out. You also want products to be high quality. I tend to try to push accessibility, and go by the mindset of: Accessibility is a part of quality.

And it is. If one person can't use it, because of XYZ reason, it's going to be a lot of people. And therefore then you have a quality issue. So I think helping to reframe it as... This is a part of quality.

And helping guide the teams who are across the whole software development life cycle, the SDLC, to understand the importance of accessibility and the tools that they can use to make it easier to get it done the first time around. And not as tech debt. And the other thing is... Tech debt really sucks.

And policies. And policies. You can put policies in place and checklists and use different tools. So it's definitely a process.

It's not just something that overnight you're like... Hey. Great idea. Let's all get in on this.

It takes time. But... Keep going. Keep pushing.

And keep in mind it is worth it. And also prioritizing... Making sure you are building a feature. You know.

Make sure... At least your blocker and high priority bugs are not there in production. At least if you can fix those while developing the feature. And we have policies in place.

So everyone is following that. Cool. I think we've got one minute left. So probably one more in-room.

Yep.

Thank you very much. When I heard Saturday Night Live, I was expecting more cowbell.

You were talking about -- workshops I guess is the best way to do it. Into the onboarding process. And you start with the general one and go into more detailed one. What would you put in the general workshop as opposed to the technical workshop?

I know I can talk about ARIA all the time, but the next salesperson or accounting or whoever is not going to care about that stuff. So... What would you put in those two buckets? That's why I mentioned about tailored training.

Kai takes product owner, product design, and I take specific product engineer. We divide it in between. And we have one for QA-specific trainings for new hires. So we have tailored it out.

I was specifically asking about the one before that. So you have the general onboarding and talk about accessibility. What it is, how you should do it, like that? Yes.

General... You want to say it? Oh, no. Sorry.

Go ahead. I love that question. And thank you for asking that. I love that you love to talk about ARIA.

I want to bring you around with me everywhere. Yeah! Great. Let's get drinks out there.

So... The answer is... Yeah. Just basic... This is what accessibility is.

I was surprised how many people... Not in my current job now, but just in general, when I first started really giving trainings in the general space, how many people showed up thinking I was talking about access to databases. And I'm like... Whoa.

Let's first define it. Let's get everyone on the same page here. Let's all use the same language. I like to talk about disability types, disability etiquette.

The inclusive language. And just general introduction to the processes that accessibility adds. Yeah. Making sure they know about like... As a company, what policy you follow.

You follow... Level A, level AA, level AAA -- they might not be knowing about those terms. But just make sure in their mind so that when they start going into their teams, they understand what level they should be following. Especially engineers.

Right? And designers, obviously. And QAs. [VIDEO PLAYS] What an event!

A11y is my middle name now. Don't we build it right the first time, every time? Let's agree. Native elements first, custom buttons to be implemented only if we know how to make it accessible.

I agree. Also, I promise to use an accessibility checklist before finalizing mockups. I'll even get accessibility acceptance criteria added to every story. Skosha, let's get that button fixed ASAP.

Oh, yes. I fixed it, that bad boy, on my way home. I tested it with keyboard, axe tool, and screen reader as well. QA passed it, and it's released to production, Skye.

Inaccessible is unacceptable. It's up to us to do the right thing. That's right. That's the spirit, Skosha.

I'm so glad we did the right thing, and now we're going to do it every time for everyone. Oh my gosh, you're not going to believe it. What? I just got an email from the end user.

They said, hey. Thanks for finally making that button that I can actually press. I love this feature. Wow.

Wow. Wow. Thank you. Thank you.

[VIDEO ENDS]