Software Accessibility

Dan:
Yeah. [inaudible 00:00:29].

Tobi:
Yeah, I love that intro. That was super cool.

Dan:
Dave [inaudible 00:00:34] at his finest. At his finest. We won’t praise him too much because he’ll be mad about that later. Tobi, as a real estate mogul, are you in a new house today?

Tobi:
No, I mean, I [inaudible 00:00:47] today. Great place. So many birds outside. It’s 80 degrees. Yeah, I love it.

Dan:
Wonderful. All right. Welcome to Labs Live. I’m Dan. I’m joined as always by Tobi. This is our monthly live stream where we talk to some great guests about technology, design, software to development, a little bit of everything. And before we jump in, some house cleaning stuff. Make sure you go and follow us on LinkedIn. Subscribe on YouTube. I always get those confused, which one’s which, but keep up with our content.

Tobi:
If we just have a consistent thing for all of it.

Dan:
It would be nice, wouldn’t it? But either way, follow us. We got some great content that we put out there, and both live streams every month and some recorded content. So see us there. All right. Let’s dive in Tobi. Today we’re talking about accessibility, specifically though, around software and product development, and we are joined by three guests. And I have to say these guests have also graciously offered to answer questions. So if you are watching, if you’re tuning in, and you want to jump into those comments and ask questions of our guests, they are incredibly knowledgeable in this space and are happy to help. Should we get going Tobi?

Tobi:
Yeah, let’s get going.

Dan:
All right. I’m going to introduce our three guests rather quickly here. Katrina Olamaker, welcome QE. And then we’ve got Kitty Garrison. Welcome QE as well. And Derek Quinn, iOS developer, but an aspiring developer of all things, maybe, is the way to say it. So welcome everybody. Thank you so much for joining us today. I think accessibility is a really great topic that likely doesn’t get as much conversation. So I think it’s great to give a lot of information to our viewers here today. So let’s level set real quick. I’m going to kick over to you Katrina first. What is accessibility, especially as it relates to software?

Katrina:
That’s a really good question because it’s a word that we throw all the time, but what does it necessarily mean? Accessibility, especially when it comes to software, is tools and features that allow people, any people, particularly people with a disability, to use an app or a site more easily. So making an app accessible means that we are accounting for the needs of as many users as possible.

Katrina:
So it sounds like that’s a lot of work to figure out because there are all kinds of people in the world, but a lot of the heavy lifting has been done for us. The web content accessibility guidelines, or WCAG for short, list design and development standards that you can use to make your app or site accessible.

Dan:
Awesome. So it sounds like there’s guides out there, which is really great. And it sounds like there’s some best practices. I want to ask what seemingly is an obvious question here, but why do we want to make our sites accessible, our apps accessible?

Katrina:
I mean, first and foremost, it’s the right thing to do. Your user base includes people who need some kind of accommodation, even if it’s something as simple as just increasing the text size in your app. That’s an accessibility feature. Most people don’t think of something that small is being like, “Oh, this is a special feature that makes this more accessible.” But yeah, just bumping up your text size, that’s accessibility.

Dan:
And I think typically when we discuss accessibility, we often focus on what may be considered permanent disabilities. Blindness, deafness, loss of a limb. But is that all we should be focused on, or is there much, much more?

Katrina:
Those are important things to focus on, absolutely. But there are other conditions that might put you in a place where you need accessibility features. Like for instance, I’m getting a little older, it’s hard for me to read the manuals in Mac packaging because it’s gray on white. Color contrast is something that we need to consider for people who are getting older. We may need bigger texts. We may need larger buttons. Our lives change and our day-to-day circumstances change.

Katrina:
If I’m in a crowded place and I can’t hear the sound on a video, it’s great to have the captions there. That’s another accessibility feature. Or even something as simple as the vibration on your phone. When it vibrates for an alert, that’s an accessibility feature for somebody who is deaf or hard of hearing. But I never turned the sound down on my phone. That’s vital to the way I live my life.

