Building a Good Web doesn’t just mean making the current Internet a nicer place, but making an Internet that everyone can use. This week Lola Odelola (Lola’s Lab, formerly of Bocoup) joins the Good Web series to talk about the fundamentals of web accessibility and the fascinating process the World Wide Web Consortium (W3C) uses to develop standards that define how we use the Internet.

Lola Odelola is the founder of Lola’s Lab, a web standards and web education consultancy. She’s discoverable as lolaodelola on Mastodon, X, and Linkedin.  She will be speaking at the London Web Standards conference State of the Browser in September. At the time of this episode’s recording, Lola was working at Bocoup.

This conversation mentions:

• The ARIA Authoring Practices Guide (APG)
• The ARIA testing website
• wpt.fyi, the web platforms test dashboard
• Cory Doctorow’s first episode on our show focusing on adversarial interoperability
• Bocoup’s design for Gobo and Freq

Transcript

MIKE SUGARMAN:

Hello, everybody. Welcome back to Reimagined the Internet. I am Mike Sugarman, often the producer for the show, but taking the wheel for this series that we’re doing on the Good Web. The Good Web, as we’ve covered in a couple episodes by now, is basically dedicated to an important question of if the Internet is kind of awful right now, how do we actually make a better internet? And we’re trying to answer that question by going around and talking to friends and colleagues who are already doing that work and have already been doing that work for a long time. Kind of to say, hey, this exists. It’s not the future. It’s the present. People have really good ideas about how to create a much better life online.

Today, I’m really excited to be joined by Lola Odelola from Bocoup. Lola is an artist. Lola is someone who’s worked in tech for a long time. Founded the organization Black Girl Tech, which worked on bringing more Black women and non-binary people into the tech industry. She hosted the podcast, Lost in the Source. And right now, she works at Bocoup as their leader of the Web platform program, which develops web standards to prioritize care, safety, and privacy of web users. We’ll get into all this stuff.

I’m really excited about this episode. This episode is a long time coming. Somehow we’ve made it to over 100 episodes at this point and have not talked about accessibility on the web, not for lack of trying, but just because we wanted to do the right one. A great time to talk about accessibility is in this Good Web conversation.

Lola, thank you for joining us.

LOLA ODELOLA:

Thank you, Mike. Thank you so much for having me.

MIKE SUGARMAN:

So I guess let’s quickly start with Bocoup, just do a little overview of what’s up with that. So Bocoup is a design firm. We have collaborated with them, actually, collaborated with you on the visual design for our Gobo and Freq projects. Important there is accessible visual design. And that’s a lot of work Bocoup does. It’s kind of this like, I would say, design work for accessibility, kind of trying to establish a co-design practice. But can you tell me a bit about what goes on at Bocoup? I think there’s a lot.

LOLA ODELOLA:

Yeah, certainly. We do, I think design is a part of what we do, but we do so much more. The business is, you know, on one hand, working with different kinds of communities who want similar services that you and your group required in terms of like design, or even more fully building out, like a website or web app for them. And it’s usually organizations who are values-aligned in terms of caring about accessibility, privacy on the web, who want to make sure that the users of their web experiences can do so as freely as possible, you know, with as little hindrance as possible. And so we’ve worked with a few different organizations on that side of the business, and we also consult and advise as well.

And then on the web platform side of the business, this is really where a lot of the standards work that you mentioned happens. And so this side of the business, the kind of projects we’ve done, we built out the WPT.FYI website. And that is a website that is used by the major web browsers to see test available, well, not just them, but anyone really can see test availability, feature availability across the browsers, and how much of those features are tested, and etc. And so we were like, one of the main people behind that.

We are very active in the inter-op group, which is a group of, again, the major web browsers and some independent organizations like us, who care about the inter-operability between browsers. And so the whole project is to make sure that there’s as consistent as possible, regardless of if you’re using Chrome or Firefox or Edge.

