Enterprise Web App Accessibility (feat. React)

Prioritizing Accessibility & Discussion

Marcy Sutton Todd

Marcy Sutton Todd

Principle Studios
Enterprise Web App Accessibility (feat. React)

Check out a free preview of the full Enterprise Web App Accessibility (feat. React) course

The "Prioritizing Accessibility & Discussion" Lesson is part of the full, Enterprise Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy discusses the importance of making accessibility a requirement and part of the regular workflow. They emphasize the need to include accessibility in tickets, stories, and issues, and to ensure that team members in various roles are on board. The instructor also suggests ways to make accessibility a reality, such as building it into automated tests, performance reviews, and interviews.


Transcript from the "Prioritizing Accessibility & Discussion" Lesson

>> So how are we gonna do this? We're gonna make it part of the requirements, make it part of your definition of done. So how do you ensure accessibility isn't skipped or missed? You make it part of your culture, so include it in ticket stories or issues kind of hovered terminology you use, make sure that team members in various roles are on board, like PMs, design, development, QA.

We wanna include it as acceptance criteria so we could surface it at a good time before something has shipped. And if you have to learn the hard way about getting an audit at the 11th hour and having to go back and fix it, that's a good learning opportunity [LAUGH].

Hopefully, you can fix stuff a little bit earlier next time. Hard earned experience, that's for sure. Because it is way more costly to fix after the fact. Question.
>> I had a quick question. I don't know how feasible this is, but I guess this is a slightly unethical tip.

Is there anything you can do to get your company under fire to make them at [LAUGH] more of a risk of getting out of it.
>> I like the way you're thinking here. No, probably not a great idea. I mean, we're all in that boat together. So, I mean, yeah, I'm not sure, I haven't ever really tried that.

It's like-
>> Yeah, good
>> Good here.
>> [LAUGH]
>> [LAUGH] Yeah, I'm not sure. I think pushing for some user testing to gain insight into the areas that are not working well. It's kind of that internal motivation instead of the external motivation. But do what you gotta do.

[LAUGH] Just don't tell anyone I told you to do that. [LAUGH] So we wanna make accessibility an actual requirement. And kind of funny story is I worked on projects where accessibility, like WCAG 2.1 AA or 2.2 AA, will be listed in a document somewhere, like we're aiming to meet it, but then there's literally no process to actually do it.

Kind of a smell. It's a process smell. So it's one thing to list it as a requirement. It's another to actually uphold it throughout the process. So we wanna actually uphold it throughout [LAUGH] the process. So that we are true to our word that it is a requirement.

I think people are just released with it actually being part of the regular workflow. But there are so many things that I've shared with you today and in the web app accessibility workshop that there have to be some levers you could pull. I've told you everything I know about accessibility, probably more than I even wanted to share with you.

So there are definitely some ways that we can make accessibility a reality. It takes a will to do it. You have to kind of be brave and go swim against the grain or swim upstream a little bit sometimes to be, be like, no, really, we have to change this process.

So make it repeatable. Find ways to remind people in a diplomatic way. Build it into your automated tests. Get those working, get those passing. Build it into performance reviews. How's that for an idea. Like that get blame thing, as a manager, looking in terms of what performance looks like, what if accessibility was a category?

I haven't heard of anyone doing that. It may be for accessibility teams. But I think if you have some hotshot developer who always ships inaccessible code, maybe that should make them less hotshot. Maybe that's not helpful. So let's gauge performance factor quality and accessibility into performance and interviews, because we can ask people about this in interviews on both sides of the table.

So yeah, let's ask about it, see if it's in their process or not. How does this factor into performance and metrics? Now we're talking.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now