Accessibility Advocacy, Automation and Best Practices | #8 Quintin Balsdon

Transcript of the podcast

Video version of the podcast is available on Youtube.

Summary

In this episode of focustrap, Tim Damen speaks with Quinten Balsdon, a technology advocate, about the importance of digital accessibility. They discuss Quinten's journey into accessibility advocacy, the challenges faced in developing accessible applications, and the role of engineers in creating inclusive technology. The conversation also touches on the future of accessibility, particularly in relation to AI, and the need for collaboration and training within engineering teams to ensure that accessibility is integrated into every stage of the development process.

Digital accessibility means including people of all abilities. - Quintin Balsdon

Chapters

About Quintin Balsdon

Quintin is a seasoned Android developer with a passion for technology that dates back to his childhood. With a Master's degree in Computer Science, he has built his career around mobile development while expanding his knowledge across various platforms. Quintin specializes in application quality, focusing on accessibility, test-driven development, architectural patterns, and performance optimization. His enthusiasm extends to wearables and IoT technologies, where he actively engages in development projects to stay at the cutting edge of these emerging fields.

Follow Quintin on:

• Linkedin

Training engineers on accessibility is crucial for creating inclusive products. - Quintin Balsdon

Join the Conversation

New episodes will be released regularly!

Ready to join us on this journey? Subscribe to focustrap wherever you get your podcasts and stay tuned for upcoming episodes that will inform, inspire, and help you contribute to a more inclusive digital world.

• focustrap on Spotify
• focustrap on Apple podcast

Together, we can make technology work better for everyone, one conversation at a time.

Transcript

TD: All right. Hello, and welcome at Focus Trap, a digital accessibility podcast. My name is Tim Dahmen, and I'm joined today by Quinten Balson, technology advocate at Yvinst. Welcome, Quinten.

QB: Hi, Tim. Thanks for having me.

TD: So nice that you are able to join us. We are hosting podcasts online, which is very nice. Of course, you're calling from the UK, I believe, right?

QB: That is correct. Yeah, I'm in Southeast London.

TD: Nice, nice. That's nice. Going to kick off with a signature question I can say now. What does digital accessibility mean to you?

QB: Well, to me, it really means including people from a vast arena or spectrum of ability to be able to independently use apps and devices and be able to participate in society really. So it ranges from things like banking, entertainment, you know, everything. As many people should be able to do anything independently. It's kind of like it's the gap of what a lot of developers usually miss, which is like they usually develop stuff for themselves rather than for the wider variety of people.

TD: Yeah, indeed. Now we are living more online, our online services are Um, widely available, of course, uh, almost over the, the services we used to have offline, um, becoming more and more online. Um, so being able to participate in this online world is, um, Very important, of course. And this is also what started your journey in accessibility. Is it part of the reason you started advocating for it?

QB: Yeah, like it was the platform formerly known as Twitter. It was a few years ago. I was just kind of scrolling through. I think I had just joined and I was contracted out to a bank at the time and we were kind of frustrated with accessibility, especially just screen readers, because that's all you thought that accessibility was. And I read a tweet where somebody said, you know, they were talking about how an epileptic service dog will go and look for attention from someone when the owner needs help. And people were just like interacting with the dog as if it just wanted attention.

QB: And they were frustrated with this, very rightly so frustrated with this. And I was like, but how are you supposed to know as someone as a layman who doesn't know? And I just. I love the idea of trying to get involved and trying to help on a greater scale. And it gave me more meaning at the bank that I was working at, like, because, you know, if you're just moving money from A to B, it's kind of boring, but you can, you can inject meaning into your work by seeing it as making people independent. And that really started a whole spiral of inspiration for me.

TD: Yeah. Yeah, no, indeed. And how, how, how do you see, for example, this, do you see, for example, a banking app, um, you used in your, uh, uh, just now a banking app, um, as it was developed, uh, at, at the time you were, you were there and, um, inaccessibly developed, um, do you now see this as a complete product as a complete feature? What accessibility? Well, the banking app that was not accessible at the time.