Dan:
That’s a really great point. I think as you’re talking about this, I’m constantly questioning and asking myself how many times throughout the day am I using accessibility, or traditional accessibility features that just, you don’t even realize. I tried to watch Peaky Blinders once, and I don’t think I was able to make it through without the captions at the bottom.

Dan:
But all right. I want to talk about the laws that are surrounding this. Are there laws? I know we have ADA, Americans with Disabilities Act. Does that govern anything around software?

Katrina:
Honestly, it’s a little unclear right now. The ADA applies to public spaces and there are cases moving through the courts right now about whether or not websites and apps are considered public spaces. Sometimes they say they are, sometimes they aren’t. I think this has headed for the Supreme Court, and any decision that they make is going to have a big effect on the way we build and market apps and websites.

Tobi:
Yeah, I think it would be incredibly fascinating after the kind of year we’ve gone through, where online replaced a lot of physical things and people spend more time online. I can see how virtual spaces will begin to have the same expectations as physical spaces.

Katrina:
Absolutely. One grocery store chain was found in the courts that they needed to make their website accessible, because they had online only coupons. Something as simple as that can put you in a situation where you are in desperate need of accessibility features, fast.

Dan:
Yep. I like that, well, certainly it’s the right thing to do and that should motivate everybody at the end of the day. With laws coming around the corners, I think that’s additional motivation. Also, it might clear up what some of those best practices are, right? There’s obviously guidelines, and then matching that up with some legislation as it comes through will be a benefit to everybody.

Dan:
Now, I want to jump into the tactical piece of this. And I’m going to move over to Derek here. And Derek, what type of tools are out there to help us build accessible products?

Derek:
Well, there’s plenty of tools for the job. And on the iOS side, for example, we have all different kinds of APIs and frameworks that we can pull in, some of which are built into core frameworks like UI Kit and SwiftUI, that allow the developer to work with accessibility features in line with other features. In some cases you don’t even have to add external dependencies.

Derek:
On the Google Play side, there’s the same thing. Different names, same thing. And on the web, of course, there’s a slew of things available, tons of dynamic things that you can pull on for web projects as well.

Dan:
That’s awesome. Now, we went through some training this past year. Everybody in the organization, leaders, including myself, and one of the things that was most impactful, not only learning the spectrum of disabilities that might benefit from accessibility. Also learning that day-to-day, pretty much everyone benefits from accessibility. But also seeing it. I was able to see what an accessible site looked like and a non accessible site looked like. And for me, that was impactful. And I believe you have a nice little video to walk our audience through what … I’ll let you bring it up and explain it here. I don’t think I’ll do it justice.

Derek:
All right. All right. So what we have here is a personal project of mine that does not have respect for text scaling settings. So I’m going to go ahead and pull that up and I’ll take you through a couple of features that could be greatly improved by more accessibility. Let’s see here

Derek:
I’ve got a video. There it is. Okey-dokey. So this is a demo of an app that I built. So here we go. We have a typical user flow, and you’re going to see it without scaling settings now. A typical user signing up, pretty small text, even for me. So after the user flow is complete, you’re going to see what it looks like when I cranked the accessibility settings. Rather, the text scaling settings. And you can see here, we’re completing the flow. No problem at standard scale.

Derek:
But what happens when I go to my accessibility settings, which are right at the top. Really easy to get to. Cheers to Apple. We’re going to crank the larger text all the way up. And we’re going to go through that flow again. We have not only design problems, but functionality problems. The accept terms and conditions has bled into the continue button. There’s ellipses showing up when they shouldn’t. There’s plenty of things we could do to help this both from a design and functional perspective in terms of accessibility. Really, really a good example of what not to do here. So I’m going to go through, and I’m going to call some of those accessibility functions in the framework after this. I promise.

Derek:
And then we’ll see here just a stark difference. I paused the video. You can just see it’s borderline unusable when the scaling’s cranked. If there was just one more thing on the screen, it would be going off screen. Not to mention, you can see the date of birth and these buttons down here for accept terms and conditions and privacy policy didn’t scale at all. Because I didn’t tell the compiler that these things need to get bigger and smaller. And that’s an honest mistake that a lot of developers make, or maybe it’s an omission due to time. We’re in the middle of a sprint and there’s no accessibility cards. So we are just moving on without it. Not an example of best practices here.

