Making Digital Accessibility More Than Just High Contrast: Building Truly Inclusive Software

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Sheri Byrne-Haber and we're going to talk about accessibility.

Sheri, thank you for taking the time to talk to us today.

Sheri Byrne-Haber: I appreciate the invitation.

Shane Hastie: My normal starting point with these is, who's Sheri?

Introductions [01:08]

Sheri Byrne-Haber: Well, that's a good question. Some days I'm a programmer. My original degree is in computer science. I do still write code even though my computer science degree might be older than many of your listeners. I have a law degree. So I used to be a lawyer and I have an MBA. So sometimes I have my lawyer hat on. Sometimes I have my MBA hat on.

Sometimes I have my coder hat on. I have had a mobility disability since birth, so disability and inclusion has always been a topic quite important to me. I also led accessibility efforts for McDonald's and VMware, so I have a lot of experience in kind of cloud computing. My background before that was in databases.

Most people do not understand what accessibility actually is [01:51]

Shane Hastie: I'm going to assert that most of our audience think that they understand what accessibility is, and we just put some high contrast colours on a screen and it's all fine. I suspect-

Sheri Byrne-Haber: Well, I want to assert that most of your audience doesn't know what accessibility is. Tesla certainly doesn't understand what accessibility is. They actually use the word accessibility in an ad today for their new RoboTaxi that had nothing to do with access for people with disabilities.

So accessibility isn't about whether or not you can get something, which is what a lot of people think it is. It's about whether or not people with disabilities can use something. And that's something can be a product, it can be a service, it could be something tangible, it can be something digital. It could be a combination of those things. Sometimes with physical stuff, it will even include things like packaging, whether or not somebody can get their Xbox that they got under their Christmas tree open, for example.

So accessibility, the short and sweet definition is, can somebody with a disability use your stuff? And it's about a lot more than high contrast.

Shane Hastie: That's what I was going to say. It's huge.

Sheri Byrne-Haber: It is quite large.

Shane Hastie: Thinking of the InfoQ technical audience who are building software for people, what do they need to know and what do they need to think about when building this software?

The importance of the WCAG guidelines [03:15]

Sheri Byrne-Haber: So I would say there are two most important things that need to be top of mind for people who haven't worked in this area at all before. One is that there is a standard that most of the countries in the world that have accessibility laws follow. It's put out by the W3C, the World Wide Web Consortium, Tim Berners-Lee's organization that just turned 30. We just had the 30th birthday party last month, and that is called WCAG, which stands for Web Content Accessibility Guidelines. And there are 50 or 60 guidelines depending on what version you're using. And if you're following those guidelines, you are going to be pretty good for people with disabilities to be able to use your software. And if you're not following those guidelines or you don't know about the guidelines, then chances are you're going to be pretty terrible at it.

We have a saying in our field, which is accessibility doesn't happen by accident. It's an intentional approach to designing and building software so that it will work with assistive technology. And assistive technology is what people with disabilities use in order to interact with computers. So Stephen Hawking, probably the most famous assistive technology user on the planet before he passed away, used an Eyegaze keyboard and a speech interface. Those are forms of assistive technology.

So the second thing that is critical for developers to know is if you don't start with an accessible design system, your end accessibility is going to be garbage. So there are more than a thousand open source design systems out there in the public that you can just download and use. And I've looked at the design system database, looked at every single one of them a couple of years ago. And out of the almost 1,000, about two dozen of them advertise that they were accessible, which means that chances are that 960 odd were not. And I don't think the numbers have improved vastly since then.

So if you're using your own design system, that's fine. You just need to do some stuff to make sure that how you implement those components turns out to be accessible. If you're using an accessible design system, that's great too because that means you can definitely do the right things. If you're using a design system that says nothing about accessibility, you're probably going to be in some trouble if accessibility is your end goal.

Shane Hastie: Shouldn't accessibility be our end goal, full stop?

Accessibility and inclusion should be a key goal [05:47]