QB: It was unfortunately a cross-platform and it was a mix of cross-platform and native. So the screen reader would actually change accent from when it was in the native stuff to the cross-platform stuff. So it was really not good. And it's interesting because when you, when you develop apps, when you start seeing things that you don't like, you should really work on it, right? You should really do something about it. And so we, we started that and now the app is completely changed. Thank goodness. It is now much more, more accessible app pretty much because it was rewritten from scratch using more standard components and not, not a hack together thing.

QB: So thankfully that has changed. That was many years ago as well, thankfully.

TD: Yeah, no, indeed. But this was your journey into getting started with accessibility. This was your first.

QB: Yeah, that's really my first introduction was kind of these two things happening at the same time, being very afraid of screen readers. And I'm an Android engineer from back in the day, being very afraid of screen readers, how to use them, turning them off is the biggest problem for someone like me. And then You know, just learning all the gestures, learning how people actually use them. But then I got, I got roped into trying to automate things because I'm a huge, huge fan of test-driven development. So writing reliable, deliverable code is something I'm really interested in.

QB: And when we got put on the. uh, national health service app for the COVID-19 pandemic. I got put on the X the Android accessibility side of things. And we were really trying to be a triple a level compliant app. So it was really cool taking the the audit from auditors and being able to say, we've got to fix all of these things. I didn't have to question, you know, whether it was AAA, AA, single A, I could just go with it and learn as I went and try to implement everything. And that was really cool.

TD: Wow. Yeah, I think this. sounds like a really great project to, well, of course, first, this is what's broadly used. So the audience is as broad as possible. Everyone needed to be included. So this is a good selling point for saying, OK, this needs to be as accessible as possible, of course. Well, that sounds great. And how did this go?

QB: Well, it saved a lot of lives, which was amazing. The most disappointing thing, especially from an Android point of view is because of the fragmentation, a lot of people were excluded purely because of the cost of their devices. So like if you can't afford a device with Bluetooth low energy, you then couldn't be included in the app. And that was a sad reality to kind of face. So dealing with that was, was difficult, but it was enjoyable to see the accessibility of it come through. And there were other ways that people could participate aside from the app.

QB: So it wasn't, it wasn't app alone. So that was at least useful, but cumbersome when you weren't on the app.

TD: Yeah. The app was the go-to, uh, I think, uh, or. And it's very accessible to make also non-technical options available, of course, which probably you did in terms of the COVID app. The team was amazing. Yeah. How did the project end up? How accessible or not did you end up?

QB: We got AA plus rated. And I think it was the first app. It's got a weird, it had a weird accreditation or something. It was like medical device as an application or something. It had a weird term, but it was the first one of that kind in either in the UK or something like that. But it was a, it was a very cool. Very cool app that everybody knew whether they liked it or not is another story, but it was designed to protect lives. From a scientific point of view, we've documented and published research that showed that it did save lives.

TD: I think it's a great project and this probably also kick-started your accessibility journey. You can imagine that you've learned a lot.

QB: Yeah, that put it into Hyperdrive. I then really got into using all the different assistive tech. I really wanted to see what I could code and Android being so open source. available to a bit of hackery and that kind of thing, not in terms of the final product, but in terms of how you develop and discover things was super, super useful.

TD: Yeah, because for iOS sites, it's more protected and more Not as open to for this hack, hackery stuff. I can imagine.

QB: Yeah. And Windows stuff as well. I mean, not, not to point the finger at Apple specifically, but like just, uh, you know, talk back for Android, for example, is completely open source. You could download the code and deliver your own screen reader with your own little tricks in it to try and discover things. Like, uh, I have a version that I added commands to it for developers that they could use from the terminal. to control how the focus works aside from having to know the gestures. And then I put it into a user interface. I made essentially a interactable cheat sheet where you don't have to use the gestures to do the actions.

QB: You just click buttons inside the IDE. And that's because it's just completely open source and freely available to do. Yeah, and really cool to play around with that. And it saves a lot of time because you like all the, in knowing where these settings are, how to change them. And it's not just screen reader, but just the whole ecosystem. It's very cool.

TD: Yeah, I can imagine. And also my initial thought was that iOS was the more accessible option. But I think with Android you can go into if you want and if you do it and you can go more into detail now that I think about it. can end up with an even more accessible app.

QB: I think the opportunities for accessibility are fantastic. And I love the idea of having like an accessibility arms race to like get to who can be more accessible. I think Apple definitely has a culture of accessibility that dives a lot deeper than what Android folks do. So even though I think Android can be more accessible, I think Apple folks practice it more. From what I've seen in communities, I, you know, it's not always the rule. Yeah.