Dan:
So it’s interesting because at the beginning of when you were talking, you were talking about Google and Apple have done a lot of really great stuff when it comes to having APIs for accessibility. But I think there’s probably a common misconception here that because Google and Apple have put a lot of effort, time and investment into this, that everything just works out of the box. And I think what you’re seeing here is supporting that misconception.

Derek:
Yeah, absolutely. So there’s some things that are happening automatically, like when I have, for example, in this SwiftUI up, I have a text field. And Apple knows to scale the text field. But when it gets a little more complex, like when I have a date picker, that’s on the developer. It’s the developer’s responsibility, it’s the product owner’s responsibility, et cetera, to make sure that these things are a priority, not just an option. It’s definitely on the developer, it’s not Apple and Google just magically waving a wand and making things happen.

Derek:
And you’ll see the app borderline crash on the next feature here. And this is an example where, because the developer, me, didn’t do anything, Apple can’t help me. You’ll see here, this is just a flow where I’m selecting a schedule, and it works fine, really small text, again. Probably [inaudible 00:12:40] buttons on the screen. But watch what happens when I scale the settings. It is not usable at all. Apple can’t help me here because I haven’t told them what I’m trying to do. Google can’t help me because I’m not telling them what to do. It’s on the developer, like you said. Good point.

Dan:
It sure seems like at the end of the day, you’re responsible for your own product. Apple and Google, obviously, provide tools and some frameworks, but unless you’re going to use them, then it doesn’t really matter.

Derek:
Totally.

Dan:
All right. So one of the things that’s coming to mind, and Tobi, you’re probably picking up a little bit of this too. This is certainly accessibility features, but it also just seems like good user experience. And so I want to kick it over to Kitty to talk about that, because it certainly seems like it is a much a broader process and more intentional that benefits everybody.

Kitty:
Yeah. I think that we really need to use empathy when we are building these features. Something that comes to mind is just the difficulty that someone can have clicking through an app. There’s folks with very limited mobility, maybe they suffered a stroke, and now they’re using a single click button to navigate an entire website. So each click can be very difficult to make. And as we were building apps at the very first beginning of the process, designing, we needed to design with as few clicks to finish a task as possible. And goes right back to usability for all users and good user experience.

Dan:
Yeah. It’s interesting you say that, because certainly while I’m designing for as few clicks as possible allow users to get through that flow simpler. It also seems to me that makes good business sense in general. So if you’re developing a product and you’re attempting to sell something, you don’t want 90 clicks or 90 taps in order to sell something. So I keep that designing and developing for accessibility just has benefits throughout the entire process here.

Dan:
So, let me ask you this. And this might even be short-sighted on my part. Is this something that should be part of the design process as well as development? Or are we talking much larger than that?

Kitty:
So, definitely when the conversation starts, we need to have all of our users in mind. And when we build what’s known in the industry as an MVP, a Minimal Viable Product, the first thing we get out the door, who is that for. We want to make sure that when we think of a product that’s going to be useful for our users, that we are including all users. And that starts with the conversation, it starts with the design sprint, and we need to keep those users in mind as we build every part of the app.

Kitty:
Derek, you mentioned accessibility cards in a sprint. And what we’ve tried to do in our teams is move away from accessibility cards. And as we build the feature that we are adding accessibility right in each feature card as a criteria.

Tobi:
So I was just going to mention that too, Derek, just from your experience incorporating it into the feature, could you feel free to chime in as well how much different is that development wise? If you were to redo this app that you showed us from scratch, how different is it from a developer’s perspective?