And then I guess what we’re going to go more detail to today is like a lot of our accessibility work, which includes standards work, which includes building websites, it includes building tools to run tests and building test suites. It’s so deep, but yeah, I’m sure we’ll have time to dive deeper into that.

MIKE SUGARMAN:

So just to kind of put some specific names and stuff on the types of things you just mentioned. You’ve worked with our friends at the Algorithmic Justice League. You’ve worked with tenants groups in Los Angeles and New Hampshire. You are working with the W3C on specific ARIA standards.

I mean, Bocoup is involved in, I would say, like, if two kind of ideas of the Good Web, one is like actually building an internet that’s like useful for change that happens offline. The other is making sure that kind of the guts of the internet, the browser that you use to get online, the standards that kind of find all the stuff together is as useful for as many people as possible.

I will just say accessibility is not always a priority in web development and web design. It’s often something that developers kind of go and add back in post hoc, right, after the fact. What I do appreciate about Bocoup when we worked with you on the Gobo and the Freq projects, accessibility started with the wireframe. It started with the like, let’s say my house is laid out. It gave us a huge comprehensive document, which is like, hey, when you go to actually build this up, this is not even fun accessibility. So, yeah, it’s important to put this stuff at the beginning of the process. It’s also kind of, unfortunately, not the most common thing in the world.

I think, okay, we’re saying accessibility a lot. Lola, what is accessibility? What are we talking about when we use that term?

LOLA ODELOLA:

Yeah, so accessibility is really an overarching term. And I totally get when people hear accessibility and they don’t really know what specifically that means, especially on the web. I think the most obvious one is around vision. And that’s vision from people who may struggle to see certain colors all the way up until people who have quite low vision. And so there are a number of things within web standards that a website must meet so that it adheres to accessibility standards, like the standard of accessibility we want to see. And quite a few governments rely on what the W3C says is accessible as a way to implement it like legally within their jurisdictions.

And so, as I mentioned, accessibility can be about vision in terms of what you’re able to see, but it could also be about visual processing. So if you have motion issues where you get motion sick or you get nauseous by seeing things move, there’s accessibility things you can do in the browser to help people with those kind of issues, things like turning off or slowing down animations and etc.

And then you have people who have other like visual processing who may be neurodivergent, whether that’s with dyslexia or whether like dyspraxia or autism or whatever it may be that’s preventing them from processing things, which really there’s ways that you know you should be writing, there’s ways you should be spacing your content to make it on fonts that are more friendly and things like that. And so, yeah, accessibility can kind of like span the gamut really.

MIKE SUGARMAN:

Yeah, and like it might sound kind of intimidating for someone listening to this show who’s like, oh wow, I really wanted to start my own small social media platform and now there’s like all this accessibility stuff keep in line. But like, to be clear, a lot of what basic accessibility practice is, is good layouts, it’s using high contrast between fonts and backgrounds so that people can definitely read your words, right? It’s making sure that your text is resizable and if you can highlight the text, then the screen reader can read it using really basic HTML tags don’t make everything a div, right? Use your H1s, your H2s…

LOLA ODELOLA:

Yeah, so that’s what we would call like semantic HTML and we’re saying accessibility a lot in within the web space is called ARIA, which stands for accessible rich internet applications. And basically, under ARIA, there are two kind of properties you have being able to stay the role of a HTML element. And also, being able to say the state of a HTML element.

So for example, you might have an input that’s read only so it wouldn’t be able to be editable, right? And as you were saying, we have things like that and then you have the contrast that you want to use for text and background and you want to make sure you use the semantic HTML elements. And all of that together is what creates an accessible experience for a user. But it sounds intimidating and I understand why people say it, but there’s so much documentation about this now that it’s really just about going through it, you know?

So it’s better to start, you know? And how long it takes is how long it takes when you’re trying to retrofit especially. But it’s a lot easier when you are including accessibility as part of the development process than trying to go back and add accessibility into what you’ve already built.

MIKE SUGARMAN:

Absolutely. And I would say, you know, a lot of people who develop things these days, let’s say you’re using a JavaScript framework because that just makes filming a lot easier, you’re probably using a variety of packages and dependencies. Take 10 minutes to Google if people think that those packages and dependencies are accessible. You can also really easily go into the GitHub and look at the actual source and see if, you know, are they, again, using these HTML or a friendly elements, that sort of stuff. But look into it because, you know, you don’t necessarily have to do this work yourself. If you want to lean on other people, there are certainly projects out there that prioritize it and then there are projects on their own.

And Lola, you mentioned there are good resources. I think we can say you and I can work together on getting a list of links for the resources. One of the goals of the Good Web project is to document all the stuff that people in these episodes are talking about, kind of put that in one place. This is going to be a really nice section to put up there.

Yeah. So, okay. I think I mentioned this a couple episodes in my chat with Ethan, but I don’t talk about this very often, but I am dyslexic. In academia, part of the reason that sucks is because most papers that are published in journals get put online as a PDF: formatted, however, they’re formatted, you’re saying, yeah, usually like a pretty standard sans serif font, but like, they are for me to read and I can’t change the font or anything like that. Right? There’s just a lot of really basic practices online that aren’t great from an accessibility standpoint, which kind of become codified.

And I think, you know, just to give our listeners who don’t experience these things or don’t have someone close to them in their life who does, like, what is using the internet like for someone who can’t see as much difference between colors or someone who is low vision or someone who is blind. Like, what is that like?

LOLA ODELOLA:

Yeah. So, I’m not low vision. Or I wouldn’t consider myself low vision. I wear glasses, but that’s not what we mean when we say low vision in this context. And so, I’m not going to speak for the entire experience, but I’m going to speak in just like what I’ve learned. And what I’ve learned, especially with the kind of projects that Bocoup is doing and the kind of issues we are trying to address, is that there are two main prongs of how low vision or blind users are experiencing the web right now.

On one hand, you have a lack of accessible web components. And that is, you know, when your, when developers are building a website, especially as many are using JavaScript frameworks and things like this, they are built around components. So, when we talked about using the semantic web earlier, the semantic web is you can build components with HTML, yes, but it’s really just about like elements, right? So, you have a header element, you have a paragraph element. A component is taking one or two or three or four of these elements and having, yeah, a web component or a pattern. A lot of JavaScript frameworks use these and many of them are inaccessible to use, inaccessible for screen readers to read.

And so, it’s as we mentioned earlier, accessibility has notoriously been an afterthought when building web experiences in general, which means that web, you know, is kind of like a historic thing. It’s not that these JavaScript frameworks, you know, introduced this problem, this particular problem. It’s that this has been part of the web.

And this can be confusing for assistive technology users who use things like screen readers at best and at worst, it prohibits stays of the web. Like, the screen reader may just not be able to read the element or may read it completely incorrectly. So, that’s one prong, lack of accessible web components.

The second prong is different languages across assistive technologies. So, I’ve been saying the word assistive technologies or screen reader quite a bit. And what those are is a way for people who have accessibility needs to engage with the web. So, the screen reader literally does what it says on the tin. It reads the screen. And so, it voices things that it can see on the screen. And in the browsing context, it can voice when there’s a button, when there’s a button that’s supposed to be disabled, when there’s form elements and things like that.

And so, what’s happened is that, you know, screen reader A and screen reader B can read the same thing, but say, speak different things, voice different things. And so, what happens when you have somebody who is using an iPhone and who is using a Windows computer, both of those devices have different screen readers, use different screen readers. What happens when they’re trying to navigate the same site on both devices and each screen reader is reading the page completely differently? You know, that can also be a very confusing experience and a very unsettling experience, especially in cases where it’s quite important to read what’s on screen. A lot of our job healthcare education is online now. So, it’s even, even more important that we get these things right. And so, that’s the kind of like other prong.