TD: Yeah. Actually. So I'm, I'm more like a front end developers are more into web development. All right. Speaking to native developers, to me, it's really strange because the web is unified, right? But with native, there's like the Android site and the iOS site, right?

QB: And they're completely different operating systems and different ways of working. I think one of the big mistakes that people make is they just call it mobile. And it's like, that's not how this works at all. It's two completely different fields. Yeah. And Apple does some really cool stuff like just out of the box. Like the whole operating system, for example, controls your keyboard focus color. So if you're, you know, you don't need to do that, but Android has the idea of accessibility services. You could totally write one. I've tried unsuccessfully too, but you can do it for folks if you, if you, if you so desire.

TD: Yeah, that's awesome. And as an Android developer, I get the feeling that, for example, as a web developer, frontend developer, once you get started in your career, at some point you have the feeling, I know about this thing called accessibility. I see some ARIA labels surrounding my code and I see So at some point, you know about accessibility, but some people just tend not to get into it or don't. Is it the same thing with, with Android or native developers?

QB: Yeah, I think, I think it, it can become overwhelming very quickly. And sometimes you see inklings of it and you don't realize that you see you're seeing it. Like I believe everybody actually does work on accessibility. Everybody knows about it. They just don't realize the extent to which they know about it. So for example, if you make a button that's too small to click, they'll make it bigger so that they can click it as a developer, but they don't realize that someone who's less confident on their motor skills or their hand-eye coordination isn't as good.

QB: They might think to make the button bigger for those people, but they might not think why, and they might not know how big. And it's the same for color contrast. I remember as an engineer, I hate choosing colors, but at least with color contrast, I know what colors not to pick. And I think accessibility provides amazing guardrails in that respect. It actually means that there's some rules you can apply that you can even automate that will help you choose things that will get you there better. But I think a lot of people see accessibility, especially when they look at the web content accessibility guidelines and all that it can be very overwhelming to like try and take all of this on at once and you end up feeling like it's.

QB: this sort of gremlin in a cupboard that you're scared to open the cupboard kind of thing. And not only the criteria, but then the testing of it, all the assistive tech and all the settings and stuff, like for switch access, how are you supposed to get access to switches and know that you're doing it right? Now you can watch tutorials online, but you know, there's such a wealth of experience out there from actual disabled people that you can learn from. That's just amazing.

TD: Yeah. This is something you used to do often or still doing is testing together with, with users.

QB: Yeah. Testing with users is paramount to me. I don't believe that I use the tech right until I've seen someone using it because I used to, for example, with voice control, because of my South African accent, these voice control systems are not designed for me. And when I try to say it, I scream at my phone, swipe down, swipe down. And it turns out you need to say scroll down. And that, that articulation of the scroll helps it a lot. And I got that from watching users actually use the stuff.

TD: Yeah, even small things like this can be of great value, right? And also getting into the realm, you eventually get also into the realm of like preferences. Some users tend to like this more, some users tend to like this more. And then, yeah, of course you need to eventually based on these things that you see, make the right decision.

QB: Yeah, I think it's huge because trying to give people the options that suit them, like Android's very good at, for example, the time to react or time to take action setting. Like you can, from an operating system perspective, say, I need extra time. One of the more disappointing things about that setting is inside the setting in Android, it says, hey, developers might not know about this. So it might not happen. So I try to talk about that setting every time I get an opportunity because that is such a lovely way for you to get some information from your user without having them to program a setting in your app.

TD: No, definitely. That's like a default Android feature that you can enable easily. Yeah.

QB: In your accessibility settings, there's a time to take action, I think is what it's called.

TD: Great that you mentioned it. Talking about big organizations, I think we both have some experience working for big organizations. Um, with lots of different, um, engineering teams, for example. Yeah. Um, and my, my feeling is that when the, the, the team teams that there, if there are more teams, more and more teams, it gets harder and harder to, um, come up with a reliable way of building accessibly building accessible features. Um, yeah. How, how do you see this?