Derek:
It can vary greatly, but how different is it? I would say that it gives you a greater feeling of accomplishment, like you’re actually finishing the job when you do this. It’s one of those things where, yeah, it might take a little more work, but your product could be twice as good if twice as many people can use it properly. And not to mention, if you look back at some of those screens I showed you, if we were designing with accessibility in mind from the beginning, there’d be some human interface guidelines that we would also do better at obeying. Like having the buttons too close together isn’t really possible when you’re considering accessibility things on iOS. I had way too many buttons on one of those screens. That would not be possible if we took accessibility into consideration, for example.

Derek:
So I guess to answer your question, although it might be more difficult, I think it’s very, very worth it.

Tobi:
Katrina, I saw you, you un-muted, do you want to add something?

Katrina:
Oh, I was just thinking that in terms of implementation, yeah, when Kitty’s talking about the MVP and who that MVP is for, it’s for everyone. And we want to make sure that we are designing for everyone, because an app that doesn’t have accessibility features is incomplete, and Detroit Labs does not make incomplete apps.

Dan:
That’s fantastic. This reminded me a little bit about security. During our security episode, it was less about any one thing, or checklist, or something along those lines. It was more about a way of thinking. So even as I talked about, is this part of the design process as well as development? It sounds like this is part of the strategy and selling process. This is part of the planning process. This is much bigger, and it seems to be a mindset is what’s important, not a checklist.

Kitty:
Yeah. And you bring up mindset with Derek’s example of an app. I saw there was some radio buttons. And when the developers are developing a radio button, we have this implicit criteria that we know that what a radio button is. A radio button means you can select one choice and you can’t select the other. And we don’t necessarily need to write that into the criteria of the card. I imagine a future of that as we become more familiar and we get better at accessibility, that some of those details won’t need to be written into the card. We will know that the radio buttons need area labels, and we’ll know that the button that we’ve created can be used without a mouse on web. And this is a beautiful future that I imagine.

Derek:
I’m right there with you.

Dan:
Kitty, speaking of future, not to break the fourth wall here, but we have these conversations beforehand, and you were talking about a great story a friend of yours said, and it really stuck with us when we were talking about before we go live.

Kitty:
Yeah. She said, “Are we designing a future that is inclusive of ourselves?” As Katrina was talking about, when my vision starts to decline, is the app that we’re building going to have scalable texts that I’ll be able to read? It’s a very interesting idea, and a good way to promote empathy, is to have empathy for your future self.

Derek:
Absolutely. [crosstalk 00:20:19] It’s interesting how these discussions influenced me in that way. Just to prepare for this, I had the some accessibility settings on on my phone. I cranked the text scaling, for example, and I found that it actually helped me with screen fatigue. So it’s actually, for me, it’s not even my future self. Those features are already helping me.

Tobi:
That’s awesome.

Katrina:
Sometimes in the course of my testing, I use a screen reader to make sure that we’re using the appropriate component, because it will tell me what kind of component it is. So having a robust screen reader support is helpful in the development process as well. It’s amazing to what extent accessibility plays into our lives as users and as creators of software.

Dan:
Tobs, were you going to add something?

Tobi:
Yeah. I was just curious, as Kitty was sharing that story, it’s such a great point, just about designing for ourselves in the future. And then I just remember too, at labs, like Katrina and Kitty and Derek now have been on the forefront of helping us do things like training and educating us as a company. And I was just curious, how did you even pick up this interest? Because for a lot of people, it was like, “Oh, this [inaudible 00:21:40] is really cool.” But from interacting with Katrina and Kitty and Derek, you can tell that they don’t just want to make accessible apps themselves, they want to really amplify that the industry, which is why we’re doing this episode, more people actually care about this. So just curious, how did you get into this? How did you know about it? And you shared a little bit about empathy and all that. I was just curious about your story, how you stumbled upon this.

Kitty:
For me, it was, unfortunately, that I had to have knee surgery, and you guys saw me limping around the office with this big brace on and wearing crutches. And it was very eyeopening to experience the temporary disability and experience some of the physical boundaries that I wasn’t able to overcome just in our space. And that really struck a chord with me to think about how important, as we are working from home and doing a lot of things over the web, have very important things are inaccessible to some folks and how we are in a position to improve that.

