Episode 3 – Do the Shift & Shuffle

Episode Summary

In this week’s episode of The Accessibility Breakdown, Mark and Justin discuss three accessibility topics from the past week that they found particularly interesting.

Locked Out: Why OTP and 2FA Authentication Fails Users with Disabilities by Sherry Byrne Haber

• Explores how two-factor authentication and one-time passwords create significant barriers for users with disabilities
• Highlights issues with text messaging as a delivery method for authentication codes
• Emphasizes the importance of testing authentication flows with actual screen reader users
• Discusses the challenge of balancing security needs with accessibility requirements

Screen Readers Are Not Testing Tools by Eric Eggert

• Explains why screen readers alone aren’t sufficient for comprehensive accessibility testing
• Notes that screen readers have built-in assistive capabilities that may mask underlying accessibility issues
• Reinforces the need for multiple testing approaches beyond just screen reader testing

Shifting and Shuffling by Beth DeConinck

• Contrasts true “shift left” accessibility integration versus superficial approaches
• Shares a personal experience about detailed accessibility documentation in bug reports
• Discusses the tension between accessibility specialists and developers under pressure
• Emphasizes the importance of education and knowledge sharing rather than keeping accessibility expertise siloed

The hosts conclude with brief comments about the Artemis II mission and its accessibility features, particularly the helpful live captioning.

Go to all episodes

Transcript

Announcer: The Accessibility Breakdown by Inclusion Impact Accessibility.

Mark: Hey, welcome to the Accessibility Breakdown. I am Mark Miller.

Justin: I’m Justin Stockton.

Mark: And thank you for joining us on the Accessibility Breakdown. Every week we discuss three. Topics that are kind of like the topics that surface that we, you know, could be blog posts, could be anything that we read and think, hey, this is an interesting bit of Thought leadership, content. So we pick three and we bring them to you. – Today, the three that we’re going to talk about are, first of all, a blog post by Sheri Byrne-Haber, And that is called Locked Out: Why OTP and 2FA Often Fail Users with Disabilities. This is a topic I think that people have talked about quite a bit, but always a super important one to think about. It kind of gets overlooked. The other one that we’re going to talk about is Screen Readers are Not Testing tools and that may sound kind of funky to some of you that’s by Eric Eggert? And we are going to talk about Beth. I’m going to struggle with this last name, but it’s, D-

Justin: I think it’s DeConinck.

Mark: – DeConinckc. – DeConinck? DeConinck. Beth DeConinck and she wrote this really interesting blog post called shifting and shuffling, which is a cool name for a blog post, but. Her thoughts on shifting laughter are super interesting in that. So… That’s what we have for you today. Are you ready to dive in, Justin?

Justin: Ready to dive in. Yeah diving in right Yeah, let’s start with Sheri’s.

Mark: Sweet so where do you want to start with Sheri’s Sheri’s article is Locked Out: Why OTP and 2FA Authentication Fails Users with Disabilities.

Justin: Okay.

Mark: And it’s, like I said, it’s kind of a topic that’s been around for a little bit. And that’s basically when you think about things like capture, you think about – Is anything that sends you a password For one single use, these things can be difficult for people with disabilities. And you can spread that out probably even further than that, but this is essentially what the article tackled.

Justin: – Yeah, and for those that don’t know Those two terms mean 2FA and OTP. Just backing up, 2FA is two-factor authentication. So that’s needing two factors, usually a password plus a device or a text message or something in order to authenticate.

Mark: Two things. And.

Justin: Then the other thing, the other one OTP is one time password. And so that is a like a magic link or something that is going to be used for one time only after that one time it’s been used. It’s. It can no longer be used again to log you in.

Mark: And I think that If you think about just inaccessibility on a website in general, right? Like it’s something that we as an internet struggle with to this day. Like the majority of the things that are out there on the interwebs are not accessible. And Now you… Add complexity to it because in both of those scenarios, whether it’s a one-time password or whether it’s two-factor auth, you’re adding something else into it. Right, maybe it’s text messaging you or sending you an email or something else, those tend to be the two that I see. What I’m doing. So now the, Chances of an element in that flow. Creating a barrier for that person with a disability is extremely high.