QB: Well, I think training is an amazing thing to do with folks and not to, you shouldn't really just push them into here's a screen reader, go ahead. I think the biggest thing from my perspective that's changed minds is explaining. to engineers that what the social model really is, like that problems don't emit from the user. A user is not a problem generator in terms of your app. Your user is trying to get the job done. And the social model says it's not their fault if they're using a tool or a setting to help them get that job done through your app.

QB: Rather than expecting them to be fixed, which is what the medical model says, we should make sure that our experiences cater to a wider variety of people and a wider variety of settings and services that already exist on the phone. I think training in its positioning in the business environment and education environment, I think education is severely lacking when it comes to accessibility, but like training is the right time because if you try to push this on a developer while they're under pressure to deliver, Not only are they going to push back, but their product managers are going to push back because they're trying, like they're under pressure and learning anything new, being faced with anything new, encumbers them quite a lot.

QB: Like I'm not saying you shouldn't do it when, because it's important, but it's just understand you're naturally going to get more friction from them when, when they, when they're busy trying to release and under high pressure. The best time is to offer some training, get them in early, get them understanding the reasoning behind it. And I think rewarding is also like celebrating the wins. Like, this is great. This works well. is a fantastic way of giving feedback. Not only, you know, when you're giving bad feedback, like, Hey, this is great, but this isn't, and this is how we fix it.

QB: I think that's another thing is you can alleviate a lot of pressure by saying, here's how you fix it. I've done that with a lot of teams where I will go in and fix the first thing, but I won't fix the next six or seven things. Even though I technically could, they need They need to learn it and they need to know how to do it for themselves. And so in previous companies, that's what I've done is I do the template example fix. Or I'll pair with them on the fix and then let them ride with it.

QB: And I found successful. Instances of that is where I've been very explicit on how, how they should fix it. Like this is what code looks like that is accessible. And then they love it. I got, I got a team fixing like. 10 issues a day. And I say to them, how do I get more people to do this? And they're like, well, now that we know what to do, it's just easy. Most of the time, you can fix certain, well, in my

TD: I believe a lot of fixes can be done in one or two lines of code. The low hanging fruit for sure. There's a lot of low hanging fruit that's in control of the developer. Yeah. Doing it right is not such a small effort. You just need to know the little details that come into play when you are building something and that needs to be, if you are trying to build accessibly.

QB: Um, yeah, I think the highest amount of friction is when, when you get into discussions about numbers of users and that kind of thing. Because like for font scaling, sorry, my accent for text scaling. Some, if you start saying, oh, you know, we need, we need a certain, how many users actually need this or whatever. Developers don't actually make those kinds of monetary decisions. So why they're asking is also a question, but usually that's a pushback question that is focused in the wrong area and you're arguing about the wrong thing. Even though with things like text resizing, you can actually say it's something about 20% of your users, that normally that's not enough to convince them.

QB: Whereas if you actually demonstrate that there's potential harm here and that users have a right to these things and it's an ethical thing, that's a far more convincing discussion to be having than when you're trying to talk about numbers. And some numbers you just can't get. And some numbers are far lower.

TD: I would even go one step further and say it's a human right to have accessible apps, especially living in 2025.

QB: Also, you can't measure the users you don't have. If you don't cater to those users, you'll never get them. So counting them is kind of superfluous.

TD: Yeah. Yeah, no, no, indeed. And also the thing that stuck with me that you said is the thing I tried to do from my day-to-day work, tried to focus on the most currently is getting the sharing, getting the knowledge inside of the engineering teams that need to create new features for working agile. Teams constantly are creating new features, right? There's a big backlog in many planning apps scattered throughout the world probably with lots of new features to build. Most of the time, unfortunately, it's still the case and the new features that are added to apps and web apps are not built accessibly.

TD: We're actually trying to change this into engineers building accessibly because of course it can be a strategy to go back and fix the current state the current state of the app and try to fix all of the problems that currently are. The expensive way. Yeah, the expensive way. But if you don't educate the engineering team, if you don't build the processes, add the processes so that new features are built accessibly, I think that should be the focus and not so much like focusing on trying to fix the older already existing problems within the app because these will eventually come.

TD: But actually looking forward is the thing that I'm trying to do. So when you said I will show them one good example and then the rest I will maybe you point to it or you would say, okay, here, here, and here, and here, you should have a look at and try to do it yourself. This is actually, I think, a really good and nice strategy to do it. And it's also how I'm trying to, well, slowly but surely educate the engineering teams surrounding me.