Katrina:
Yeah. I have a loved one who needs the voice controls on his cell phone to operate it. And seeing how those work and how they could be made better, really inspired me to get into this work. And also just the technology industry in general has a little bit of an empathy problem. And I think the more that we focus on the obvious places for empathy, the more that it seeps into the other parts of our work, and it becomes a nicer, friendlier, more welcoming industry. So this is, again, for people in the industry, as well as for the users.

Dan:
That’s great. So you mentioned voiceover, I think Tobi, maybe I’ve told you this, but one of … Well, honestly, maybe it had been the only time I used the accessibility features. I think two years ago, I had LASIK and laid down in bed and had to keep my eyes closed for four hours. My wife was nice enough to put The Office on for me, because I think we all need a little bit of The Office in our lives. And unfortunately, I rolled over and hit the controller, and so it was off whatever the area I needed to hit another episode. And I was able to turn on voiceover just by asking through the Apple TV, remote through Siri, and all of a sudden voiceover was on and it was very easy to use.

Dan:
So it’s incredible the thoughtfulness that has taken place inside of these devices. And it’s definitely on the creator’s responsibility to make sure to integrate with those. The tools are there, it’s on us, the creators, to integrate. So I want to jump back over to Katrina here. I want to talk about what makes us qualified to talk about this. I think we’ve alluded to it and maybe foreshadowed it a little bit throughout this conversation, but what gives us the ability to come on here and have a live stream and talk about this?

Katrina:
Yeah. Well, we’ve been working with clients on this for a while, so we know what users need and how to implement it. But the QA team saw that we needed to take it a step further and formalize our knowledge rather than the ad hoc, informal tribal knowledge we had gathered. So everyone who was employed by Detroit Labs’ services unit in 2020 took training courses in accessibility concepts, implementing accessibility features in webpages, or they took courses in both, depending on their roles.

Katrina:
We thought it was really important, because like I said before, an app without robust accessibility is incomplete and we are not in the business of making incomplete apps. So we can make informed recommendations about what accessibility features make sense for whatever app or webpage we’re building. And that expands the audience of the product that we build. And it helps people retain their audience as those people’s lives and circumstances change. So that training has made a big difference in the way we think about the work that we do, how we approach design development, testing every aspect of our work.

Tobi:
So watching this now, let’s say I’m a business or I’m somebody who is now open to this and we already have an app in the app store, a website that is not accessible. What is the next step to do this?

Derek:
I’d love to jump in on that. So I think it’s just like adding any other feature, except it’s a very special feature for me. For example, we could add push notifications to an app that doesn’t have it. We can add animations for better user engagement. We can add HD video playback instead of 720. But for adding accessibility, it’s a matter of, you can put anything you want in a pull request, and I think it would be a mighty fine thing to do for an app that’s already out there. And of course it’s totally doable. It’s no different than adding any other feature. But I think with this feature, you’re almost guaranteed to get more users, which is quite nice.

Dan:
So I want to toss out there, for folks that are viewing as we get close to wrapping up here. If you do have any questions, jump in and ask them. But Derek just to follow up on that, it sounds like it’s never too late to refocus. So even if a product is out the door, it’s been shipped, it’s never too late to refocus and double down on accessibility efforts.

Derek:
No, of course not. It would never be too late. And as we know, apps evolve and change over their life. A good app is updated frequently, and this could be packed into another update just like anything else. It’s never too late.

Tobi:
Yeah. It probably will have better release notes on the app store, or then just say bug fixes, which is what it usually does for every app.

Derek:
Exactly. You nailed it.

Dan:
That’s awesome. So, yeah, I want to build on the training that Katrina talked about. That was incredibly powerful. I’ll even go as far as to say powerful. When we were going through that, I don’t obviously develop … Well, maybe not obviously, for those tuning in. I don’t develop software, I don’t know how to do that. I host these. And that was something that was incredibly powerful for me to see, the impact, the product development and software developers, designers, QE, delivery leads, the power they have to impact people’s lives, both negative and positive.