Justin: Yeah. Right. Yeah. I see this a lot with my mother-in-law. And who needs to be able to access things. And we’ve tried to set her up with, you know, Good security, you know, good, like I’ve got a one password to family account, got her in there trying to get her to use these things but She invariably gets stuck. Often. You know whether they sign it into a bank account or whatever and so helping her understand like what these things are why they’re there why she can’t just use a regular password Yeah. I.

Mark: Think, you know, that’s an interesting point that you bring up because the My mother, right? And my mother’s much more technically savvy than she realizes. But I think for anybody who’s older that didn’t grow up and learn the sort of language of technology. And that’s why you and I are probably not as tripped up by it is because we’re just used to the language. We’re really used to the lexicon, the taxonomy, and we kind of get it, right? But the generation before us, or a few generations before us, not so much. And I know my mom went to log in to watch something live. And when she did that, her Chrome browser, it popped up and said, You need to enable your microphone in your. And your camera for this in the fact that it asked her just the fact that it said, Hey, there’s a second thing that you need to do. It was sort of beyond her expectation. Like her expectation was I click the link and I get in. And of course that’s just Chrome being like, you sure you want to share your mic and your camera. Which is reasonable to you and I, but to her, That didn’t matter. What mattered is it asked her to do something that she wasn’t expecting. And that’s very much like, Two-factor authentication. So, and all we’re talking about here is, somebody from another generation, Maybe, I mean, my mom’s is, Smart as a whip. At her age, my parents both in their 80s, but you get a little bit of cognitive decline, you get the confusion, you get, so we’re not even talking about Anything that is something we’ll all experience at one point. And it can throw people off. So the point in this article. Which is almost sounds obvious, but it’s like. Test it. Hand it to a screen reader user and say, can you do this? Like to sit there and guess your way through whether or not somebody can accomplish the two-factor authentication with a screen reader is not going to work. You’ve really got to give it to an native screen reader user and say, “Hey, can you do this?”.

Justin: Or the very least. It’s not even a traditional accessibility problem where it’s, did we make sure that the form fields are labeled correctly and everything? It is a multi-step process that often involves not only the app that you’re trying to gain access to, but maybe an authenticator app, text messaging, some other thing, moving back and forth, a timescale. There’s multiple factors, no pun intended, that all are at play and Different people are going to approach that process differently.

Mark: Well, and it brings up things like, you know, Because you’re absolutely right. And the other thing is you brought in the two factor authentication apps out there as well. So the likeliness that you’re going to be ” – not just introducing a But potentially even jumping back and forth between one or more third-party tools is high. So I think that This plays a little bit of the automated scanning, We all know that if you scan your website for accessibility issues, you’re not going to catch all the accessibility issues. There’s another kind of hidden piece to that. And that is that you’re not necessarily going to even cover all of the different pathways that might exist. This being one of them, because that scanning tool is not going to jump out of your website and into the authenticator app on somebody’s phone and say yes this is fine too and then jump out or whatever you know scan it for errors too and then jump back in so It’s really… In a way, it starts to redefine how we need to think about usability on the web. You know, and locking ourselves into a single code base. Just doesn’t quite cut it, you know? And by the way, like I always like to think of accessibility first in terms of barriers, significant barriers, right?

Justin: –

Mark: What more significant barrier can you have then you can’t get into this at all because you can’t pass the authentication.

Justin: Yeah. Yeah, totally.

Mark: Like out of the gate, you have something that difficult. So what I really appreciated about this article and what I really appreciated about Sheri bringing this article to us was the. The fact that it’s, it was, it’s sort of like almost like gavel banging, right? It’s like, Hey guys, we’ve been talking about this for a long time. It’s still not working. Right. Like we can’t forget this subject. I’m going to bring it up again because I still every day run into this that doesn’t this kind of thing that doesn’t work.