QB: Yeah, I mean, also what you could do is start writing tests for that stuff, right? This is one thing that I love about Jetpack Compose in Android, the new way of defining user interfaces. There are a lot more. there's been a lot more consideration towards the accessibility APIs that you can write really nice tests to maintain that behavior so that you can see that behavior was intentional. But you know, all of this boils down to just good engineering practice. It's not even really accessibility. It's about making sure you know what questions to ask at refinement and that it gets into your definition I've done or what definition of ready is on your, on your ticket and make sure that it's, that the, the testing cycle, it's just been included, right?

QB: It's, it really is just a matter of practice and anything that takes practice. Once you get good at it, it takes a few minutes.

TD: Yeah, no, indeed. And, um, getting into maybe automation. So, um, automating of course. I think automation, how I see it currently is you can do two things. There are like general automation and you have context specific automation, I would say. So the context specific would be in the context of your organization, in the context of your specific application that you are trying to build. Of course, there are differences in building something, something accessibly that can be automated, but that they are specific to your context. And I think there are possibilities to also automate in this way, but also generally general things.

TD: So how should a button behave or other types of like more general stuff.

QB: Yeah, I think that's the power of design systems as well, right? Is when you have a design system in place, even if it isn't accessible right from the outset. Teams can get going, working on stuff. You know, it's, it's part of a parallel development effort that before releasing opponents, at least on a component level, things get accessible before the release. And then it's not every, it's, it's not an individual's job. It's everyone's job together. And that's, that's really a powerful thing.

TD: Indeed, and this everyone's job together. So what would you, so start starting maybe before the design is made until the testers done testing and production release is made. There's a whole development cycle in between, of course, and What would you say is a good strategy to get everyone on board and get started with building accessibility?

TD: Get everyone on board in the beginning.

TD: Yeah. Yeah. So for example, a complete engineering team would exist of designers, engineers, business analysts, testers. So starting all the way from the start of a development life cycle, for example, before the design is even made until after the testing is done and production release is ready. Integrating accessibility in every step is, I think, is something you would aim for if you try to level up your maternity level. And it's, I think, the way to go if you try to stay and try to build accessibly in a sustainable way. But how would you go and, well, Yeah.

TD: And integrate this into the development lifestyle. What, what will be your strategy?

QB: Well, I think, uh, number one is employed people with disabilities.

TD: Yeah.

QB: Uh, you don't necessarily need someone who has identified or, you know, put themselves out there, but they need to be able to, you need someone who's going to advocate, uh, because if you don't know, you don't know. And those are the most dangerous. unknowns, right? So you do need someone who is, is knowledgeable or at least acknowledges accessibility. People with lived experience are the best.

TD: Second best is some, is an advocate. And then, yeah, just, I think as with, as with all things, right. If people consider it to be a nice to have, they will throw it out.

QB: And so how to, you know, energize people and get them involved and get them keen and help them understand the priority.

TD: That really comes with facing the right people. And I think that really comes with facing the right people and including them in the, in the whole life cycle.

QB: So without, without people who are representative of our user base included in our development process. I don't think we're really going to achieve the depth of accessibility that we really want to see. But I also understand statistically, it's difficult to find a screen reader user who's a Kotlin engineer.

TD: And so, you know, it becomes a matter of training.

QB: And I really think that our education system needs to include digital accessibility as part of any like software engineering course. I think that businesses are actually undertaking a lot more than they necessarily should in terms of that kind of training. And yeah, it's something that the disability community has said for years, there's nothing about us without us, right? And so making sure that they are included either in testing, development, research, and that's actually another area that a lot of people don't really consider is a big organization should really start with measurement. They should say, how much of our user research includes people with disabilities?

QB: How much of our design system caters for what are our gaps there? And what are our gaps in terms of the app? And you need to take stock first to understand the sort of scale of the problem. But that doesn't mean you can't start. You can say things like, hey, let's work on what we can. Let's tell the developers to just work on roll name value. You know, just from today, let's have a session. Talk to them about role, name, value, how it works, why it's important. And let's put it in the acceptance criteria. Let's tell designers they need to put headings.