Dan:
And so making that choice to take the time, have a mindset of empathy, and really focus on the user experience as a whole can just be so positively powerful for people. So I think the training was fantastic. I encourage anybody who is interested in this stuff, by all means, look into that because it was really, really great. And I think what we can probably do too, Katrina, if you remember the link that we used for training or the company we went through, we’ll have our marketing team drop that into the chat here or the comments after this goes, it can be watched again.

Dan:
So with that, any partying statements before I let you all be free and go about your day?

Kitty:
I wanted to touch on just a word that you mentioned, Dan. Thoughtfulness. As folks learn more about accessibility and we’re reading through WCAG criteria, taking it beyond the checklist and using the powers of empathy, digging deep, and thinking about why we’re doing it and why maybe some images need a better description, and some images don’t. If we’re trying to get the important content to a user that can’t see the site, that’s the criteria we need to focus on and not just checking boxes on the list.

Katrina:
I would just echo what Derek said, that it’s never too late to start to add accessibility on your existing application. The best time to start something is yesterday, but the second best time is today. So let’s get going.

Derek:
And I would like to say, I’m looking forward to a future where accessibility isn’t just something that we can add, but something that we do add every time. And I think if you look at the direction that the app store is going, especially, they’re enforcing unique privacy standards right now with Apple sign-in and unique accessibility requirements could be on the horizon. And that’s a future I look forward to.

Dan:
Awesome. Well, thank you so much, all three of you, for joining us today. Providing your expertise on this, highlighting what motivates you in this area. Thank you so much.

Katrina:
Yeah, of course.

Dan:
Tobi, that was fantastic, wasn’t it?

Tobi:
It was. As you were sharing about the training as well, I remember taking it, and as a developer, I’ve gone through many … You implement the accessibility, but that training really was very eye-opening for me as well, because you just learn so many ways people use your product and even the impact of making it easier for somebody else to use it. So, yeah, it’s always great learning more about this. And as Derek said, looking forward to that future where this is the norm. Basically, right now, there’s some things that are normal. Like, “Oh, you should do this kind of design.” Looking forward to that day where accessibility is something that we just do all the time.

Dan:
So we did get one more question popped in. I’ll have our team respond back in the comments. In your opinion, what is the best way to test for compliance? So I’ll have either Dave or either Katrina, Kitty and Derek, if you can afterwards jump into the comments and provide that answer, that would be fantastic.

Dan:
So, I have to say, I’m incredibly proud of Detroit Labs for focusing on this. I’m proud of the team for bringing this to us. I can still remember the conversation that we had in the large conference room with Katrina and another team member, saying we really need to focus on this and we really need to invest in training, and I’m so glad we did that. As the team said, it’s never too late to work on this. So if you have a product that’s out there, it’s never too late to focus on this.

Dan:
We can actually help with that. So we can help you get that product up to accessible standards. We can also help you from a process standpoint, from the very beginning, all of our projects, all of our engagements with clients, all have accessibility from the very beginning. We can either help as part of a project, or we can help as a process to be applied to your current project.

Dan:
So with that said, don’t forget to, let’s see if I can remember it, Tobi. Don’t forget to follow us on LinkedIn. Subscribe on YouTube. We have great content. We’re also on Twitter and Instagram. I know you’re a big IG fan, right?

Tobi:
Yeah. I love IG. It’s the simplest. Well, I say simplest. The feed is the simplest of all of them. So that’s why I like that.

Dan:
As a real estate mogul, no Tik Tok. Dave, just let us know, no Tik Tok. Tik Tok. Tik Tok. Tobi, are you on Tik Tok?

Tobi:
No, but I get the best videos forwarded to me. So, I get [crosstalk 00:34:08]

Dan:
You don’t need it. You have a Tik Tok curator.

Tobi:
Yeah, yeah.

Dan:
Are they on payroll?

Tobi:
They’re not yet on payroll.

Dan:
Okay. All right. I need to get a Tik Tok curator on payroll. All right. With that, Dave, why don’t you play us out? Thanks everybody for tuning in.

Tobi:
Thanks, everyone.