Justin: Yeah. Yeah, she brought up a lot of interesting points. Things that we touched on a little bit during our first episode when we were coming back from CSOD and we had that security session that I sat in. We talked a little bit about some of those things. There’s a couple of things that she brought up Like particularly like around like using like text messaging. As your sole source for delivering a one-time passwords. Already like security. The national st. Standards and technologies, NIST, So it’s like, text messaging should not be your only way of delivering one-time passwords and right because there’s so many different types of attacks that someone can get in there and get that one time password. Get into your account and lock you out so. Don’t use text messages, but we still rely on it. There’s so many websites and applications out there that rely on delivering one-time passwords. Only through text messages, which drives me crazy. Thatty. I’m.

Mark: Sorry, Justin. On behalf of all one… Multifactor authentication.

Justin: Yeah. But too, one of the things that she talks about is the inaccessibility of some of the authenticator apps. I was on a site just this past weekend and it was like, ” you need to download Google Authenticator and you need to use this specific app to do this specific thing.” you know, nerd, geek, I knew that I did not need to use that one particular app, that I could use my chosen app of one password to still be able to do all the same things. I was able to go through and set something up. But if you have a site out there that is recommending that you use a specific authentication app, and that app is not accessible, now you’re locked in.

Mark: You’re locked in, yeah. There’s.

Justin: That weird cognitive space of now you’ve got Google Authenticator and 1Password and Bitwarden and all these different apps over here. Which one of the apps that I store this particular So now I’ve got to go find it within that time window.

Mark: Well, you could have said it right there too, like the time window, like even if it is accessible or let’s just say it doesn’t create a significant barrier. Maybe it’s not very accessible, but a screen reader user can figure their way through it. Well, now they have to figure their way through it and inside of that time box. So it’s, I know for me, it’s a bit of a panic. It’s like, ” where’s my phone? I got to get this. I got to find this.” Then I don’t know about you, but with Microsoft’s authenticator app, that The number changes every, I don’t know what it is, 30 seconds or so. So sometimes by the time you type it into the website anyways, it’s changed.

Justin: And that’s.

Mark: Without introducing an assistive technology or inaccessibility that might slow things down. So. Anyways. I, like I said, I really appreciated, Sheri bringing this back to us basically like resurfacing the subject with a little bit more detail than I think maybe I’ve seen in the past and causing people to think about it because like I said, it’s a significant barrier and it shows up immediately. It’s literally the front door locked when you can’t Get past it.

Justin: Yeah, exactly.

Mark: So. Cool on that one.

Justin: Yeah, I… There was a note at the end of her article on account recovery that said, I’m still kind of spinning my wheels on in my brains that I want to come back to at some point. Maybe I’ll write a blog post or something about that because cat recovery is Yes, it needs to be accessible, but.. Okay. Just like with authentication and security, It’s therefore a very important reason and making it too easy to do makes it diminishes the ability of it to keep you and your data safe. I think that there’s maybe a little bit more than just a note on the account recovery. Maybe to talk about in the future.

Mark: Yeah, and that’s sort of a reoccurring theme. I mean, this whole subject, to your point, it goes back to what we talked about in episode one. And it’s this reoccurring theme of how do you balance. And how do you balance? IAN SEFFERMAN: Security and accessibility in a way that accomplishes both goals because they’re both important goals. And if you look at it one way, they’re at opposite ends of a continuum. But I don’t know that they need to be right that tends to be where all the mindshare goes is like these two things are pushing and pulling each other and the question is – See episode one, we talked about a little bit is, How do you create a framework in which you can talk about it as things that work together and support each other versus work against each other? Alright, well sweet list. This is this other this next one by Eric Edgar. Really the title is alone grabs you and makes you go like wait what Which I really appreciated, and it was a very good read. And the premise of this is that screen readers aren’t testing tools. And the reason why that’s a goofy thing for you and I to read is because There’s almost this soapbox that accessibility professionals are always on that says, hey, you can’t just run tools over your website. You’ve got to manually test it. And oftentimes when we say manually test it, that’s like code for keyboard testing and screen reader testing, right? But. There’s more to it than that. And there’s. Things that you need to consider when you’re screen reader testing because screen reader And I think the point is here, if you sort of were only to look at the Sight through that straw. Best screen reader straw, it has things that it’s not going to catch. So it’s sort of an argument for Manual testing means a complete set of tests because you have to do different things to catch different things. You’re not going to catch everything with a screen reader. You’re not going to catch everything with keyboard testing. You’re certainly not going to catch everything with automation. So it was a really interesting experience. Interesting look and way to think about screen reader testing I thought.