TD: Yeah. What you mentioned and integrating this into the university studies. Yeah. I think there's also parts to do for a tutorial YouTube creators as well. Start integrating this, mentioning it during a tutorial. All right. Yeah. Actually caring about it.

QB: Because there's a lot of opportunities for influences, right? I'd love to see. There are a few influences that are out there that are very cool. There's carry on. Carrie on accessibility. It's Carrie. She does a lot of screen reader and magnifying YouTube videos. Uh, so she's a very, very cool one to, to watch and experience. And she does reviews on products, products that I wouldn't even begin to know how to use, but she's very awesome.

TD: Yeah.

TD: Oh, that's great. Yeah. No, that's great. I think there's, I see things moving because if I look, for example, to universities here over in the Netherlands, front-end, but also UX-related studies are focusing more and more on accessibility, which is a nice thing to see. And we're going in the right direction here. But also, Visibility on conferences or online YouTube tutorials, crash courses. There is some work to do, I would say.

QB: I think presenting it as a separate thing is often the problem. Often if you look at documentation, it's here's how you do a button. And then in some hidden corner of the, this documentation, oh, here's all the accessibility stuff you need to know. You wouldn't do that with security. You wouldn't say, here's how you do, here's how you do a password field. And then hide it in another field, how to actually hide it in or just obscure it in the documentation, how to make it a password field. You tell them straight away. So why accessibility isn't a part of that?

QB: I'm not a hundred percent sure.

TD: This is, this is so nice. I love to compare security with accessibility a lot, because for example, working for a bank, for example, security is like up here, up really, really like top priority, I would say. But accessibility is on the lower end. I think they should level more, of course, well, hackers and it's very important to have a secure system.

QB: I think that's super important because if you make something accessible and you open up a security hole as a result, that could be a problem.

TD: Yeah. Yeah. No, but I, I, I hope we accessibility is going into direction of security as well, because with security, you also have a lot of processes in place. For example, big organizations have a lot of processes in place to make sure that everyone works secure by default. Um, And also there are measures taken to prevent, for example, codes to be pushed to production. When certain security levels are not met, then the pipeline just says, no, all right, this, this, this package, this is a, we can't push this product to production. This is a, in one of our scans, it says no, sorry.

QB: Yeah. And I think that's a big way of selling like automated accessibility is it's release confidence, right? How can I be confident that my release is suitable? Because if it's not accessible, it's not suitable.

TD: Yeah. And really, of course, looking also in this year with the deadline of the, uh, uh, EU accessibility act, uh, um, the end of June. Yeah. Correct. Now that's just another. Another measure, another good reason to step in the right direction, I meant to say, leveling it with security. Because there are lots of rules and lots of legislation already surrounding accessibility, running security. Now also accessibility is following, I would say. And this is a step in the right direction, meaning, all right, sticking seriously. Now we actually have legislation in place in a few months. And also, I think all of the processes and measures will eventually follow.

TD: or staying advocating for it is still important. There should be some champions or some people advocating for it a little bit more.

QB: I think it needs to be a human endeavor and it needs to be done by people who want to do it. I think anyone dragging their heels, kind of doing it out of a begrudging sense of I have to, is never really going to make something truly valuable. You know, if you're not, if, if you're not putting the passion into your product, you're going to get a very bland product and accessibility is the humanity. You can't separate the two. So if you're just an engine, if you're just a developer developing code, you are different from an engineer who builds something of value.

QB: And accessibility is that kind of required quality, more so than security, right? Security, you need it for a specific purpose, but with accessibility, it's a quality aspect that prevents people from actually doing the task. So it's this weird non-functional functional requirement Uh, whereas security is completely non-functional. In fact, sometimes the security itself is the barrier. Uh, yeah. So I think it like, you'll always need people who care because if, if you don't care, it's, it's. It's not going to happen well. And, and regulation has that risk of, of making it very bland and checkboxy.

TD: Yeah.

QB: I mean, if you look at what happened with the, um, preferences dialogue on the web, like the cookie settings, companies have gone out of their way to make it inaccessible, confusing. Um, they make it a. sort of barrier to entry. And it could be so easy, just accept or decline, carry on with your life. It would be so easy if they did that, but instead they make you open up pages and uncheck endless amount of checkboxes just to be able to save what preferences you actually want. And the regulation has now catch up and say, oh, it's got to be as easy to decline as it is to accept kind of thing.