Sheri Byrne-Haber: Well, I think accessibility should always be the end goal. Or even better than accessibility, one step beyond that would be inclusion. Don't just look at accessibility as a compliance exercise where you need to check the box and move on, but actually include people with disabilities in the process. Make the entire experience accessible. Conferences and shops and games and all the customer support, documentation, training, all of the things that are associated with the product, make those accessible too. Because disabled people don't just want accessible products. Disabled people want accessible experiences. We want equal access to everything that everybody else gets automatically.

Shane Hastie: So how does that show up? What does that actually look like if I'm designing that end-to-end experience? Not just thinking of the screen with the software, which is an important part of it, but that end-to-end experience, customer service, ongoing maintenance enhancements, all of that stuff.

Sheri Byrne-Haber: So if you're trying to get to the accessible experience end goal, but your company hasn't made any accessibility efforts yet, that kind of tends to be a multi-stage two to three year process to get from nowhere to perfect. And you can do that, and I recommend going about doing that in a way called maturity modeling.

So accessibility, here's another myth that your audience needs to know. Accessibility is not the accessibility team's job. Accessibility is everybody's job. It's the QA team's, it's design, it's procurement, it is everybody if you really want to do it well. So that kind of change requires a cultural overhaul. And the best way to perform a cultural overhaul is to do some maturity modelling and say, "Okay, these six things we're doing right, we just lucked into those six by accident, but these 19 things we have to work on".

And so when you build a mature organization, people aren't afraid to raise their hand and say, "Hey, what about people with dyslexia? I don't think they're going to be able to use that". And people are going to be willing to talk about both the good and bad experience that they, people with disabilities, have experienced and maybe they hadn't disclosed at the company before that they had a disability because they were worried about being discriminated against.

So when you get these cultural changes starting to roll, then people with disabilities are more likely to speak up, you're more likely to hire more people with disabilities who will also speak up, and you will get it trickling into every component of the organization, which is really what you need to be successful.

Shane Hastie: Let's step into the, what I can do in code. What are some of those concrete things that we need to consider? You've mentioned the guidelines and so forth, but let's dig into some examples that I should be thinking about.

Practical changes at the code level [08:53]

Sheri Byrne-Haber: Sure. So the simplest example that we always start with is what's called alt text. So alt text is a description of a graphic that will be announced to a screen reader user, somebody who's completely blind who uses a screen reader. When their screen reader hits that graphic, it doesn't say graphic, it says whatever's been put into the alt text. And so it might say, "Picture of Shane Hastie sitting in front of a bookcase with a pretty floral print behind him". Alt text frequently depends on the context, how it is that it's being used, what information is the picture trying to convey. And if the picture is just there to be pretty and the information is already covered in the text, you can set the alt text to null so the screen reader skips over it. And that way people with disabilities who use screen readers can get through the content faster because it takes longer to listen to something than it takes to visually consume it.

Something a little bit more complicated might be the concept of expand and collapse. So if you're looking at an accordion, the blind user needs to know what the state is, right? They need to know whether that has expanded or collapsed so the person knows whether or not they can go into the text. Or if you're putting some cookies into a shopping cart and the subtotal changes somewhere else on the screen, the blind user needs to know that that change took place so that it's a confirmation, "Yes, my adding the cookies into the shopping cart actually worked".

So we sometimes focus a little bit too much on people who are blind, not because they're the largest group of people with disabilities, but because it's the hardest thing to do, is to make something inherently visual like the web work for somebody who can't see. So about half, maybe a little bit more than half of the guidelines that I discussed earlier, the WCAG, focus on people with vision loss. Some of it has to do with magnification. Does reflow work? Can you make the screen zoom in? Some of it has to do with cognitive disabilities. Some of it has to do with neurodiversity and mobility and hearing loss. So hearing loss, really the only requirement is that any videos that you post have to be captioned.

Shane Hastie: And what about the physical restrictions, physical mobility limitations?

Designing for people with physical mobility limitations [11:28]