So, accessibility for people who are low vision or blind or who need to rely on screen readers to use the web really need to be able to trust the devices they’re using and the screen readers they’re using, but also know that like the pages they are visiting in the browser are accessible and they can trust that the information that the screen reader is going to read because the pages are accessible is going to be correct and know they’re not going to miss anything, whether that’s for something important or whether that’s for something frivolous, you know, like everybody deserves to just like wind down and you know, watch TikTok on the web in a way that’s, you know, accessible to them.

MIKE SUGARMAN:
Yeah, yeah, absolutely. Yeah, and I think that that’s like, that’s the reality of all the accessibility stuff is it’s like, yes, it’s important to build accessible technologies and, you know, adhere by ARIA standards and all of that. But at the end of the day, it’s like, I don’t know if I’m building social media software, if I’m building a platform, which I actually am, for better or for worse, I want to as many people as possible to be able to like use it and interact with each other, right? I want to make that like a nice, I want to make that a nice place for everybody. That’s just like kind of the point of this thing. Right?

So when I start with that, it’s like, okay, yeah, I have to like, I guess, it’s not even put that much more work into it. It really is a challenge for me to do this stuff, exactly. But it’s just like, I just have to make sure that I’m accounting for that much in the same way that like I’m accounting for, you know, are my other interactions logical to use? It’s just part of that whole process.

So okay, it’d be one thing if I had you on the show to say, hey, I work at this place. This place is friends with the place that you work at. Let’s talk about this topic. Actually, the reason I wanted to talk to you is because you are intimately involved with not just this work at Bocoup, but this work to better the Internet as a whole working with the actual consortiums and other developers who have the ability to really influence this stuff.

So we talked a bit about this before we started recording, but there are a few projects that I think are especially interesting or relevant here. I’ll start, I can walk us through all of them, but I’ll start maybe able to just progress through them naturally.

APG for web developers. What is this?

LOLA ODELOLA:

Yeah. So the APG is the ARIA Practices Guide. And the ARIA Practices Guide is a collection of web components and how they should be written to be accessible. And it’s a list of, you know, loads of patterns and web developers in a similar way that a web developer might go to MDN, the Mozilla Developer Network, to find out how to use a particular web feature or particular element, they would go to the APG to say, okay, I have an alert web component. How do I make sure that my alert web component is accessible?

So that’s what the APG is, the ARIA Practices Guide. And so it describes how to apply accessibility semantics to common design patterns for web developers and others creating the web, not just web developers who build and create on the web, right? So it’s for everybody.

MIKE SUGARMAN:

And you are doing that with W3C. W3C is the World Wide Web Consortium. W3C, it’s actually the body that sets—if there’s HTML standards, if there’s new CSS, that gets added, every time there’s new CSS revision—it’s them. Right, they’re the ones who say this is now the standard. It would be wonderful if you were just making this guide yourself, but you’re actually working them on it, which I think sounds like you’re trying to develop standards with them or at least kind of codify the standard.

LOLA ODELOLA:

Yeah. So like the W3C, the way the W3C works, right, is—and this is just very general, like I’m not going to go into the nuances of the W3C—it’s a standards body.

And there are three main groups. You have a community group where anybody can join, regardless of even if you work in tech or not, you can just join, you can give feedback on specifications that may want to be standardized, right?

And then you have a working group where that specification hopefully becomes standardized. And then you have the technical architecture group. And with the working group, sorry, that is not everybody can be a part of that. You have to be a member organization of the W3C.

And then you have the technical architecture group, which is you can only be a part of that if you’re nominated to be a part of that. And that’s a very small group of individuals who make sure all standards meet specific requirements, especially around privacy, safety and accessibility.

And so what we are doing is we started in the ARIA community group, and we’re actually still there, to discuss how the ARIA-AT app should be and should work and should look like. And then to also discuss the AT driver, which is a specification, as you mentioned, that we want to standardize. And we’ve been involved in a few other groups as well, but the ARIA-CG is the main one. And the idea is that because it’s a community group, we can get the input of volunteers who are low vision or blind or otherwise visually impaired. We can, because of the way the ARIA-AT app works, which I’ll speak about in more detail in a little bit, we need testers, you know, so we can get members of the group to be testers and run tests for us.