QB: But this is the problem with coming up with over generic regulation. So I hope that doesn't happen with the EAA. I think they're trying to be better because they're saying, look, you need to conform to WCAG, but each territory needs to come up with their own subset of rules and how to enforce it and punishments and that kind of thing. So I think it's right that it's taking a bit of time because they're trying to make it a bit more personal.

TD: Did you also hear about, now that you mentioned it, every country is going to regulate it in their own way. Did you hear about Ireland?

QB: Yeah, I think it could be jail time.

TD: Yeah, jail time for non-accessible.

QB: This would be interesting. I wonder if fear mongering to that degree is, I mean, They probably are doing it as that's the maximum penalty. I think how to determine who's at fault in an organization would also be a difficult thing, but I'm not a lawyer, so I can't speak to that. But it's interesting that they do that.

TD: Yeah, it's, it's very interesting.

QB: It sounds a bit extreme to me, but yeah, I wouldn't want to be the engineer there, but there are other cases where people have gone to, like there was a, there's a course, uh, ethics and software engineering. I think I can't remember the platform, uh, but they, they go through six case studies. One of them was with a car manufacturer where the car manufacturer was faking data in the test environments so that when the regulator came to inspect the CO2 emissions, the car knew it was in a test environment, knew the car was programmed to simulate behavior of being very fuel efficient when it actually wasn't.

TD: I think this was Volkswagen.

QB: Yeah. Yeah. And people did go to jail over that, but whether the engineers are responsible, I think what happened with the engineers is they were just told to make it behave efficiently in certain conditions. So you couldn't really put the engineers at fault there. Whereas with accessibility, engineers could absolutely be at fault. And it's not even ignorance of the law isn't an excuse. You've got to remember that. Like right now in accessibility, ignorance is an almost excusable excuse. Whereas when it comes to legal matters, ignorance is not an excuse. And that, that makes it far more difficult and challenging, uh, for, for engineers at least.

TD: It's an interesting thing that I, I learned just a month ago about the Ireland jailing. Uh, but, uh, well. I hope it won't get so far. And that's also, yeah, of course, yeah, there's this legislation versus ethics, okay. Deep down, of course, as a company, as an organization, as human beings. We should care about each other and we should care about creating accessible stuff. Um, legislation, I think also looking at the more at the bright side, I would say it could be a kickstart. It could be an eye opener for some organizations. Okay. This is, this is a serious topic.

TD: Uh, I'm, uh, uh, there are a few times I've skipped the topic for now, uh, but now I'm going to read up on it and maybe. It was stuck. Maybe it was stick and maybe they will take it more seriously also due to the legislation. But then this transition needs to happen to blinds to more ethical and deep down are willing to build accessible software. Yeah.

QB: I think just human centered design, right? But speaking of motivation, You know, the, the first thing that I've tried to do is I've tried to, I tried to lower lift with the tools that I create for engineers. So I try to prioritize things for them. I try to make sure that I create tools. Like I created the Android ally, which is a free plugin for Android studio that engineers can download. I've started making a keyboard accessory for engineers, like in an IOT situation, very It's very clumsily made because I'm not a C++ engineer. But that emulates a switch device, a keyboard, and it lets you control the screen reader using the keyboard interfaces.

QB: And that's, so that's one way that I've tried to do things. And that, that keyboard thing will work, the keyboard switch thing will work for Android and iPhone, anything that takes a keyboard really.

TD: This is making, making accessibility more accessible.

QB: Yeah. And, and making it, making it a little bit fun. I mean, like this little chip it's called Alley Keys. This is my 3d printed little thing. This is just a thing I'm making at home. It's a teeny tiny little chip. Let me show you one of the chips here. Uh, this is a full on little keyboard. Just doesn't have any keys and it lets you control your phone with the, uh, a website pretty much. You know, so, so lowering the lift is one thing. Education is another thing, but to really convince someone to do it, we need to inspire them.

QB: And this is what I got from a web aim. a web aim blog the other day, he's got this triangle of motivating accessibility change. And at the bottom of the triangle is, is fear. And that's what a lot of people try to do is they try to create fear to drive it, but it's the least impactful way of getting change inspiring people. to do it for themselves is going to be the far more effective and long-term solution to actually doing this. And I think when disabled people are more integrated in society, and this is the sort of cyclical problem, when we create apps that exclude people from society, we don't integrate with them, and then we don't see them in society.