Sheri Byrne-Haber: Sure. So I don't use a mouse, for example. I've got fairly bad arthritis in my hands, so everything has to work with a keyboard. So after alt text, which is kind of like one of the big and one of the simple guidelines, the second one I always teach everybody is everything has to work with a keyboard. And the reason for that is most assistive technology is based on either keyboard interaction or keyboard simulation. So keyboard simulation would be like a speech interface where you're saying go to the next field. Well, you're kind of behaving like a keyboard even though nobody's actually touching the keyboard. So without keyboard access, people who are blind can't use your software, people have mobility issues, can't use your software. And so that's the next big one because if that doesn't work, nothing works.

Shane Hastie: What are some of the other common? So yes, blind, but there's also other visual elements. A statistic I've heard is that I think it's 8% of males are colorblind.

Sheri Byrne-Haber: Definitely.

Shane Hastie: Yet we give green and red, and that's the most common colorblind spectrum. I look at traffic lights and I wonder. But what are we doing in our software?

Sheri Byrne-Haber: So to use your traffic light example, yes, they use green and red together, but together meaning on the same object. So usually, red is always in one position and green is always in a different position. So it doesn't matter so much that they're using red and green together because you know it's always going to be in the same place, and it's just a matter of whether that bulb is lit up or not.

So extrapolating that concept to software, you can use red and green together, but you have to use something else with it. You have to use an icon with it, or you have to use some text with it or a pattern. Now, WCAG is famous for not being prescriptive. It won't tell you what to do. It won't say, "Oh, use bold or use a label or use XYZ pattern". It says you have to have something else to go with the colour so that people who are colourblind can distinguish between, "Oh yes, that one's green because it's got this extra little bit going with it like a check mark. And that one's red because it's got an X".

Shane Hastie: What are some other, I want to say, straightforward, I don't want to say simple, things that we should be considering and can bring in? What are, is it the low-hanging fruit?

Accessible implementation starts with accessible design [13:54]

Sheri Byrne-Haber: So accessible implementation, which is your audience, your audience's developers, actually starts with accessible design. If an inaccessible design is given to a set of developers and they develop it 100% to the inaccessible design, it's not going to be very good at the end of the day, even if the developers do all the right thing because the design was bad in the first place.

So if you, the designer, or you, the product owner, whoever's listening to this, wants accessibility to be built into your product as an end goal, the first thing you have to ask is, "Am I getting an accessible design? Has this been through a design review?" If the design is handed to you and it's got a carousel that's continuously moving and never stops and doesn't have a stop button, you will never be able to make that accessible because that is a direct violation of one of the WCAG guidelines.

So there are various different design checklists you can go through, and it's things like, "Okay, what is the page title? What does the heading structure look like? What do my error messages look like? Do your error messages always tell people exactly what the error is and where to go to fix it? Preferably with a link in the error to make it easier for the person to get there. Did the designer specify a skip link in the beginning, assuming that it's HTML, in the beginning so that if the first thing that a page receives this input after the screen is loaded is a tab button, it knows that it has a keyboard user and it gives the keyboard user shortcuts to jump around the page rather than having to sit there and hit the tab button 108 times to get to the footer?"

So those are some things, for example, that developers can ask designers and say, "Well, what about these features that we need for the end result to be accessible?"

Shane Hastie: Neurodivergence. What do we need to do to support a more neurodiversed user community?

Supporting a neurodiverse audience [15:59]

Sheri Byrne-Haber: One of the things that I frequently advocate for to improve accessibility everywhere, and it just happens to benefit neurodivergence more than other groups, is personalization and customization.

So one of the things that we know from user studies is some people who are neurodivergent don't like neon colours. They find them distracting, it gives them headaches. They struggle to make decisions when they're faced with that. So let people personalize their colour choices. Let people say, "Well, you know what? I really just want tans and browns and navies on their screen". You might think it's ugly, but it might be what your user needs to do in order to better use your software. So being able to personalize for no motion is great for people who are neurodivergent. Being able to personalize for no countdown clocks is great for people with anxiety and in general for people with neurodivergence as well.

Colour choices is another one. And then a fourth one that I frequently recommend is avoiding the use of italics because people with dyslexia really struggle to read italics and they really struggle to read things that are centre-justified or any justification other than left justification.

