Prioritizing Accessibility in Software Dev

[00:00:00]
>> Okay, so how do MVPs or minimum viable products apply to accessibility, especially if you are in a waterfall system? There is this well-known concept in agile software development of the minimum viable product, or MVP. And the idea is to produce iterations of a product that meet a customer need every step of the way.

[00:00:21]
As opposed to trying to get it all in, in this mammoth giant build that takes forever and goes over budget, we wanna increment. We wanna get to sort of a picture this graphic on the screen, where it's instead of single wheels in the goal of building a car, we go from a skateboard to a scooter to a bike to a motorcycle to a car.

[00:00:45]
So it has less features, and maybe it works slightly differently, but if we can ship something that works to accomplish at least part of a customer need, then we can build on that. And so, for accessibility, I like that metaphor because sometimes that's what we need to do.

[00:01:02]
We can't just go and rip everything out and ship the perfect component fix, sometimes you can. Sometimes I can't even touch that part of the code if it's not part of the ticket that I'm working on, I work in a pretty restrictive environment like that. So we have to find ways that we can ship things on time that are still accessible.

[00:01:24]
The unfortunate reality is that a lot of early phase product launches don't include accessibility. I mean, it's the easiest way to get people coming with torches to yell at you on Twitter if you launch something that doesn't have accessibility in it, it's not great. And it's because people are so frustrated about this, they're like, why can't we think about accessibility earlier?

[00:01:49]
We hear things like, it's an alpha version, don't worry about it, we're just getting started, we'll ship it later. I mean, they're doing their best, I understand, but I think we can do better than that. And so, part of my goal as I've matured and learned, is when you point that stuff out, be kind about it, the pitchforks and torches are probably a bad idea.

[00:02:12]
Cuz we want people to learn about it, we wanna be like, hey, this is great, I really like how you did this part. I wish it had accessibility included in the beginning because it would be just more successful that way. I think the challenge is that, we do that over and over, and it just is continually forgotten.

[00:02:32]
So if you're building an early stage product, be a hero and a champion [LAUGH] by including accessibility early, because you can incorporate it into the DNA of the product. You could potentially handle use cases that would be really hard to add after the fact. And so, you do this by incorporating accessibility in planning, in design, not just like, dang, we caught it in QA, now we have to go and try and jam changes back into earlier parts of the software development life cycle.

[00:03:04]
So there's a quote in the article by Henrik Nyberg who wrote or created that original MVP graphic. He had the idea of, what's the cheapest and fastest way that we can make something usable? And I kind of took a spin on that and thought what's the cheapest and fastest way we can make something usable and accessible?

[00:03:23]
Note, I have to do a big caution. I am not talking about adding an overlay, which is a one line of code fix that claims to make your site accessible, that is not what we're talking about here. Cuz that's, yeah, outside of the scope of this talk. But I think if we can create iterations and phases where we kind of ship something that's solid, but just does fewer things and then we build on that.

[00:03:52]
The next version of this will be more interactive or we'll have one widget that can do more functions instead of having a toggle between two different views or something like that. Technical debt applies to accessibility big time, and it's why it becomes so costly to do it later.

[00:04:11]
And parts of MVPs, some of those live on in design decisions and code, those early prototypes, the work in progress. How many times do you see WIP commits and code that live on forever and all kinds of projects. So those decisions, I've actually heard them described as layers of sediment, which I thought was really interesting.

[00:04:34]
Yeah, kind of a nature theme to think about, or tree rings, or something, and it's like these decisions live on. And so, if we make decisions early on about how we architect our frontend code, in particular, we can make it easier for ourselves. Cuz it is hard to recover from this debt without significant re-imagining, re-platforming, and essentially starting over.

[00:04:58]
So just do less, if you can't make it accessible, do less. Add a widget that people can toggle between, if you have a really fancy table that you can sort, but it only works for mouse users, provide an alternative format that's easy to get to, that's pleasant to all users.

[00:05:17]
We don't wanna ship people off to text-only, boring, non-maintained sites, but it is okay to have lower five versions, especially early on, that then you go and iterate on and improve. Make it part of your culture, make it an accountability culture that's friendly, not cutthroat. [LAUGH] But I think the culture piece is what's missing a lot of the time.

[00:05:42]
So, how do we do this? In the software development lifecycle, as I was saying, we wanna tackle it earlier than catching it in QA. So, we wanna consider accessibility earlier, what we call shifting left, cuz we wanna consider it and planning, design, engineering, content strategy. Basically any time that decisions are being made about what users are going to see and experience, if we can plan ahead of time, we could prevent some re-work, some cycles of the feedback loop of, does it work?

[00:06:15]
And we test it, goes to QA, we feel like start over, just that loop, you can cut that down. It gets really hard when some of the things you have to change are really core to the product like brand colors. If you can't make colors past visual contrast ratios without changing it so much that your orange looks brown, you just can't fiddle, you can't tweak those colors enough to make that work.

[00:06:41]
You have to go back to your design team and your brand people, and try to come up with a solution that can be hard with T-Mobile pink, or some color like that, pink and white, the pink can't get any pinker, that's it. Or if your whole app is built in HTML5 Canvas, that's kind of hard to change and very hard to make accessible.