QB: You know, you, if, so if you, if you start by creating accessible apps, you might see them out there in the world a little bit more and understand them a bit more. And then, and then you'll want to create apps that are more accessible. And this is what was great with Twitter's accessibility team back in the day, is they were doing this and through their efforts, I got inspired.

TD: So. That's great. Well, let, let, let. Well, maybe a good moment for us also to inspire others and hopefully the EAA will also help with this and other initiatives. Also working through the great work that you have been doing, creating the plugins and the open source tooling, I think will also help greatly there. last thing that I would like to discuss. So looking into the future of accessibility more. Yeah. Do you see some notable trends, for example, coming up, some things that you would think, okay, these are good development?

TD: Well, I mean, you know, everyone's talking about AI these days. I don't I don't know how well AI is really going to serve humanity.

QB: I think the more we rely on humanity, the more we rely on AI, sorry. The more we rely on AI, the more humanity is going to cry out nothing about us without us. Because AI has severe limitations in terms of learning from immediate experience. It requires a massive amount of data processing power, even water, just to behave. I think if we can give it the right kind of data, like accessible code, maybe AI can start spitting out accessible code. If we given enough context, maybe it could start doing some good suggestions for alt text, given a context.

TD: Because I think it's easy to look at a picture and get a computer to describe it.

QB: I think we could do that, but to give it the correct alt text for the meaning of the context in which it's in is a different story.

TD: And yeah, so just.

QB: I see a lot of good things happening there, but it's early days.

TD: Yeah, I think, if I'm correct, Firefox was experimenting with this, like an on-browser LLM, which Um, was actually, uh, inspecting images and coming up with alt text. If the alt text wasn't there yet, for example, that was the experience.

QB: And captions. I mean, auto-generated captions aren't considered accessible. And I agree. But what they do for you is they give you most of it. And then you can go and fix it and, and make it so, so you don't have to sit there with an hour long video and then have to write everything yourself and get the timings right. Perfectly. It'll do most of that for you. And then you can go and fix it. So it reduces the burden on the creator side in an amazing way. Like.

TD: I'm there with you. For example, I started editing some of the earlier episodes. And of course, part of it is also the transcription and making sure it's done right. And actually, like you said, a lot of it is done well. but it's not perfect. But you can change it indeed. And it makes it a lot easier to do already. So I actually think it's a great example of help we can get by AI. But of course, it's not perfect.

QB: And the more AI tools we have, we could get them talking to each other so that the captions come out even better because they're like, oh, I think this, I think this, oh, let's go back and listen. Oh, wow. Okay, cool.

TD: Yeah. That's I think a nice thing to take away. And yeah, I'm going to thank you for this conversation. I think we had a great conversation. Thank you so much for joining. I hope to have you on another time as well, because I think we are not finished with our conversation. I think we can go on for another hour or two.

QB: I can talk about this all day.

TD: Yeah, no, that's great. That's great. Of course. Then let's plan that in the future for sure. What's great, catching up with you again, Quinten. Yeah, lovely chatting to you, Tim. Yeah. Thanks. Thanks so much to all the listeners, if you like what we do. Please consider following us, subscribing, liking, rating, whatever you would like or leaving a comment that's giving some feedback. It's always welcome. We are here to improve. And also a nice comment is always welcome as well. I'm going to thank you again, Quinten, for the conversation.

QB: Thanks for having me here. Until the next time. Alright.

Takeaways

• Digital accessibility means including people of all abilities.
• Quintin's journey into accessibility began with a frustrating experience at a bank.
• The COVID-19 NHS app was a significant project that highlighted the importance of accessibility.
• Android offers more flexibility for accessibility development compared to iOS.
• Training engineers on accessibility is crucial for creating inclusive products.
• Integrating accessibility into the development lifecycle is essential for sustainable practices.
• People with disabilities should be included in the development process.
• AI has the potential to improve accessibility but requires careful implementation.
• Accessibility should be prioritized alongside security in software development.
• Inspiring engineers to care about accessibility leads to better outcomes.