Transcript
Stefan Tilkov: Welcome, listeners, to a new episode of the CaSE Podcast, another conversation about software engineering. Today I'm extremely happy to have Nic Steenhout as my guest, and we're going to be talking about web accessibility, a topic that's dear to my heart. I'm really happy to have this on the show, finally... And I'd like to start by asking Nic to introduce himself.
Nic Steenhout: Hi, Stefan. Thank you for having me on the show. Introducing myself - I am a web accessibility consultant. I've been working on web accessibility for nearly 25 years. I work with large companies, I've had clients like airlines and Fortune 500 companies, and I also work with a lot of education providers, government departments, and smaller non-profits as well.
Nic Steenhout: My main focus is to help organizations become more accessible, provide more accessible websites, applications, platforms, and generally help folks understand why accessibility is important and how to implement it as a whole.
Nic Steenhout: I'm a speaker on the topic of accessibility, so some of your audience may have heard me at one PHP conference or another... And I'm a podcaster, where I have a podcast about (strangely enough) accessibility.
Stefan Tilkov: Okay, we'll definitely link to that. I can heartily recommend that one. So we're basically going to do a giant ad for your podcast here, which I'm really happy about...
Nic Steenhout: Thank you.
Stefan Tilkov: Let's dive right in. Maybe we should start by defining the term accessibility. What does that mean?
Nic Steenhout: That is such a loaded question, and it's one of the reasons why a lot of people have problems with it. I actually ask my guests on my show how they define accessibility, and out of about 50 guests, I had about 50 different definitions. But it always comes back to something similar to the idea that accessibility is the inclusive approach to building websites that work for everybody, regardless of ability or disability. If we unpack that, it really comes down to realizing that everybody uses the web if the web is accessible for them, and that we want to build inclusive things. We want to make sure that everybody can use it, whether it's someone that has a condition that really impacts their ability to function, whether it's someone that has no sight, or no hearing, or no control over their hands... Or things that might be not as obvious - maybe someone's colorblind, like 8% of men in the Western hemisphere.
Nic Steenhout: If you have a toggle and the only thing that makes the difference between the toggle is on or off is that there's a green dot or a red dot, then chances are you're cutting out a percent of men from being able to easily use your platform.
Nic Steenhout: So it's a wide range of things, and we have to think about trying not to design for the edge case, because there is no edge case. It's always about people. I like to say that accessibility is a technical solution to a human problem.
Stefan Tilkov: So it sounds as if part of what you're saying is that it's a very wide spectrum of things. There's no such thing as the people who have accessibility issues and the people who don't, like it's a binary distinction between those two groups. There's lots of grey areas in between, where maybe somebody has a problem in some partial aspect, or maybe only a temporal problem, whereas somebody else has a more fundamental problem... I don't even know whether "problem" is the right word... Issue with accessing whatever it is that we're offering.
Nic Steenhout: Yes. It's really complex, because as you point out, you have some people that have a specific condition. Say, George is blind, and that's not likely to change. But then you have people that may have conditions that are degrading, so maybe they are starting to lose their sight, and as they're growing older, they're going to get less and less sight. But maybe it's something that varies. Maybe because of whatever condition, maybe one day they're gonna have good control over their arms, and then the next day they're gonna have tremors, and that means they can't use a mouse at all.
Nic Steenhout: And then there's this concept that a lot of people in the disability community are talking about, is this concept of TAB. Everybody is Temporarily Able-Bodied, meaning that at some point you are going to get a disability; maybe not something permanent, but maybe you're gonna break a wrist, or maybe you're going to put a splinter in your eye, or maybe you're going to play soccer this weekend and you get a really big knock on the head and that affects your concentration. Or maybe you had COVID and now you're dealing with brain fog, and you don't know if it's gonna last three months or six months or a year or forever. So there's a whole range of situations where you have temporary impairments.
Nic Steenhout: Then there's the situational impairments. For example, say a young mother has an infant in her arm, the infant is sick, she's trying to find information about the symptoms her baby exhibits on her cell phone - I guarantee you that she has a problem concentrating, because she's worried about the baby, and if the website talking about these things is not using clear language and good contrast, it's going to be really hard for her to function.
Nic Steenhout: Then the last layer of it all is when we're talking about accessibility, we're also talking about it's good for everyone. We say "Don't use gray text on gray background, because it's bad for people with low vision." But I guarantee you, if you put gray text on gray background and a really young person with great eyesight tries to read the content on their phone, outside in full sun, they're gonna struggle. So we're talking about accessibility being good for everyone.
Stefan Tilkov: Okay. I think that's an excellent summary, and probably most people will agree that it's a good thing. It's a good thing if an application or a website is accessible to as many people as possible, in principle. But I still observe many people viewing this as something that's sort of an add-on. It's something that of course would be a good idea, but lots of things would be good ideas. If you're building a minimum viable product, maybe accessibility shouldn't be part of that... Because first of all, you're serving the majority of your users, the ones you care about most. And while you do care about the people who have accessibility requirements, they're still the minority. So what's the value in doing that? How if I think it's a good thing in general do I counter those arguments? If I as a developer want to do things the right way and my project manager or architect or boss in general tells me "Yeah, sure, but we don't have the money to do that now."
Nic Steenhout: There are many arguments you can use, whether to try and convince somebody, or even just convincing yourself. The first thing is this idea that we don't have the money, and accessibility is expensive. And yes, for sure, you can spend hundreds of thousands of dollars remediating a website that's not accessible. It's a little bit like building a house though... And I'm gonna use an example that people can really visualize easily.
Nic Steenhout: If you build a house and you put in a 30-inch door, and you have two steps in front of the entrance, you've just made it impossible for wheelchair users to come in. And suddenly, if you need to have wheelchair users come in, you're gonna have to take the door out, break the door out, make a bigger hole for a bigger door, fix all that, then you're gonna have to pour a ramp over the steps, and suddenly that costs you a lot more. If you had built it with the wide door and the level entrance to start with, the cost difference would have been negligible. You're talking maybe 1%, 2%.
Nic Steenhout: The other aspect in our world in development is that a lot of accessibility can be done without extra cost, because if you understand HTML, if you understand accessibility basics, just the way you should understand performance basics and security basics, these are basic skills you should not even have to spend extra time about. You just build muscle memory, and as you're going, you're building things accessibly, so you don't have to convince anyone.
Nic Steenhout: However, let's say you do have to convince someone. You can point out a) the costs are bigger if you try to retro-fit accessibility after the fact, b) it's going to be even more expensive if your platform or your website is one of the 5,000 websites being sued every year in the United States for a lack of accessibility. So suddenly, you're not talking just about development costs, but you're talking about legal fees, you're talking about possible damages... So it gets very expensive, and very messy as well. It's like blueberry muffins - if you make a blueberry muffin and you don't put the blueberries before you bake the muffin, it's gonna be really messy putting those in at the end. And accessibility is a little bit like that.
Stefan Tilkov: That's an excellent analogy. I love that. So could you liken it to something that's kind of on everyone's mind these days, which is security? Security is not a feature that you add at the end of software development. "We've developed this. Now we'll make it secure." That's gonna end in disaster as well. It seems like accessibility is the same kind of thing.
Nic Steenhout: It's the same thing, it's the same thing. I like to think of accessibility, security and performance as the three legs of a stool that you must consider from the very start of the project. Even before you have your designers start putting colors and font sizes and all that, from your wireframe stage, you have to start considering accessibility and thinking about the interactions and thinking about how are we gonna mark this up... Because if you don't, then you're making it harder and harder. And as you're going through, your designers hopefully will give you information about what they had in mind.
Nic Steenhout: So a good designer would be able to say "Okay, this is an H1. This is gonna be a button, this is itemizing all the elements... Because otherwise, what they're doing is they're giving developers a photo of a cake and saying "Go bake this." Without the recipe, you are going to do your best, but that's only what you can do. You cannot necessarily replicate what the designer had in mind really well. You're going to have to make a lot of assumptions about what's expected for the interactions, for the UI, and even the user experience. Everybody has a responsibility in terms of implementing accessibility, and the sooner you do it in the design process, the better it's gonna be.
Stefan Tilkov: That makes a lot of sense. Another argument I heard a lot of times which I'd like your thoughts on is that if you're building something that's accessible, especially if it's in some sort of e-commerce scenario of sorts, then you're actually widening your market, you're opening up to more people who can actually use your services, and that's actually a very strong monetary argument to support those things. Would you agree with that?
Nic Steenhout: I'm gonna give you my favorite answer, which frustrates most people... It depends.
Stefan Tilkov: A consultant answer.
Nic Steenhout: Yes, it's one of those things where I really like the images that we can conjure when we're saying "At the latest official survey from the CDC in the United States we found that there's 26% of adult Americans that have a significant disability." So more than one in four people has a disability.
Nic Steenhout: I like that the World Health Organization is saying that the buying power of people with disabilities worldwide a few years ago was 350 billion dollars. Those numbers are very, very impressive. The reality of it is we actually don't know; I cannot tell you "Make your site accessible and you will get X increase in sales." I can't tell you that.
Nic Steenhout: I can tell you that not everybody who has a disability has access needs on the web, but I can also tell you that most of my clients are really focused on making sure that their website is compatible with IE11. And if you're looking at the amount of traffic that comes through from these older browsers, you're gonna get maybe 1%, maybe 2% of traffic, and I can guarantee you that there's more than 1% or 2% of your (potential) audience that you're not looking out, that has this need. So yes, you will see increased traffic.
Nic Steenhout: The other thing is the disability community is quite a community, and we talk to one another. So if I'm going to the Widget website and it's not accessible, but a Gizmo website is actually accessible, I'm gonna tell everybody, "Hey, don't go to Widget, because you can get the same things at Gizmo and it's accessible." And friends and families tend to also patronize these sites that work better for family and friends... So it's not a solid black and white kind of thing, "Build it and you're gonna get more sales", but certainly it makes a lot of sense, and we are people with disposable income; sometimes not very much, but we still need to buy things to function, we still need to shop, we like entertainment, we hire developers... We just function in the same world as everybody else.
Stefan Tilkov: Okay. I think those are all very convincing things in the end... So let's move on, maybe to some of the things that actually go wrong. Some of the things - or many of the things, in my experience, that hurt accessibility are things that nobody has really done on purpose. It's not as if anybody intentionally breaks their website or web app to make it less accessible. These things happen because people don't know, or don't care enough, or some tools, or other things, or best practices that turn out not to be so good lead to those problems. Can you give us some examples of things that hurt in terms of accessibility?
Nic Steenhout: Yes, I can. And I will. I think the first thing that I would suggest is that your favorite framework is probably your biggest enemy... And I say this from a perspective of being framework-agnostic, because whether you're using Angular, Vue, React - it doesn't really matter what you're using - these platforms as is are not particularly good at delivering accessible outputs. Some of the things that happen that are problematic is, for whatever reason, these platforms have tended to rely a lot on non-semantically-meaningful elements, for example divs and spans, to replicate the behavior of elements that already exist in HTML. So you can make a div behave like a button, but the amount of heavy lifting you need to do to make that happen is significant, and most of the time it's not done.
Nic Steenhout: For example, you can use the button element, or you can use a div and then modify that behavior; so you would have to have the div, then give it a role of button, and give it a type index of zero to make it keyboard-accessible. And then you have to maybe give it different values and attributes to replicate what needs to happen. So the potential for mistakes here for accessibility issues is huge.
Nic Steenhout: In fact, when I do accessibility auditing, I would venture to say that a good 60% of the issues that I find that need to be fixed are a direct result of the default output of frameworks. So that's one big issue.
Nic Steenhout: Now, there are some ways to create accessible content in these platforms, absolutely, but you have to be aware of them, you have to look out for them. You have to take some care in how you develop things. So that's the first aspect, choose your tools well, because they matter... And know your tools well, because the output matters.
Nic Steenhout: When we're thinking in terms of what kind of things we're putting in, what kind of features we're putting in that might be very cool - well, then that becomes problematic as well. For example, we use disabled buttons a lot, so until the person has accomplished specific steps, we don't let them click the button; we make it disabled. Which is a problem, because disabled problems typically are gray, and they're hard to read, and you're gonna have people that have low vision and don't really perceive the fact that it's grayed out on purpose. So there's gonna be a lot of added cognitive load in terms of why is this button disabled. Unless your workflow is really clear as to "Okay, complete this, this, this and that, and then you can hit this button", it's not gonna be very clear.
Nic Steenhout: Carrousels - for some reason, designers still love carrousels, and they are fiendishly difficult to make accessible. It's very difficult because often you have interactive elements, you have things that move on the screen, you have images, you have image of text, you have a whole range of moving parts (quite literally) that you have to cater for, and that makes it really difficult. So carrousels are one of these things that is used often and actually really shouldn't. They don't bring that much stuff. They're cool for the stakeholders, they are cool for the designers, they can be a fun challenge for the developer, but the end user does not really benefit from that.
Nic Steenhout: Here's another one that's really tricky - date pickers. We build date pickers where we use a mouse, we click on a field, a little calendar pops up, and then we can select a date. But we don't think about how that interaction functions for people that actually can't use a mouse. How does it work for a keyboard user? Are they actually able to open your little calendar and navigate the dates? Is it navigation with using the Tab key, or is it navigation with using the arrow keys? How did you mark this up? How is the interaction working for people that rely on screen readers, that software that helps primarily people who are blind interact with computers? As the name implies, it reads the screen, but it does a lot more than that. It allows you to interact with the application on the browser, but if the date picker hasn't been marked up properly, it's gonna be really difficult, if not outright impossible, to use a date picker.
Nic Steenhout: A solution for that is actually easy - create a single input where you can put the date, you can actually tag the date, so you then approach it with belt and braces. You have the widget where people who want to use the calendar picker with a mouse, they can, but you also have an approach where people who prefer to just type in a specific date in a field can do that as well.
Nic Steenhout: I think that's one of the things to think about - different people have different ways that they process information, and the more ways you can give to your users, the easier it's gonna be for everybody to interact with that.
Stefan Tilkov: I think that may be a very good example - maybe you picked it for that reason - because these date pickers are something that even people who don't have primarily accessibility issues just don't like or don't want to use, depending on what day it is that I want to enter; it may be much faster just entering something as text... And the thing is I as a developer don't really know. I don't know anything, or I don't know much about the people using the software that I'm building, so I shouldn't make too many assumptions about what works best for them. Instead, I should give them options to do things the way they like to do it.
Nic Steenhout: Yes. It's interesting, because we were talking about business case and how many people with disabilities come to us, and so on and so forth... And we don't have metrics for that. We don't know if someone is using a screen reader, we don't know if they are a keyboard-only user, we don't know if they rely on speech input... We don't have metrics for that. We know what browser they're using, which country they're coming from - unless they're using a VPN - we know how long they spend on the site... We know a whole bunch of stuff, but specifically disability-related we don't know. And that's alright, because I don't want to give up my privacy, I don't wanna have anyone know whether or not I'm using just the keyboard, or if I'm using assistive technologies, or what.
Nic Steenhout: So because we don't know, and because accessibility is good for everyone, and because making things accessible also involves thinking about different ways to consuming the content and interacting with your interactive elements, it really pays off to look at all the possible options.
Stefan Tilkov: You mentioned frameworks already. You mentioned that frameworks can turn out to be accessibility's enemy, or may turn out to be developer's enemy in fact, when trying to achieve good accessibility... What's the solution then? Is it to make that part of the criteria for selecting the right framework, or is it a way of getting to know how to use the framework, so that it doesn't make things as bad?
Nic Steenhout: There's, again, several layers here, because sometimes you don't really have a whole lot of choice in what framework you're gonna use or work with... So definitely, doing due diligence to understand "Is this framework going to allow me to do what I need in an accessible way?" And if yes, is it out of the box, or is it something -- is there a plugin to extend it, or do I need to be aware of modifications that I need to do?
Nic Steenhout: I think with a little bit of knowledge and understanding of accessibility, you probably can make anything sing... But you have to think about it ahead of time, and you need to plan for what's going to happen. And you also need to look at your third-party plugins ad widgets and stuff, because a lot of the times those are not gonna be accessible either.
Nic Steenhout: You may be selecting tools that actually you have no control over what the output is gonna be, but they're not allowing you to provide an accessible experience to your end users. So at this point you have to either look for an alternative that is accessible, or you need to put pressure on the third-party developers to actually make it accessible... Which can be tricky. But I think one of the problems is it's very often difficult to get that information. Developers don't know often the people you're interacting with are not the developers, they're gonna be salespeople who have no clue.
Nic Steenhout: I was looking for an accessible learning management system several months ago, and I reached out to the top 60 LMS providers. I asked them "Does your platform allow the creation of WCAG 2.1 conformant product?" And that was so hard, because most of them didn't respond; some of them did and they just said no. I even had one salesperson tell me that information is confidential, which really boggled me... But in the end, out of 60, I only had 3 that came back and said "Yes, we can actually make this accessible." And out of the three, there was only one that was actually compliant. The other two were kind of compliant, but not fully, and those three solutions were gonna cost my client $50,000 for the first year to use.
Nic Steenhout: So we're ending up with providers that don't actually really know what they're talking about... So as we are going through the discovery process and deciding which platform to use, it can be very difficult to determine whether or not it's gonna work... So you do have to be approaching things with caution. And I realize I just used an acronym that maybe not all your audience may be aware of...
Stefan Tilkov: Yes, I wanted to ask about WCAG...
Nic Steenhout: WCAG stands for the Web Content Accessibility Guidelines. This is a standard put together by the W3C. We are currently on version 2.1 of the standards, and there's going to be version 2.2 coming out soon. So if you hear any client ask that they want to be accessible and meet WCAG 2.0, you can turn around and say "Well, actually, that's outdated. We want to work towards 2.1, or at least maybe even 2.2, because we want to future-proof things."
Nic Steenhout: What WCAG does is it gives us a set of principles, guidelines and success criteria that direct us into making things more accessible. So there's four principles; we're thinking about the acronym POUR. That stands for Perceivable, Operable, Understandable and Robust.
Nic Steenhout: So ask yourself, "Is what I'm building perceivable? Can I actually see it, can I actually know it's there?" Is it understandable? Can I understand what the content says? Can I understand what this interaction does? No, sorry. Operable. Can I actually trigger this widget? Can I interact with all the things? Then, of course, Understandable, which I was just talking about... And then Robust really is talking about making sure your platform is solid, it's gonna be backwards-compatible, there's not gonna be parsing errors, and that kind of stuff.
Stefan Tilkov: Thank you for clearing up the acronym. I had something that I wanted to add which I had in my mind for a while... This whole thing about -- you mentioned that you were looking at tools and checking them whether or not they were accessible or not... And I think many of us have been doing similar things.
Stefan Tilkov: My colleagues and I recently had the same thing - we were looking for a task management tool that was supposed to be accessible, and we simply couldn't find any good one. We couldn't find any good ones that met our criteria or other functional criteria, and also was accessible. And the thing that drove us mad, and still drives me mad to no end, is that there's absolutely no real reason for this. There's no justification why a task management tool would not be accessible.
Nic Steenhout: They ignore it.
Stefan Tilkov: Yes, that's the only thing you can think of. Maybe nobody ever talked to them about -- but why would you not make that a selling point, especially if you recognize that your competitors are not accessible... What a great chance - I can have the best product in the market simply by making it accessible to everyone, because my product is something that's useful to everyone. Why would it not be usable by such a large number of people? This makes no sense at all. It's mind-boggling why it still happens.
Nic Steenhout: It makes no sense at all, until you realize that there's nowhere for developers to know about this, to learn about this. I rant and rave often enough about things that aren't accessible when I'm on Twitter for sure, but if I'm fair and I look at computer science degrees, most of them don't even mention accessibility anywhere at any point in the curriculum. If I look at bootcamps, most of them don't even barely touch HTML, let alone accessibility.
Nic Steenhout: I even had a bootcamp founder tell me "Well, our bootcamp is for local developers and we're here to help fill the demand for the local industry, and nobody wants accessibility. So we're not teaching accessibility." And I'm thinking "But you have no vision here, because I guarantee you, if the people going through your bootcamp have knowledge in accessibility jobs, they will be much more employable, and they can actually get higher money for their skills."
Nic Steenhout: So when we're looking at that and we're looking at the tutorials, most tutorials on the web don't have anything -- they don't even mention accessibility. So where are people going to learn about accessibility unless they listen to a podcast like yours, or come across one of my rants on Twitter...? Unless they have a direct or a secondary experience with disabilities and accessibility needs, where are they going to learn about that?
Nic Steenhout: This is true for every developer, including framework makers, widgets, and all that. The big difference is that when you start having a product that's big enough, you become a bigger target for people ranting about it, and you should be aware... But then you run into the problem we were talking about earlier, that you built it without thinking about accessibility, and now you have a blueberry muffin that doesn't have the blueberries in it, so what do you do?
Stefan Tilkov: Well, you build version 2.0 of the blueberry muffin and everything's gonna be fine.
Nic Steenhout: Well, yeah. Absolutely.
Stefan Tilkov: To be fair to framework developers, I think most of them these days at least know if they have issues. At least they pay lip service to the idea, which is not great, but it's better than nothing. It's better than complete ignorance or claiming that it's completely unimportant and not an issue. They may not have a great solution, but most of them have the will or are starting to have the will to change those things... Which is good, I think, because they have such a huge multiplication effect, because so many people use their tooling.
Stefan Tilkov: Another thing -- again, I'm interested in your thoughts about this... What I've found is that once people know a little bit about this -- they don't have to become experts, but if they know a little bit about this, like the value of semantic HTML, and the way a screen reader works, even if they attend just one session with somebody that demonstrates something like that, they sort of know about this thing, and then they see it everywhere. It's like, you can't unsee it, because you now know -- and now you notice how many things for no good reason at all are not accessible, and just break things without any justification. So that's probably a good strategy to get more people to care about these things.
Nic Steenhout: I love the idea of not creating accessibility experts, but creating accessibility champions. As you say, once the awareness is raised and you have people that start paying attention, you have people that can actually raise the issue, they can be the squeaky wheel within the organization, they can ask their framework or plugin developers "Hey, is this accessible? Why not?"
Nic Steenhout: We don't need a whole bunch of experts, we need people that can do quick tests. "Hey, you're a developer. You're probably power keyboard users, why don't you use your keyboard only to navigate on your website, on your news website, on the website you frequent regularly? Use your Tab key, you use your Shift+Tab to go backwards... Try it a little bit" and suddenly you're going to realize "Hey, this is not easy. Why don't we fix it?"
Nic Steenhout: Become that squeaky wheel, become that champion that -- maybe you don't know everything there is to know about accessibility, because let's face it, nobody does; I've been in this field for a quarter of a century and I'm still learning. But when there's something that you don't know about, "How do I fix this?", you'll know "Well, I can go check out the Web Accessibility Guidelines. I can go look at the education material on the Web Accessibility Initiative website on the W3C. I can do a whole bunch of things to start finding the problem and finding solutions to it. And if I don't know, hey, I know Nic. I know the accessibility Twitter community, I know these resources."
Nic Steenhout: So if you can't fix it yourself, go talk to the expert, but at least you have this understanding that we can't let this stand the way it is because it's broken for so many people.
Stefan Tilkov: Okay. I think we are in complete agreement regarding this. I'm enthusiastically nodding my head all the time... So maybe let's move on to some other strategies. One of the tendencies we as developers or as the tech community have is to just throw a tool at a problem... So why can't we just throw a tool at this particular problem as well? If I have a website or a web app that doesn't have the needed functionality that's needed to be accessible, can't I just have some magical tooling help me to do that?
Nic Steenhout: Well, there are some people out there, some companies that will tell you "Hey, I have this solution. You put one line of JavaScript on your page, and my tool is going to fix everything." They're often referred to as overlays, and I'm going to name them specifically, because they are particularly egregious and problematic. There's AudioEye, there's accessiBe, there's UserWay... Those are three big providers of what is called accessibility overlay. And in theory, what they do is you put in a line of code and it puts in a little button, whether it's a little wheelchair button or other, and that deploys tools to make things more accessible for people with disabilities. Basically, it's trying to fix your website with, as you said, Stefan, magic... Except it's not. It's not magic, it's snake-oil.
Nic Steenhout: These solutions nine times out of ten will actually conflict with the user's assistive technology. So if you have a website that does not work for a screen reader user and you put in an overlay, and one of the overlay functions there is "Read the screen", suddenly you have the native assistive technology and an overlay that's trying to do the same thing, and the two will conflict, most of the time.
Nic Steenhout: You can have the same things with keyboard access and contrast, and all these things. The problem is users that need accessibility know their software, know their assistive technology, have their own solution that they need on every single website. So it's not actually good for them to think "Oh, well I'm gonna rely on one overlay for this side, another overlay for that side." It just doesn't work that way.
Nic Steenhout: If someone tries to sell you something that sounds too good to be true, it probably is... And the reality of it is that overlays like that are magic, they're fairly affordable, I can see the appeal for people, especially if you don't know accessibility and it's very easy for stakeholders to think "I'm doing the right thing. I'm actually making this site more accessible." But it's not. So I would seriously encourage anyone that you know, if you come to a website that there's this little button that says "Accessibility options", chances are it's going to make it worse for users.
Nic Steenhout: In fact, there's a very good web page which is an explanation, and an open letter, and a pledge, all at the same time. It's overlayfactsheet.com. I would encourage everyone to go read that, and if you're on board, which I hope you are, just add your name through GitHub, do a pull request and sign the pledge.
Stefan Tilkov: It reminds me a bit of those snake oil promises, like "We're going to turn your mainframe application into a web application with this magical tool that will screen-scrape your 30 to 70 terminal screens and just turn them into beautiful web apps." Or the things that say "We're going to solve your mobile web problem by this magical tool that will turn your desktop web page into a mobile-whatever page." Those things, as you say, they sound too good to be true, and that's exactly what they are.
Nic Steenhout: Yes.
Stefan Tilkov: Also, it sounds a bit like these tools would work perfectly to solve somebody's legal problem... Which is maybe a good strategy in terms of selling stuff.
Nic Steenhout: Yeah, it sounds like it--
Stefan Tilkov: Even if they do... Do they even solve people's legal problem?
Nic Steenhout: They don't, actually. That's the funny thing.
Stefan Tilkov: Not even that? Okay...
Nic Steenhout: There might be more, but to my knowledge there's three fairly significant lawsuits in the United States that specifically mention accessiBe as a problem with accessibility on the website.
Stefan Tilkov: Okay... So they create the legal problem.
Nic Steenhout: The funny thing is - to keep picking at them, and they might not like, but... If you read the terms and conditions of accessiBe carefully, which really you should, before buying a product... In their warranty of product they're saying that the tool is gonna work if the website validates HTML and passes WCAG.
Stefan Tilkov: That's a very good one. I'm sure nobody who buys the product understands what that means or why it's funny.
Nic Steenhout: Or reads the thing. So basically, "Yeah, we guarantee our product is gonna work if your website is working in the first place."
Stefan Tilkov: Very nice. So we agree that this is something that needs to be built in from the beginning, that requires some knowledge with the people who actually do the design and the development of a website... Which is actually no surprise probably to anybody. But even if you want to do that, if you think you're fairly knowledgeable at this, how do you test that you've done a good job? What's the best way to approach this?
Nic Steenhout: There's three levels of testing. The first thing is you can use automated tools for testing, and there's really good stuff about automated testing and there's not so good stuff. The good stuff is that you can throw an automated test at all the pages on your web assets and it's gonna go through fairly quickly.
Nic Steenhout: The other good thing is it's great for identifying things that might actually be a problem. It's like a linter - you can look at it until your eyes go cross-eyed, or you can let it check that you have your colons and semicolons and commas and all your spacing right. So automated accessibility testers are gonna be good for that. They're going to identify a whole bunch of things for you that are fairly straightforward. However, automated testing tools for accessibility - the best one out there identifies about 40% of all accessibility issues on a website.
Nic Steenhout: So probably, if you have an automated tool that returns one or two errors, you know "Hey, we're in good shape. We're not doing too bad, but we still need to check manually." Checking manually is actually fairly straightforward if you have a little bit of wherewithal about you. The first thing you do is you test with the keyboard. Can I get to every single interactive element on the page? And can I trigger them using only the keyboard? Can I navigate backwards? Can I see where the focus is? Because so often you're gonna have an interactive element, but the focused outline is gonna have been removed, because either the designer thinks it's ugly, or you're using an old version of Bootstrap, and there's a reset in there that removes the default outline, or whatever reason. So that's your first step.
Nic Steenhout: Once you've tested that it works for keyboard users, then you can start looking at your code. Do your images have the alt attribute? And if the image is decorative, so it's basically eye candy, there's no specific information conveyed, then you would use a null or empty alt. If it's an informative image, especially if the image is the only destination of a link, like say for example social media icons, make sure you have clear and concise alternative texts, so someone coming to that link using a screen reader - they're not just gonna hear "Oh, here's a link. Here's an image. I don't know what it is." They would hear "Here's a link, here's an image, and the alt text is Twitter", for example.
Nic Steenhout: Make sure your forms work with the keyboard. Use your browser default resizing. If you're on a Mac, Cmd Plus. If you're on a Windows machine, Ctrl Plus. Increase that to 200%. See if things are breaking. Maybe you have container heights that are defined in pixels, and when you increase the size of the font on the page, that's gonna break outside. So do these kinds of things.
Nic Steenhout: As a developer, you can do these every day. Every time you build something, check it out. It doesn't take very long. You can use different accessibility plugins to help you accomplish the first part, which would be automated testing, and then use the keyboard and a little bit of code inspection and check it out.
Nic Steenhout: Then, if you want to have fun, start learning how to use a screen reader. If you're on a Mac, you have VoiceOver that's built in for free into the operating system. If you're on Windows, you can grab the free open source screen reader called NVDA, which is available at nvaccess.org. If you google "nvda", you're going to get results for NVIDIA, and that's a little bit annoying.
Stefan Tilkov: We'll put all of that, of course, into the show notes as well.
Nic Steenhout: And look on the WebAIM website for introductions as to how to use these screen readers for testing, and you can start having fun with that. I guess that's the thing that I wanna tell everybody out there - we're developers, we always are looking for a technical challenge; think about accessibility as a technical challenge, not as a chore, not as something you have to do because somebody told you "Well, accessibility is now part of the definition of done" and "Oh, why do we have to do this? It's so hard." Well, yeah, it can be hard, but it's a challenge, it's fun. You have the tool and suddenly you have to find ways to do things that you've been doing maybe for three years, five years, ten years, maybe 15 years, and suddenly you have to figure out "How do I do this differently to reach the same result, but in an accessible way?" I think that's just fun.
Stefan Tilkov: Those are such perfect last words... I think we should maybe come to an end. I think this is a great message. We will have a ton of links in the show notes to lots of additional information, because of course, this was definitely not enough time to discuss all of the aspects of this topic. But we have great resources with your podcast, with a lot of the other information that we're going to link to.
Stefan Tilkov: Personally, I'm totally convinced that this is something worth spending time on. I think there are so many positive effects of caring more about accessibility, from the obvious ones for people who can access the stuff that we built and couldn't if we didn't build it this way, to the fact that things are simply better in many other aspects if we build them this way. So I think it's definitely time spent well to learn more about accessibility. Time spent much better than learning about the 13th framework this year... So I think everybody should just get to that. Is there anything else that we should have discussed and haven't, Nic? Or anything else that you would want to add?
Nic Steenhout: I think we've pretty much gone all around the topic, but perhaps the last thing I wanna say is really accessibility is about people, just like building web tools is about people. For some of us, we're building just for the sake of building, but ultimately, what we're building is gonna be used by people, and we should make sure that everybody can use our products.
Stefan Tilkov: I completely agree. Excellent. Well, Nic, it's been such a pleasure to have you on the show. Thank you for your time.
Nic Steenhout: Stefan, thank you for having me. It's been a joy talking with you. I look forward to interacting with you folks on the web.
Stefan Tilkov: Thank you, listeners, for listening. Please check out the show notes, and talk to you next time. Bye-bye!
Nic Steenhout: Cheers!