We have, apart from Bocoup, the other group who is paid to work on this is Prime Access Consulting, and they are a group of accessibility specialists, and they are writing tests for the ARIA-AT app.

And so the idea that I’m trying to get to is that within a community group, you have such a diversity of who can partake and who can input. It’s not just like big tech, it’s not just the Metas and the Microsofts, it’s the Prime Access Consulting, it’s the independent, you know, volunteers as well. And that just helps make sure we are meeting the needs of the people we want to meet their needs, if that makes sense.

MIKE SUGARMAN:

Yeah, it certainly makes sense. I mean, basically you’re describing as something of a kind of like a democratic framework for making sure that web standards actually represent people who use the web.

I guess, you know, now that I think about it, it might actually be really interesting at some point to do an episode on the W3C, because it’s yeah, I don’t know, the web’s is not possible without it, and it’s a really important organization.

LOLA ODELOLA:

Yeah, I think we could definitely have a deeper discussion about the W3C, especially when we start to think about diversity issues beyond accessibility, which I think it’s something they’ve struggled in, actually. But I think accessibility, saying that, I think their accessibility program is one of their strongest outputs, you know, apart from CSS and HTML and things like that. But as I mentioned, at the top of the program, their accessibility output influences legal policies and laws, you know, and especially in the EU, I’m based in London, and we’re not part of the EU anymore, but we still have to watch what’s going on over there.

And the EU in 2025 are going to be, you know, making it compulsory for every website that operates in the EU to be accessible and meet certain standards. And that’s heavily influenced by what the W3C has done.

So I do think, yeah, I think a deeper episode into just looking at their work and why they’re important, and even some of their failings would be really good.

MIKE SUGARMAN:

Yeah, I would actually, I don’t know if you want to go to now, but it is fascinating to consider diversity issues in the W3C. I mean, the one piece of perspective I have on this is like, on this show, on this podcast, we have not even tried very hard, which is nice. It’s just kind of like worked that way, but we’ve had a lot of people on the show who are not just white dudes.

But I’ve been doing a project, I’ve been researching for the past year and change the history of music community online. And a lot of my interviews for that are white dudes. Because if you want to hear about, yeah, what was going on in the 90s in between news online, it’s like, yeah, it’s pretty homogenous. Yeah. And I could only assume that those are a lot of people who got involved with standards in the W3C also.

LOLA ODELOLA:

Yeah. Yeah. And I think as well, the W3C, it’s going to talk about diversity. Yes, it’s like gender, race, and protector characteristics. But it’s also like, you know, who has the money to be a member of the W3C, what kind of organizations can afford to not only pay to be members, but pay employees to participate in the W3C, you know.

And I think when you, yes, the community groups are great, because as I said, anyone can join. But when you get to the working groups where things are standardized, you know, then you see it’s significantly more homogenous in terms of the kinds of companies who are participating, you know.

And if we want, I think it’s good that big companies are participating in web standards and open webs, especially because the W3C does care a lot about privacy, does care a lot about safety and accessibility. But it, you know, we don’t just want those voices, we want as diverse a pool of company voices as possible.

MIKE SUGARMAN:

Certainly. Yeah, I mean, I guess like one way to look at it is like, one major way that people access the internet is through Facebook. Another major way people access the internet is by going on the computer at their local library. But Facebook has representation of the W3C, but there’s not necessarily like representation by some association of like, yeah, librarians getting people online. And yeah, a lot of that is because like, well, one, I’m not sure there is necessarily an association of like online librarians, but two, like libraries, at least in the States, I don’t know about in Britain are like, notoriously under resourced, despite being one of the future public social institutions, like for me, this country. So yeah, it’s like, really simple. And just like, I don’t know if the brass tacks sense to understand that like Facebook has a little more pull in how standards get developed.

LOLA ODELOLA:

Exactly. Yeah. Okay.

MIKE SUGARMAN:

So, there’s a thing called a driver protocol, right? Use a driver protocol for web testing. You’re also at work on this thing called the AT driver standard, which I believe stands for assistive technology driver standard. Can you tell me a bit about what this standard is?

LOLA ODELOLA:

Yeah. So, the AT driver standard is a standard that describes a protocol. The point of this protocol is that when web developers or assistive technology vendors or developers are writing tests, we want to create a way for them to engage with the assistive technology. So, in this case, with a screen reader remotely. So, for example, somebody might write a test and they want to test that when their mouse is in this element, the assistive technology says the right thing.

But in the test, you need to actually open the assistive technology. Like it needs to run in the context of the test, right? And the way you do that, the way you could do that is you could manually make sure the assistive technology is open when it’s running and run your tests that way. But this driver allows you to do so using automation and using, yeah, in an automated way remotely. And so, you don’t need to manually open the assistive technology. It will open, hopefully, in the context of your test. And we have that working now within our other projects, the ARIA-AT app.

But, yeah, so we want to standardize this. And we want this to be part of the web. We want this to be something that is a tool that helps web developers and assistive technology vendors and technology vendors to run easier tests and make it easier for them to test this stuff. And so, we are, as I mentioned, discussing this in the ARIA community group. But it recently got chartered in the browser tools and testing working group, which means that we can start to put it on the standardization track. So, right now, it’s just a specification. It’s not standardized. And once it goes through the standardization track, which can be, like, you know, 10 years, at the end of that, we will have an AT driver standard.

MIKE SUGARMAN:

And then that standard is also something that you’re working on implementing via a piece of software, which I believe you’re calling the ARIA-AT app. Am I correct about that?

LOLA ODELOLA:

So, the ARIA-AT app uses the AT driver protocol. But it’s more than the AT driver protocol. The AT driver protocol is a small piece of it. But essentially, the ARIA-AT app, the goal of the app is to improve interoperability and use the experience of assistive technologies. And so, we want to enable users to run manual and automated tests. And within that automated test bit, that’s where the AT driver functions. We want to enable AT vendors to see information on feature coverage within their AT or screen reader. And then we want to enable web developers to see information on feature coverage.

And so, the ARIA-AT app is a test suite, essentially. And the patterns that I described in the APG, for example, the alert pattern, there will be a test for the alert pattern in the ARIA-AT app. And that test, you have one test for iOS, which is voiceover. So, you have voiceover in Safari. Then you would have one test for JAWS, which is one of the major Microsoft screen readers. And you have that for JAWS in Chrome. And then you have another test for NVDA, which is an open-source screen reader. And you’d have that test for NVDA in Chrome. For now, we are not going to include Firefox. But for now.

You’ll be able to see that, like, okay, in the voiceover in Safari, this is how much the test parcel failed. So, you might have, like, a 60% score for the component and make it that, like, that would say that, yes, it reads the component in the way we said it should read the component. It does that 50%. And then another test might show another 80 browser does it 100% or whatever the case may be.

MIKE SUGARMAN:

Is this an app that people can use that’s still being developed? Is there a beta? I assume people are saying this might be like, oh, well, I do want to use this developing my thing.

LOLA ODELOLA:

Yeah, no, this is an app people can visit and they can actually see the interoperability reports. And we also have a video on there explaining more about the work. And I can send you a link for that.

MIKE SUGARMAN:

Great, perfect. And that’ll also go into show notes.

Okay, so interoperability, people who listened to the show have heard this term several times. I think the first time we really had a discussion about it was back in our first episode with Corey Doctorow. That must have been like 2022. He was talking about adversarial interoperability, which is the idea that if Facebook doesn’t let you use Facebook Messenger in some way that’s compatible with iMessage and then get back with WhatsApp, we should as users be able to build software that hacks all three of them together.