[00:07:07]
There were some claims that you could do that, but it's just not the same. I'm a Figma, that's what they're dealing with. That's a Canvas-based application that is very hard to go in and change. They're working on it, bless them. They're awesome, but that's hard. And so, we'll have the most success when we consider it earlier.

[00:07:29]
All right, we're doing this in Canvas, should we? What are we gonna do to make this accessible? That's a tough thing to overcome later on. So what kinds of things need to be addressed in design? I mean, contrast, colors, that was one. I mean, you could be assigned a drag-and-drop widget that to make it accessible, we're going to work on one later.

[00:07:53]
And I happen to know from working on those that sometimes you have to change the design to make it work. And design might have already been signed-off on months ago, depending on how your process works, it could be a totally different company that made that, so that can be hard.

[00:08:12]
So, yeah, some things like, you can only finesse it so much as a dev, you have to understand that you might need to open up some design cycles to really get it right. And so, yeah, just keep that in your mind, in the back of your mind when you're doing sprint planning, you're thinking about how is this work gonna get done, yeah, know that you might need some design help.

[00:08:38]
And so, we had some kind of questions, thoughts around how to convince stakeholders, because it's the stuff people don't always wanna do. There is a bit of an art to this, and depending on what motivates people, that's part of what makes it an art, is like finding out what matters to people.

[00:08:56]
Some people might respond to a carrot, some people might respond better to a stick. And so, those approaches, it's kind of exhausting having to think about that. But if we wanna get this work done right, sometimes we have to think about this. So what do people care about?

[00:09:10]
Legal risk and compliance, maybe, lost revenue, possibly, brand reputation, that could be a big one. So my strategy is to tackle these tasks and phases, find easy wins, find things you've already done, and you can say, hey, look, we did this and you didn't even notice. Think about, if we put a little bit more emphasis here, how much more we could get done?

[00:09:34]
And here are some prioritized issues at least a quick pass at that to think about how much work we need to do, make it easy for them to say yes. So that's what I would do anyway, especially as a tech lead. And when you combine that with kind of the MVP approach of having something that you can do in phases, something that works every step of the way.

[00:09:59]
Or at least, you're gonna tackle it the next sprint, and you have it scheduled, it's not just gonna languish in the backlog, that's how you can chip away at it. But I think the reality is, accessibility often is fixed long after something is launched, cuz people go, dang, I didn't know [LAUGH].

[00:10:19]
So sometimes that's what you'll be dealing with and it's kind of the same process though, you still have to break it down into parts. You still have to schedule it, figure out what the scope and estimates are, all that. So to help you prioritize some heuristics that I would think about for prioritization include, what's the accessibility impact of issues.

[00:10:39]
You can find all kinds of little tweaky issues, but some of them might be WCAG AAA and, or maybe they're kind of your personal bias or your personal thought of how something should work. Really consider how blocking is this? Can someone complete this if they really can't use a mouse and their focus dial is lost, are they going to be lost?

[00:11:01]
Yeah, probably, that happens to be, I think, a level A criterion in WCAG. So, yeah, what's the impact? If there is a WCAG criterion for web content accessibility guidelines, there's three levels, level A, AA, AAA. Level A is absolutely yes, you must meet it. AA is also absolutely yes, usually.

[00:11:23]
AAA is, well, if you can meet that great, but usually AA is what we're aiming for. So that can help you kind of gauge how that works and test with users too, if you think someone is blocking, if you can have someone test it, who knows, that's really great input also.

[00:11:43]
Analytics and metrics, so we can't track screen reader users for privacy reasons, but we do have traffic metrics that we can see usually, are these core user flows that these are on? How much traffic talking about here cuz that could be really impactful? If people can't check out, they can't buy a mortgage or whatever, that's a problem, you're gonna lose a sale, you're gonna lose some business, that is what Target got sued for, their checkout button was not accessible.

[00:12:15]
And so, they've changed their culture now as a result, which is really cool. But which browsers and platforms? Are there any areas that need more help? I was saying, do you need more design help? And then the cost of not doing it, I'm not an MBA, but I could probably break it down into coming up with some scary estimate.

[00:12:36]
[LAUGH] Or sorry, not scary, a helpful estimate of the cost of not doing it, that's what you could make scary. Like, hey, if we do this, these are the benefits, if we don't do this, here's the scary estimate. But we'll talk a lot more about organizational skill building a little bit later.

[00:12:55]
So accessibility personas, especially in the design phase planning, thinking about who our users are. This is one of the earliest times that people with disabilities are marginalized out of the process. And there's no thought or care into how someone would use a screen reader or use a keyboard.

[00:13:14]
And so, sometimes that can be part of your planning phase, your design phase, to think about, how is this gonna work? What would our customer be doing, if we're a bank? Yeah, blind people have bank accounts. Blind people do all kinds of things. So including your customers in accessibility personas can be helpful.

[00:13:34]
And while personas are not real people, they do represent your users, people using your product, buying your services. So I have some examples, because there is a lot of really great expertise that's been shared over the last couple of decades. There's some from the UK Government Digital Service, from Stanford, book called A Web for Everyone that weaves personas throughout, that's really great.

[00:14:01]
I found these personas on the Figma community, part of the Figma as well. And I have the cover of that on the slide, but there's a whole series of personas in there. So you could see kind of how do people approach that, I think we can benefit from the wisdom that's been shared by people in the Accessibility community.

[00:14:22]
So you can share that with your design partners and colleagues.