Justin: Yeah. One of the things that it was right there and I thought he was going to make the same comment that I typically use when I describe the similar screen readers are for user testing and not necessarily for like testing automated testing sort of stuff is, It’s assistive technology, and that technology will assist you in completing the task. With a screen reader, you focus so much on the screen reader aspect that you may not realize all of the other assisting that it has, one, built into it, or two, that it’s going to do on your behalf. And so like he says, like there are keyboard commands that you can do that you can click on anything. It doesn’t have to have an on click event or key up. It doesn’t have to identify as a button. If you can get to something, you can send a click event to it in the hopes that it might react and get you to do that thing. So it still has to have an on click event. Sorry, I didn’t mean Yeah.

Mark: To. But yeah. Yeah, just because you can… Pack your way around it. Just because assistive technologies, people try to make them better and better, right? Yeah. What because the web is so bad doesn’t mean we shouldn’t be trying to make the web good right yeah I mean I often think about that with you know screen readers now can look at a and describe the picture to you.

Justin: We do is because the web is so bad Yeah, that’s right.

Mark: Right. And so- You know, like, why do we need alt text? Still, you still need alt text. Like, it’s not. That’s not enough just because that technology can I could pass the fact that you didn’t put alt text in there. You still need alt text. What if the person’s not using that level of screen reader? What if they’re… Looking at it some other way, what if it’s wrong? What if it’s actionable? Just because it can look at that and describe that image, it doesn’t mean that that’s going to necessarily convey effectively – The action that occurs if that image is actual, meaning you click on it and it does something, probably brings you somewhere else. So, So the alt tax still becomes important and if you’re relying on just the screen reader alone, you might miss the fact that you don’t have good alt text in an actionable image. I don’t know. That’s just the one I thought of. Yeah.

Justin: Now you as the creator you get to decide you put that image there for a reason so it’s better for you to describe Provide that context for why that image is there that it is to let something else or someone else speak decide on your behalf Yeah, sure.

Mark: On your behalf. That’s right. Moving on.

Justin: Yeah. The next.

Mark: One is my favorite, I think my favorite name. For a blog post in a long time mainly because it sounds like a dance a song and a dance right it’s shifting and shuffling so maybe next season we’ll all be doing the shifting and shuffling whatever that means and that’s but this is by beth i’m gonna let you do the last name because you had it figured out better than i did The conic.

Justin: Pretty sure it’s beth dakonic Beth, if you hear this and it’s wrong, please let me know.

Mark: Yeah, let us know. So shifting and shuffling, while it sounds like a fun dance, this was really an interesting Discussion and it was based on a personal experience that Beth had with an employer that got her thinking about this. But this it really in my mind, it really helps to find what true shift left is. Versus kind of a to do shift left, right? Thus the title, shifting being shifting left and shuffling being we’re shifting left, but we’re really not.

Justin: It’s like an agile, it’s like, ” we do Scrum, but we changed a few things.” Changed a few things. Some people refer to that as Scrum-butt, is what you’re actually running for your methodology.

Mark: Well, you know, in at a high level we think a shift left and it’s like we’ll start doing stuff earlier So for those of you who don’t, maybe, I think, if you don’t know what shift to left means, right, it’s a term… Related to the software development lifecycle. And essentially, most diagrams of a software development lifecycle start at the beginning of the lifecycle on the left and then move right, just like we read English, right? Left to right. When you say shift left, it means hey, take this thing that’s occurring later. AK on the right and slide it into an earlier position. The left right? Move it to the left and. Where accessibility oftentimes is really contemplated in production all the way to the right. That’s the final. We built a website. Now we’re putting it out there for the public to go try out our two-factor authentication on. And so that’s in production, right? It’s out there for people to use. And oftentimes, I know as an accessibility consultant, probably 90% of the time we’re looking at stuff that’s already in production. That is expensive. It’s already out there at risk, it’s already causing people not to be able to use it, it’s already at risk for lawsuits, whatever the case is. If it’s B2B, it’s not conforming with your client’s rules. And it costs a lot of money. It costs a lot of money to build something and then go fix it, no matter what it is and websites included. We think of shifting left is like, do accessibility earlier. Beth said, yeah. But in some cases, it’s more of a shuffle than a shift because… If you’re doing it earlier, but separate. That it’s not as effective as doing it earlier and integrating it. And I will let you take them there.