But interoperability doesn’t just have to be that. Interoperability is just a really fundamental thing, which is that basically from a user point of view, you should be able to have the things you rely on work across all different analogies. So there’s no good reason why the AT driver standard should not work with Apple screen readers and with Windows screen readers.

I think that we think about interoperability issues as the result of some kind of corporate malfeasance. And a lot of times they are. Facebook does not necessarily want you to get your data and take it away from Facebook and bring it somewhere else besides Facebook. But the flip side of that is we’ve had so many years of that kind of walled garden proprietary data thing that a lot of these places, a lot of these companies don’t even think about how their technologies should be interoperable with other technologies.

I always have a music example, but you can’t make a playlist of tracks from SoundCloud and YouTube and Spotify because they don’t have like track IDs that you can like associate across the same platforms. That’s annoying if you want to make a playlist.

But a similar type of problem is just bad. If you are a vision impaired person trying to use your screen reader app and there’s not a standard, that makes sure that everybody interacts with those screen readers in the same way or that those screen readers which are built differently are all compatible with like the stuff of the web. Right?

I mean the accessibility concern and the interoperability issue, like how much of an issue is that today? Like are you really experiencing the web in fundamentally different ways of using different screen readers?

LOLA ODELOLA:

So I will, before I answer that, I will say that I think that what is really good about the W3C is that really at the core it is about interoperability. Right? And so a lot of these companies are kind of weird in a way because they are participating in the W3C and so they are participating in interoperable process. Right? Only to the extent though of the bones of the web. Right? Not to the extent of like, you know, the playlist example you use for instance, right? Which is really more about data interoperability and things like that.

But like the bones of the web, we mostly agree that if you’re on Chrome, you should have as similar as possible experience as if you’re on Firefox. And so if you have a paragraph block or I’ve been using the alert example, let’s say you have an alert component, like if you’re not using an assistive technology, if you have an alert component, that component should be rendered the same way regardless of the browser that you’re using.

And even these smaller independent browsers, most of them use the Chromium browser stack, which is what Chrome is based on. So typically if Chrome, the web browser is being good and interoperable, you can kind of assume that Chromium will be fine as well. So the smaller independent browsers kind of like, you know, get the perks basically of that.

But if somebody who is of low vision, what happens is that how things are displayed in the browser will probably be consistent across browsers. So how it’s displayed in Chrome would probably be consistent with how it’s displayed in Safari. The interoperability aspects comes into play with how the screen reader interprets what’s displayed by the browser.

And so we are really speaking to both browsers and AT vendors to make sure that, you know, there is interoperability, that there is cohesion. We don’t want users to be confused. Most people don’t build websites so that no one knows how to use them or no one knows what’s going on with them, right?

And so it’s in everyone’s best interest, not just the users of these services, it’s in everyone’s best interest that there is interoperability, good interoperability with how these websites and web apps are being interpreted by screen readers in certain browsers.

MIKE SUGARMAN:

Yeah. And I think, I mean, to kind of make a real world example out of this, it’s important and basically universal now that there are curb cuts on sidewalks, right? So that you can easily get a wheelchair up onto a sidewalk. And then that’s good because you should be able to be on the sidewalk. You shouldn’t have to, you know, be in the road when you’re like trying to get around. That’s unsafe.

But if the buildings on that street don’t have ramps to get into, right, then there’s, in some loose sense, like your city is not interoperable with like your businesses or houses and that sort of thing. It’s a level of coordination, which is actually fundamental to everything, working like it should work, right?

LOLA ODELOLA:

Yeah. Yeah. And I will say as well, like, you know, the, we’ve received a very good reception to this work. We’re rarely having to, you know, strong on people to participate, whether that’s browsers or AT vendors, because I think, as I said, we all agree that interoperability is important, you know, like it’s at this point, it’s more about the nuances, you know, when we’re speaking about the specific, the AT driver specification, which we hope to be standardized, it’s about like how the algorithms should be written to do this work, you know, it’s about, do we want to give, you know, certain technologies this much access? What’s the consequence of giving these technologies this much access? How do you want to safeguard our users? It’s the nuances of things at this point. We’re all in a grudge that we need interoperability, you know.