So have a little block with your login where people can select their theming and they can say, "I don't want to see italics. I don't want to see motion. I don't want to see neon colours". And then just remember that every time they log in, they get the same experience.

This lightning bolt hit me. My daughter who is deaf, just turned 33, so this had to have been more than 20 years ago. So she was 12 or so, and she came into where I was working and she said, "Mommy, why doesn't Amazon remember that I'm deaf?" And we unpacked that sentence. It took a bit. And it turned out that she was really angry that every time she went to Amazon to look up lyrics for a song so that she knew the same lyrics that all her friends were listening to, that she had to turn the captions on over and over and over. And to her, it was like a microaggression.

She was always having to say, "I'm deaf. I'm deaf. I'm deaf" every time she had to punch that closed caption button and it just absolutely infuriated her. And so that's kind of when I started on the, we really need to be able to personalize this experience and the personalization needs to be remembered so that people aren't constantly getting the same annoying questions over and over every time they come back.

Shane Hastie: What else should we be considering or adding to our lexicon?

Make accessibility part of the definition of done [18:43]

Sheri Byrne-Haber: I'm not sure lexicon is the right word for my answer, but I'm a very firm believer that accessibility has to be part of the definition of done. Because if it's not part of the definition of done, it's going to get punted first when push comes to shove and you're overdue your past your scheduled release date and you're not quite done with all your features.

Accessibility is not something that you want to do later. It's something that you want to build in from the beginning because if you build it in from the beginning, it's a lot easier and cheaper. If you leave it until the end, it ends up being rework and it ends up having to be a completely separate release cycle, which is not a cheap process when you're looking at all the people, especially at a larger company that have to touch a release on the way out. You have to redo all your QA. You have to redo all your pushes to production and everything else associated with it.

So I would say my number one request would be make accessibility part of the definition of done. And not just generically, but we are going to follow this standard. We are going to follow WCAG 2.2 level AA, for example, or 2.0 level AA if you're doing something for the federal government because the federal government requirements aren't quite as stringent as the rest of the world's. Understand that in less than a year, the European Accessibility Act is going to kick in. And governments in Europe everywhere will stop buying inaccessible software. If you have customers that are in the EU and in the public sector, you need to know that this is coming.

The US government is also starting to crack down. They're doing surveys of all of the people who are getting money under section 508, which is the federal accessibility law in the US and they're saying, "If you're not accessible yet, show us our roadmap for when you're going to be. And if you are a vendor providing software into those environments, you either need to get with the program or you're going to get kicked out". And that's not me being rude. That's just me stating facts.

Shane Hastie: So at a legislative government level, people are taking this seriously. We should have been taking it much more seriously as an industry for a long, long time.

Legislation requiring accessibility [21:00]

Sheri Byrne-Haber: Yes, section 508 has existed for 16 years, and it's really only been the last couple of years that it's been at least paid more attention to, if not quite followed yet, largely because of litigation. So in the US, we're a very litigious society, and the Americans with Disabilities Act only gave us two options if we feel that we're being discriminated against. One is to file a complaint with the Department of Justice, and the Department of Justice does take up some of these complaints, and you don't want to be on the receiving end of that.

And then the other is litigation. There are about 10,000 lawsuits a year in the US over the ADA in general. And about 4,000 of those are about digital accessibility, so access to software, access to documents. The rest is like parking spaces and sidewalks and physical stuff. And those are very, very expensive to litigate. And if it gets to the litigation phase, chances are you're going to lose because it's difficult to prove that you've provided equal access when you're not following WCAG. It's possible. I haven't seen anybody do it successfully yet.

Shane Hastie: Stepping out of the software into your life experience, what are the things that you bump up against on a day-by-day basis? You've mentioned you're mobility limited. What are some of the microaggressions, the little challenges that you face? Or not so little challenges.

Day to day experience of a lack of accessibility [22:28]