Justin: Yeah, it’s that. Yeah, it was a really, I don’t know. It was a really interesting article. I almost felt like at first I thought that I knew Beth at some point because I was like some of the stuff that her conversation that she had between her and her senior accessibility person on our team. It sounded like something that I may have said to someone at some point. But it sounded like that a whole piece.

Mark: Worked for you at some point. Now she’s wrote.

Justin: I don’t know, Beth. But it was a little dismissive. It was a little flippant in that person’s response to her. And it didn’t really kind of address her need. I’m actually going to read it real quick. Basically… Where it kind of got her thinking about all this was Her senior accessibility specialist said that she’s putting way too much detail in her bug reports and was sharing a lot of unnecessary information that’s slowing down her work. They then followed on by saying that developers don’t read the tickets we write. All they want is for us to tell them what to do to fix the problem. Anything extra is a waste. Sounds great. And that it’s not great, But it’s true. And this would be my kind of This would be that extra piece that I would add on to it is that especially in a larger shop, if you’re a software developer, You’re evaluated maybe by the number of tickets that you close, how quickly, the time rush, the crunch. Everyone’s crunched these days to do more with less, all those things. Doing a full documentation in a ticket is probably not the best place for that. And because that’s only going to improve the life of that one developer if, and I’m throwing up the air quotes, if, they read it and they understand it and they have questions about it. So I do agree with the kind of the comment, but I think it was flippant and didn’t give a lot of context that what’s better is Hey, we keep seeing this same problem happen all the time. Let’s take a deeper dive into that. Let’s train the developers. And that’s where the shift left really needs to happen. Let’s push… Let’s push that information further up the stack rather than putting it at the end where the developer who’s already crunched, and isn’t really going to be able to take the time to read it and appreciate it is really where it is.

Mark: Well, and I think, you know, she makes the point that like, Accessibility Smee shouldn’t hold the accessibility knowledge hostage. I don’t know if those are exact words, but… And I think that that’s the spirit in which she was saying, like, I’m going to put detail in there so that everybody can benefit from this and they can integrate it into their processes versus, Hey, I’m trying to make this thing accessible. And then it reminds me of this Saturday Night Live with the IT guy. Yeah. And they would be like, I’ve got this problem. And he would just go, move and then he would sit down and type and you know you say all sorts of like nutty highly technical stuff if you just blah yeah i think that can you know we could replace that skit with an accessibility professional you know like Okay, let me see it. This is what you need to do. And that’s not shifting left. I mean, that’s better than letting stuff enter into production. That’s the shifty shuffle. And maybe that’s what needs to be done today. But the more that we turn people off. On to how to do it in the more that. The general QA staff is including accessibility checks in a way and doing it well, the more that the developers know how to code and know accessibility best practices, and maybe know how to do a little bit of testing themselves, The better, right? That accessibility Smee shouldn’t like hold that tight. They should be educators.

Justin: Yeah, absolutely. But where does that, where that information lives is, and continues to live and grow within an organization, I think is the important part. And that’s, It needs to living in a ticket and If you see that same problem multiple times and you address it, that’s a lot of time writing up a ticket in JIRA or whatever, only to have it then.