MIKE SUGARMAN:

Man, the thing that I didn’t necessarily see happening in this episode is we’d have a really detailed conversation about standards processes. But it’s super fascinating because I think that it really stands in contrast with a way that we used to talk about the Internet, even until kind of recently, this kind of move fast and break things model, right? This is the like move really glacial and get things right.

LOLA ODELOLA:

Yeah. And I think that is, and you know, not to big-up Meta too much, but our main funder for this work is Meta. Matt King at Meta, he’s an amazing accessibility specialist and has so much, not just experience, but knowledge about this work. He himself is a blind user of the web. And so he has the first-hand knowledge, but also the kind of theoretical knowledge of this stuff. And he’s led many amazing accessibility initiatives.

But you bring up move fast, break things, which is like a big Facebook thing, you know. And now we have that same company embracing the kind of like slow and steady approach in terms of like, doing it wrong, we have deadlines, we have targets we want to meet and things like that. But more of an approach of like, we understand this is going to require, this is too important to, you know, break.

People already have a hard time either having an accessible experience or building accessible experiences. And so we want to make sure that when they are adopting these things and using these things that, no, they’re not breaking that they’re working. So we can make it as un-frustrating as possible. We can make it as nice as possible to use an experience, you know. And yeah, we’re really, really lucky to have Matt King on our side, because as I said, he’s very passionate about this work. But yeah, I do think it reflects a kind of like, changing how we think about building technology.

MIKE SUGARMAN:

Slow and steady keeps coming up in this Good Web series. It’s such an interesting motto for this type of work. But I think it kind of universally applies, like, yeah, get it right, take the time you need. Exactly.

When we were talking about our interview before, we got together to record this, we said Facebook would come up. And we also said Facebook wouldn’t be the only place we would name because we want to make sure that all the other people who are doing great work get credit too. So who else are you collaborating with? Who else is working in this space? Who’s doing exciting work? Yeah.

LOLA ODELOLA:

So I mentioned Prime Access Consulting earlier in the show. We work with them to build the ARIA-AT app to discuss and collaborate on the ARIA practices guide and also the AT driver specification. So they’re amazing group of people. Also, Microsoft has been a big part of this. Michael Fairchild in particular. Michael Fairchild and Matt King are both coaches of the ARIA community group.

And then the ARIA community group, which is full of volunteer testers and other interested companies of various sizes. And that group is really core to the work that we’re doing. There’s so much we wouldn’t be able to do with that group of people, whether it’s the testers who are working on their own time, essentially, to run these tests and make sure that they were able to resolve conflicts and things like that to the people who are inputting based on their experiences or based on how their company wants to implement this work and all of that stuff.

And also that the assistive technology vendors, such as Vispero at the moment, who we are engaging with these tests. And we’re saying, this is the result of the test for your screen reader and they’re coming back to us and saying, okay, we will look at it. We will see what we can do in terms of implementation and all of this are changes happening. And yeah, those are the collaborators/stakeholders that we’re working with.

And also the editors of the AT driver specification. At the moment, the main and current editor is Mike Pennisi, who is a principal engineer at Bocoup. But previously it was Mike and Simon Pieters, who works at Mozilla now. And they both edited the AT driver specification and made it like what it is today. So yeah, just wanted to shout them out too.

MIKE SUGARMAN:

Lola, thank you so much for this incredibly insightful, but also I think super accessible. Accessible in terms of easy to understand conversation about accessibility standards, all of this stuff. It’s pretty in the weeds, but I really appreciate you keeping this stuff super easy to understand.

And yeah, I think that’s exactly how people should look at all of these technologies, all these protocols, all these standards. They are easy to understand. It’s not intimidating stuff. And I just super appreciate your time coming here and walking us through it. So well, Lola Odelola from Bocoup, thank you so much for joining us.

MIKE SUGARMAN:

Thank you for having me.