Sheri Byrne-Haber: I was in a parking lot literally yesterday, and they had recently retard the parking lot, meaning they'd put down new black asphalt. And they had repainted the accessibility parking spaces, but they hadn't removed the cones even though the paint had been dry for days. So I couldn't find a place to park. I literally had to park almost half a mile away and wheel into the store that I was looking for instead of being able to use the accessible parking space directly out front of the store. Stuff like this happens to me literally every time I leave my house. I mean, it happens so often it almost doesn't register anymore.

The FedEx truck will block the spaces or people will be parked in those spaces that don't have accessible parking tags. I'm not saying you have to be in a wheelchair to use it, but you have to have a legitimate accessible parking pass to use the blue spaces in most states in the United States. So that stuff happens all the time.

When reflow doesn't work, I find it quite aggravating because I use magnification. I have glaucoma in addition to my mobility issues, and so I need to zoom stuff in to be able to read it. Also, because of the glaucoma, I can't use dark mode. People love dark mode. It's like the new darling of design. But what design doesn't realize is there are people that can't use it, and frequently it's people with glaucoma. Sometimes people with dyslexia don't like it as well. It's more of a personal thing. So that's one of those places where if you only provide dark mode and that's your only option, you're never going to be accessible. And the best way to handle it is provide it and then personalize it so I don't have to select dark mode every time I go back to the website. It remembers, "Oh yes, last time you were here, you use light mode. Presume you haven't been cured. Let's go ahead and switch that on".

Shane Hastie: I also know that you have some strong opinions about machine learning and disability, the bias that's built in there. Tell us.

The risks of unsupervised use of generative AI for accessibility [24:35]

Sheri Byrne-Haber: So I have strong opinions about a lot of things, to be fair. I am concerned about the unsupervised use of generative AI. I just posted an example today to LinkedIn. I have a series called Accessibility Fail Friday, and we happen to be recording this on a Friday, where a video that I was watching was talking about a woman with a cochlear implant. Cochlear implants are implanted devices that people use to hear, except they had used auto-captioning, and it came out as a cocaine implant.

So AI is biased because the data is biased. And the data is biased because they're groomed on the data on the internet. That's what they train on. So in the beginning, if you asked DALL-E to generate a picture of a child with autism, you always got a white boy because there's limited other data on the internet about girls with autism or people from other cultures with autism. We exist. It's just the data isn't out there, and that's what DALL-E was trained on. So I think cautiously, and I've used machine learning and I've used generative AI, but I've done a lot of training with the supervised learning and the LLMs to make sure that the data is unbiased that I use, and I don't know that other people are doing that. In fact, I know for a fact they're not because of the results that I see.

Shane Hastie: You've mentioned your blog, and we'll make sure we include a link to that, if people want to continue the conversation, where do they find you?

Sheri Byrne-Haber: So I pretty much live on LinkedIn. I don't use X because Elon Musk fired the entire accessibility team at Twitter when he took over. So I said, "Okay, done there". So Byrne-Haber. There's only two of us with the last name, me and one of my daughters. And if you end up with my daughter, she'll send you my way instead. That's definitely the best place to find me.

I would say if you want to find out more in general about accessibility, the best thing to do is to look for an accessibility meetup in your area. There are both physical meetups and virtual meetups almost all over the United States where you can hear talks about accessibility. There's a great website called accessibilityassociation.org, and that's for IAAP, the International Association of Accessibility Professionals. That's our credentialing organization. And they have tons of really good material and lots, a great big webinar backlog that you can watch to find out more about the topic.

Shane Hastie: Sheri, thank you so much for taking the time to talk to us today.

Sheri Byrne-Haber: Again, I appreciate the invite. I have a saying, which is, good accessibility professionals talk at accessibility conferences. Great accessibility professionals talk at design and developer conferences. So we want to go where the non-believers are so that we can convert you over to becoming advocates for accessibility.

Shane Hastie: Thank you so much.

Sheri Byrne-Haber: Thanks.

Mentioned:

• WCAG Guidelines
• Sheri Byrne-Haber on LinkedIn
• Sheri Byrne-Haber’s blog