Mark: But I’m going to defend Beth here a little bit. Right. I’m on your snite bath. But I think that everything that you say is super true, right? But I think the reality of an organization and you and I know this from the accessibility maturity stuff is right. Like the, because we do the organizational maturity. The reality is it’s a very difficult to. To get leadership to put the things in place that truly make this change. That would be bringing in education for the developers, that would be creating policies, mandating it, not having it be something that can be traded out for speed or whatever. There’s a million things. And as a, loan advocate within a company, sometimes you just kind of keep getting your, you keep getting pushed down, right? Like the mole and whack-a-mole, they’re just like, get back down. Yes, we know. We’ve heard your accessibility stuff. Get back down. And, So I think that. – Well, yes, adding it to the ticket takes a lot of time. From Beth’s standpoint, I bet it was the only thing she could do. – yeah. – Right? It was like, I have control over this ticket. People keep hitting me with a whack-a-mole hammer. Watch what I do with these tickets. And then that kind of resurfaced in this discussion with her boss. And that goes however it goes. But it’s another opportunity to say, hey, we should be doing it this way. And all I’m trying to do is educate the developers so that this problem doesn’t resurface. And if that leads to a bigger discussion and that leads to even one incremental change that’s more of a permanent change, that’s good. So I think that You know, her boss is right? Don’t spend all this time on it. But she was right to go like, okay, you want to keep and I’m speculating best experience, by the way, here. I don’t know. All I know is what I read in the Thing, but just having run across similar stuff. I really can imagine a scenario where she was like, well, don’t hit me with a whack-a-mole hammer every time I bring up accessibility and I won’t cram everything into a ticket. Like that’s what you left me with. That’s what I have. Just my little world over here. I got control over it. So that’s what I did.

Justin: But it’s interesting that From me. I don’t know, I put on the developer hat, you put on the accessibility specialist hat. We just try to defend those positions. But at the end of the day, Both of our roles in that sort of scenario are under a lot of pressure. To do more with less.

Mark: Yeah, 100%. I mean, I’m not even complaining about the manager’s advice. I think the manager gave the right advice. And I think what Beth did worked in that situation because the manager’s talking about it. And like I said, she tried to get somebody to talk about it and out came the whack-a-mole hammer.

Justin: But yeah, it’s, I don’t know, it was one of those kind of articles that I was like reading and I was like, okay, how would I have approached this? I’m a very asset focused person. And so anytime that I do something more than once, I want to pull it out and not have to do it again. And so like, that’s immediately where my head was like, how is this, How is that information going to live on in that ticket so that people, the new hire comes in and knows what to do. It’s just not the best place for it. So I was already starting to think in that mindset.

Mark: Yeah, 100%. But if you’re if that’s what you have control over, have control over I actually admire Beth Cohen, like, well, this is what and maybe it’s different for you than what we’re describing.

Justin: That’s all you have control over. That’s all you can do. You.

Mark: I don’t know. But that’s sort of what I imagine is you go and this is what I got to work with. So, all right, man. Well, yeah. Anything else before we wrap up?

Justin: Just want to say it has been so cool the past few days watching the Artemis II mission. I’m Just absolutely blown away how cool that’s.

Mark: Been. I’ve seen some stuff pop up about accessibility. Yeah, except for some of the stuff too. So that was, I haven’t dove into it yet, but, It’s very cool. It’s very cool, particularly since I just watched the movie. Hail Mary.

Justin: Which is tell me i haven’t seen it yet.

Mark: Fictitious space movie i’m like go to the moon i just want to tell mary it was hail mary’s a good movie go see it i’ve heard the book is good too i haven’t read it but i know so i read the can’t ruin anything for you it’s the comments i’ve got is it follows the book pretty well the book goes into a lot more technical detail So there you go.

Justin: Book and been looking forward to the movie for years so i. Yeah. But the live captioning between and the integrity have been really helpful because a lot of times you’re like, wait, what did they say? And then all of a sudden you’ll see it pop up in the captions below and you’re like, that’s what they said.

Mark: Is that a little bit of a curb cutout effect Yes.

Justin: There? Yes.

Mark: Justin, you’re describing All right.

Justin: Very helpful.

Mark: Well, since I said curb cut out effect, I want to thank everybody for listening now that we have broken accessibility down for you. And I want to remind you to keep it accessible.

Announcer: Thank you for listening to the Accessibility Breakdown by Inclusion Impact Accessibility.