📋 Discussion Points

Why a11y matters

A11y in the developer community

It's our (collective) job to make the web-accessible.

Where to start?

📝 Transcript

Previously on Remotely Interesting:  

[00:00:04] Phil: [00:00:04] I think you should all reassess all of the conversations you've ever had with me and just think about how it really went. 

[00:00:12] Cassidy: [00:00:12] Hello, and welcome to Remotely Interesting. 

[00:00:14] Phil: [00:00:14] This is remotely interesting. 

[00:00:16] Amberley: [00:00:16] Well, that seems a little presumptuous. 

[00:00:18] Leslie: [00:00:18] No, no, no, that's the name of the show.

[00:00:20] Music: [00:00:20] [Intro music] 

[00:00:28] Cassidy: [00:00:28] Hello everybody, and welcome back. We're going to be talking about accessibility today. Also known as A11Y, which I know means accessibility, but I always read it as "Eleventy," like the static site framework and it throws me off every single time. But accessibility is important and we also have some team members from the rest of Netlify who work on this a lot.

[00:00:53] So hello everybody. 

[00:00:56] Amberley: [00:00:56] Hey! Howdy, howdy. 

[00:00:59] Phil: [00:00:59] Is everyone comfortable with using the word numeronym? 

[00:01:03] Amberley: [00:01:03] No. 

[00:01:03] Phil: [00:01:03] I'm very happy - numeronym, numeronym. 

[00:01:06] Jason: [00:01:06] I'm comfortable with you using that word.  

[00:01:07] Cassidy: [00:01:07] Yeah, it sounds good when you do it.   

[00:01:09] Phil: [00:01:09] When I realized we were talking about accessibility and we were going to see it written like that, I was just excited at the prospect of being able to say the word numeroym.

[00:01:17]Amberley: [00:01:17] Can we just point every time we need to say it and you'll just say it for all of us? 

[00:01:21] Phil: [00:01:21] I'm at your service. 

[00:01:23] Amberley: [00:01:23] Perfect. 

[00:01:24] Cassidy: [00:01:24] We could do some ASR with that. 

[00:01:26] Jason: [00:01:26] [Laughter] That's - welcome to Phil says soothing words. Okay, so what are we actually talking about today? We're talking about kind of accessibility in general, but I think maybe one of the most important things to start with is just, and I'm asking this, not because I want to know, but to set the stage here, okay? Why does accessibility matter?

[00:01:49] Cassidy: [00:01:49] [Jokingly] You really don't want to know this. 

[00:01:51] Phil: [00:01:51] Who wants that? That's a hot potato. 

[00:01:54] Leslie, do you want to, do you want to open the bidding for why accessibility matters?

[00:02:00] Leslie: [00:02:00] That's a meaty one. [Laughter] I like it. I like it. You know, I always think of it as building software for humans, right? And so at like the very base level, what we're building as engineers are things that people can use, right? So we probably want to reach as many of those people as possible. And you know, there's a lot of diversity in the world, a lot of different types of people using all different types of devices. And so it's our job as engineers to build things in a way that allows as many people as possible to use them at like a super base level, I think. 

[00:02:28] Phil: [00:02:28] I've worked in places where there's been an accessibility expert and it's been - they have their parts of the project where, oh, there's a line item for accessibility. And that always kind of, kind of rankled me a little bit because yes, we need experts, but it's hard to just kind of have one point of a project where accessibility magically happens. 

[00:02:49] So, we don't do that here, do we? Who's - is there an accessibility expert? Whose job is accessibility?

[00:02:55] Amberley: [00:02:55] I feel like Leslie would be a great person to talk about this, at least on the front end core side, Leslie and I both worked together on the front end core side. And speaking for myself from previous job experience, like especially on smaller teams, you tend to have like one or two people who are very personally interested and passionate and sort of advocating for it on a team.

[00:03:17] But I've been lucky to work on a couple of teams, including this one, where it's really sort of a core competency that's considered in the hiring process. So at least on this particular team we have individuals who are more - it's more in the forefront. People are more actively advocating. But as a baseline on the team, we have team-wide buy-in and sort of a built-in team ethos surround it. 

[00:03:46] Leslie: [00:03:46] I would plus one all of that. I think one of the things we look for is like during the interview process, just does it come up? Is this something people have, are familiar with and have used in the past? And that's not, we're not going to not hire you if you haven't done a lot of accessibility work in the past, but it's, is this something you care about? And is this something you'll keep top of mind as you're developing? Right? 

[00:04:02]So it is sort of a process of learning from other folks on the team. I wouldn't say that we necessarily have anyone who's like a hundred percent focused on accessibility all the time, but, as Amberley said, we have folks who sort of champion it internally. And that helps and kind of drifts out to the rest of the team members who maybe are focused on other areas - performance or, well, performance is a bad one cause that's also an accessibility issue, but in some other areas, right?

[00:04:24]So it's about the knowledge share as well and doing some shared code review and pieces like that to kind of spread the knowledge. 

[00:04:30] Hugues: [00:04:30] I want to say, I think if you have the luxury of having accessibility specialists on your team, I think that's super great. I used to work at a company where they had the accessibility team that was kind of like overlooking the product and like everything that we ship to the world.

[00:04:47] So I think if you, if like, I think accessibility is important knowledge for everyone on your team, but if you can have specialists that really like learns and do educational stuff inside the company, inside the team, I think that's awesome. 

[00:05:03] Jason: [00:05:03] I think there's like a nuance to it because I really like that we have accessibility experts in the sense that there is somebody who has deep knowledge, you know, as you said, like, someone who's there to help take things further.

[00:05:16] And I think, you know, like I, I've worked with Amberley at a couple companies now, and she's always been one of those people who will like educate me about something that could be more accessible and here's why it's important and how. 

[00:05:27]But what I think is where we, where it falls over and where I agree with Phil is I don't like it when teams think of accessibility as a thing that happens after you build the tool and you like throw it over the wall to the accessibility people and say, all right, well, you deal with whatever that is. 

[00:05:43] Hugues: [00:05:43] And I think it's important for everyone to buy in. Leadership to buy in and design and content and engineering. I think it's just a culture thing in companies. 

[00:05:55] Leslie: [00:05:55] Definitely agree. It doesn't start with engineering, right? It starts with how you build the product, how you think about the product or whatever it is you're building, right? And so coming at it with that mindset of accessibility, even at its most base core, what are you building level, which involves design and product and all of those sides.

[00:06:11] I think coming at it from there helps bake it into the whole process and not kind of, oh, the engineer gets tagged in, you're ready to build the thing and all of a sudden you're the only one caring are these design patterns we're using even, you know, lend themselves well to accessibility. Maybe there's things we could have thought of earlier in the process to kind of support that.

[00:06:27]Jason: [00:06:27] I have a question. Earlier you said performance is an  accessibility concern. And then just now you said, you know, accessibility starts in the design process. And for a lot of folks, I think when they think of accessibility, they're like, can I push the screen reader button and it like works?

[00:06:44] So it sounds like it's way more than that. So can you give a more, maybe like a broader overview of what we're talking about when we start thinking through accessibility? 

[00:06:53] Leslie: [00:06:53] I feel like Amberley might have a good queued-up answer for this. I feel like she's answered this before. In general, I think it's, you have to think beyond the screen reader, right? I think we so often default to accessibility just being does it work with a screen reader? Because that's a tool that most of us have on our computers already and can test with. So it kind of feels like a defacto, oh, it's accessible if I can use voiceover on it. 

[00:07:12]But there are a bunch of different assistive technologies that folks are using to access certain, you know, the software that we're building. Everything from like sip-and-puff devices to neural, you know, brainwave scanners that are helping people navigate websites and apps. So it's much broader than just one specific area. 

[00:07:32] Jason: [00:07:32] I'm going to ask you to clarify a term. You just said, sip-and-puff, and I'm not familiar with that. 

[00:07:36] Cassidy: [00:07:36] What is that? 

[00:07:37] Leslie: [00:07:37] So hopefully I'm going to explain this well. I'm also not an expert in this, but my understanding is that there is a device that you can use to, essentially, maybe if you don't have certain vocal capabilities, you can sip or puff into like a straw, essentially? And that can send, basically, connect up to some other device and can help you navigate something.

[00:07:57] So I'm not - maybe Hugues or someone else has a little more like specific detail on how it works. But it's a way to kind of interact with things. 

[00:08:05] Amberley: [00:08:05] It's just basically one type of alternative input method. Like another one, another good example that's one that I always recall is I worked at a disability advocacy nonprofit, and one of the people I worked with had cerebral palsy and she worked remotely and she used a chinpad to type using Morse code. 

[00:08:29] Cassidy: [00:08:29] Whoa. 

[00:08:29] Jason: [00:08:29] Interesting. 

[00:08:30]Amberley: [00:08:30] So there's, to go back to Leslie's earlier point of a lot of times you think of accessibility and you think, can I push the screen reader button? And really you should be going all the way across the other side of the spectrum, which is, I cannot perceive the infinitely large constellation of ways that people could input and access. And that sort of universality is what I should think about instead of this one particular input mechanism or access mechanism.

[00:09:05] Phil: [00:09:05] It feels to me like the web is this thing that is so difficult to know how people are going to be consuming it and how people are going to be interacting with it because there's so many unknowns. So it's trying to push the threshold down as low as possible to let as many people in and interact with things we're building in ways that we don't, we can't always predict. 

[00:09:24] I think that's such an art. And I think you've already said there's a bit of a culture and a mindset to that. Just knowing that you can't control everything is really key. I also think it's interesting how extreme some of these examples can be. It's like, well, what, you know, what are we going to be able to support?

[00:09:41] And again go, this, you know, this concern I think can go all the way right through to how do we craft the copy on a button, you know, how do we just write text, which is inclusive and easy to digest for people who either don't speak the first language or, you know, for everybody? And I love seeing the craft that goes into just thinking about what the words are that we write on things, you know, across that.

[00:10:06] I think that's, that's something that kind of goes a bit overlooked often when we talk about accessibility. 

[00:10:11] Hugues: [00:10:11] That's kind of also the beauty of the web that you're, you don't know how your site is going to be accessed, so it can be a phone, it can be like a PlayStation browser, it can be a lot of different things. I think that's the beauty of it. Like trying to make it work for every platform that exists today and that will be created in the future. 

[00:10:31]And I'll still a hundred percent agree about, I think we often look at the - we're developers. We look at like the developers side, that there's a lot on like the language that you use, like the level that you can understand the text, in design, like the colors, the font size. I think there's a lot for everyone to know more about accessibility. 

[00:10:54] Jason: [00:10:54] Well, and I want to come back to the performance is accessability thing and something that - someone shared a story recently, may have actually been one of you, about - it was a person who was in like a government services office and they saw a woman on a PlayStation portable, and they were trying to, they were like, oh, she's just playing a game. And then they walked behind her and saw that she was on the government website and like, you know, it's not a particularly high-powered website. It's just HTML and that device is objectively terrible for browsing the web as a modern web. But because it was accessible HTML, she was still able to fill out the forms and complete the thing.

[00:11:34] And so that's another thing that I think is interesting when we talk about accessibility is like, it's not just like we're building special things for people with special needs. We're building things that work across the spectrum of access, whether it's that your device is low power, that you need a different way to do input or a different way of consuming the information.

[00:11:54] Like I think, that was something that really started to sink in for me was when I started to realize that the things that we're doing for accessibility, we're not doing special things, like extra things. We're meeting base level use cases so that our, the things we build are actually usable, no matter where somebody gets to them from.

[00:12:15] Hugues: [00:12:15] I think that's the, again, the beauty of it, where it serves everyone. So you can be in a particular situation where you don't see the color well on the site and at that particular moment, you need good color contrast. And maybe you never needed it before, but now you're on your phone, you're outside, you have difficulty to see color contrast, and now you need good contrast ratio, right? 

[00:12:42] So that's, I think that sums up well when you say that, like, accessibility is for everyone. It's just, it can affect, it can depend on like your situation or the device you're using or a lot of different factors.

[00:12:55] Phil: [00:12:55] It's like that, that one time when the sun came out in the UK and then I needed to have good color contrast on the screen. [Laughter] 

[00:13:08] Hugues: [00:13:08] '98? 

[00:13:08] Phil: [00:13:08] Yeah, good times '98.

[00:13:09] Leslie: [00:13:09] I love this story Jason just told, too, about the PlayStation. At a previous job, I was working on sites for video games and those sites needed to work on the browser in the system that I was building for. So, and those browsers are objectively like pretty terrible. And so they're like only at the time we, I think CSS3 was like a new thing and you couldn't do most of the CSS3 things in this Nintendo 3DS browser. And so there were all of these, not hacks, but there were things we had to work around to make it work. But it was so important to us to make sure that, okay, you could actually get to the website for this game on the device where people are going to be using it. 

[00:13:45] Phil: [00:13:45] And the, and that, that word kind of "baseline" has kind of crept in a couple of times. And you know, when, just thinking about, you know, we need to make things for different contexts. And, you know, for like Hugues, Leslie, and Amberley, you all work on slightly different pieces of the Netlify kind of web state, if you like, you know, there's the .com, there's the app, there's a lot of pieces and they're built using different technologies.

[00:14:08] And this idea of the baseline is maybe different depending on the tools that you use is an interesting one to me, because I'm a, I'm a bit of a old kind of web curmudgeon who likes HTML, please. I like HTML and browsers do, too. And lots of assistive technologies do, too. And it's a really nice baseline. But we're building more complex things than that these days, you know, when, you know, app.netlify.com is a React app that does lots of clever interactive things.

[00:14:36] So I'm kind of curious about the different experiences that you've all had across different things that we've been building for Netlify based on the tools that you've had to use to build that. What's, what does that look like from a, from an accessibility kind of context for all of you? 

[00:14:51] Leslie: [00:14:51] My hot take is that React itself doesn't cause accessibility problems, right? My hot take there is that developers have access to everything they need in React to make a React app accessible. But it's our job to, to do those things, right? So nothing is preventing us. It's just a matter of knowing the tools, knowing what you have available to you in terms of semantic elements, right?

[00:15:13]All of that is available to you in JSX in React. But it's knowing those tools. It's understanding how focus management works so that you can make sure - actually React, I think, makes focus management easier than it used to be in the pre-React days where you were having to like move focus all around sometimes and do some weird jQuery stuff to, you know, focus in different areas. But React actually makes a little easier to kind of manage some of those things as long as you're aware of it and baking it in kind of, as you go. 

[00:15:37] Cassidy: [00:15:37] I agree a ton. I think there's been plenty of hot takes around the internet of like "React isn't accessible." "Using JavaScript isn't accessible." JavaScript is a language in the browser for a reason. If you use it right, you could do, you can do a lot of things. So I agree with your hot take wholeheartedly. 

[00:15:54]Amberley: [00:15:54] And the data proves that out, right? Like, for example, we were really proud in the Gatsby team last year when the WebAim survey came out, showing that, you know - Gatsby uses React and incidents of accessibility errors were about 50% lower on Gatsby sites than React sites in general. Which to me proves out that it's not so much about the tool as about the community and who's wielding the tool. 

[00:16:25] So we had put a lot of emphasis and intention behind building out accessible examples and building it into the tooling and stuff like that. And I think you see that kind of intentionality ripple out. It doesn't make it perfect, but that's a great indicator of it's more about how you wield the tool than the tool itself. 

[00:16:46] Jason: [00:16:46] I agree with that, like, to the very bottom of my soul because I feel like the thing that's, the thing that's so important in communities and in frameworks is like, we have to lead by example. Right? And so if the frameworks are out there saying you should probably do accessibility, but it's hard so we're not going to do it in any of our examples, they're sending a message. That's communicating to the people who use your tool. Oh, accessibility is hard, we'll do it later, we'll do it later. And then it never gets done because everybody's under deadline.

[00:17:14] What I thought was really cool about Amberley and Marcy Sutton at Gatsby who put so much effort into making sure that it was a top-level concern, this is not a thing that we ship without. This is a, like, if we don't have this, we don't ship kind of concern. And that shows. It shows in the examples, it shows in the way people talk about it. And as Amberley said, it shows in the results. 

[00:17:35] And I think that, you know, it's a good reminder to people who are in positions of leadership. If you run a framework, if you run a community, the things that you put an emphasis on are the things that your community will put an emphasis on. And so, you know, you have a lot of control, whether or not you want to admit that's a thing.

[00:17:52] If you're out there running a framework, if you're not putting accessibility top of mind, you're actively breaking your community. And that's a, that's an important thing to keep there. 

[00:18:01] Leslie: [00:18:01] Amen. It's almost like this is about humans at the core, right? It's almost like people are who we're developing things for and not just software and code for the sake of it. Right? Imagine that. 

[00:18:12] Hugues: [00:18:12] And I think we all know that a lot of people will just copy-paste your example from your docs without reading. 

[00:18:19] Phil: [00:18:19] Not my example. They never copy and paste my example. [Laughter] 

[00:18:24] Hugues: [00:18:24] So if these examples are not accessible, then you just like, keep the problem forever. Think it goes even in like Stack Overflow's answers, whatever you write code. If these are not accessible, then you just like continue the problem I think. 

[00:18:41] Leslie: [00:18:41] The other thing is that, that sometimes that line between what's accessible and what's not can be really murky. Right? Where it's like, am I meeting that standard? Is what I just built - like I used Semantic markup, but maybe I didn't pay attention to my focus order or something. Right? But that can be hard to judge. 

[00:18:55] My kind of piece of this is anything is better than nothing, right? So it doesn't have to be perfect to put out an accessible example, do the best you can, and then learn from it as people, hopefully, help guide you and give you feedback on it.

[00:19:08] Hugues: [00:19:08] As long as you're trying, I think you're already better than half of the websites. 

[00:19:13] Jason: [00:19:13] And something that I keep seeing repeated over and over by accessibility specialists is like, the best way to be accessible is to just write markup. Like stop reinventing controls and components. If you are making an input, use an input. If you're making a button, use a button. And that gives you so much default accessibility because so much effort has gone in to making markup accessible. So instead of creating a div and adding the click handler and then trying to deal with focus states, like don't do that. Just use a button. 

[00:19:44] I see Amberley making a face. So I'm going to let you speak to that. [Laughter]

[00:19:51] Amberley: [00:19:51] For context, I don't hide anything on my face. I am wildly aware of that fact. 

[00:20:00] Cassidy: [00:20:00] It's a blessing and a curse. 

[00:20:01] Amberley: [00:20:01] I was getting, I was getting very excited because that tied back to something that was relevant to what we were talking about a couple of minutes ago that I didn't quite get to, which is two points. One, one of the legitimate pieces of that concern, I think, about JavaScript frameworks is that they do make it so much easier to lean on scripting instead of on the markup and structure that we have available to us. 

[00:20:27] So it's not that the tool, again, it's not that there's something wrong with the tool itself. It's the way you build the tools. So you have to be intentional about not leaning towards scripting when you don't need it. 

[00:20:39]But then also the other piece of what you said that I think is interesting is there's sort of a whole new world of almost accepted primitives that has developed in web design in terms of these accordions and sort of all these other things that don't have associated HTML standard primitives associated with them. So in some ways the standard web hasn't evolved with web developers to the point where there are reasons why people do have to keep rebuilding some of the stuff that they're trying to rebuild.

[00:21:10] Obviously, if something's a button, you should just code it as a button. There are things like that exists and you should lean on. But there's also the way the web has evolved in our interaction patterns that I do wonder, you know, what happens with evolving HTML and evolving these new patterns so that people don't have to keep reinventing certain things. 

[00:21:28] Leslie: [00:21:28] I love that. Right? It's the document object model for a reason because it was built for documents. Right? But now we're using browsers for apps and interactive experiences. And so I think, you know, obviously the folks working on the spec are doing great work and moving things forward, but there's always more work to be done, I think, to kind of fill those gaps. 

[00:21:45] And with the CAG, web content accessibility guidelines, as well. Right? They're like always, not a little bit behind, but we sometimes move faster in how we're kind of developing new patterns in what we're trying to do in the browsers and the guidelines sometimes have to kind of catch up. So we've got to be at the forefront of that as the developers and not always rely on the guidelines to tell us exactly how to do it.

[00:22:06] Cassidy: [00:22:06] Are there any projects that you all like that are accessibility focused that help you not reinvent the wheel? The one that comes to mind for me is Reach UI. That one is so nice for just drop-downs and they have, they have really large state machines just for figuring out if someone clicks and moves things away and stuff. And I thought that one was really impressive, but I'm sure there's ones that I don't know about. 

[00:22:27] Amberley: [00:22:27] So Reach UI is the one that I would point to also, and in previous projects, we've used Reach UI components as a base to then build component libraries off of. And that's a great example of sort of, building out a centralized pattern that someone has to put energy and attention and thoughtfulness into analyzing and testing and sort of leveraging on top of that. 

[00:22:51] To me, that's sort of exactly what I'm thinking of when I say it's a button, take advantage of a button. It was designed - everything underlying an HTML button is designed that way for a reason.

[00:23:01] Similarly, there are people trying to answer that call, seeing this need for these new web primitives to be built and putting them out there, like the Reach UI library for people to build on top of. 

[00:23:13] Jason: [00:23:13] And I think that's what, like, that's what we want the JavaScript community to be. Right? What I think is really inspiring about JavaScript over the last five years or so is with the prevalence of Babbel, we kind of created this ability to test new specs in the wild before they become permanent so that we can see what happens when somebody uses it like this? What problems arise? What do people run into? So that we don't hit this problem. 

[00:23:39] Like, when you put something into the web spec, you can't break it. Like, we've seen what happens, you know, I don't know if anybody remembers like array.smoosh, but like, this is, this is all stuff that like, we have to be really careful because if somebody builds something for the web, we have to support it forever. Or else we risk so much, you know, so much breaking and loss of history because we accidentally broke tens of thousands or millions of websites.

[00:24:05] So I love the idea of letting JavaScript be the place where we prove these ideas out. And I think that Reach is a good example of being thoughtful about this. How do we create primitives that Reach can provide, that we can build on and test, and we point out what's working and what's not. And then once we've got something that consistently works for the 90 percentile use cases, then we pull that into the browser because we know it's going to work.

[00:24:29] And I find that really encouraging, and I wish that was more of the model around everything and not just like, look at this new cool JavaScript feature. I want to use optional training today so I'm going to turn on Babbel stage three. It's like, no, let's use it for all of this stuff because that's what it's so good at.

[00:24:47] Leslie: [00:24:47] I love that. I also have to give a shout out to Heydon Pickering who I feel like has done a lot of work around inclusive components and published that work and kept a blog. And that was some of the earliest stuff that I was looking at when I was trying to figure out how does all this stuff work? Because Reach is also amazing, but it's a little bit newer and so looking back even further, people who were putting up blog posts and examples, and working through some of this stuff in public is, has been super valuable for me. 

[00:25:08] Hugues: [00:25:08] I wanted to do that exact shout out I think. It, the inclusive components, what I really like is there's like a lot of educational stuff that you can learn also. So it's not like, oh, you want to do a toggle button? Here's the code and the here's how to import it. It's like, it goes through this is the problem, this is how we can tackle it, this is like the different state it should have. 

[00:25:33] So it kind of also educates you on how and why these decisions are made so that you can make also better decisions in the future for your own components. I think inclusive components. It's really awesome resource. 

[00:25:45] Leslie: [00:25:45] There are also trade-offs. Right? There's not always like one perfect way to do it. And I love that's, Heydon covers that, but there are other folks writing about this too, who are like, okay, well you could make this tab component accessible in one of three ways, or here, you know, some examples of how I've done it.

[00:25:59] And sometimes depending on your use case, you might need to choose one over another. Right? But being aware of kind of what's out there helps make that choice. 

[00:26:06] Cassidy: [00:26:06] I think what you said and what you said earlier when you, I think it was you Leslie, but we've kind of all touched on it. It's good to at least try to start something. And then even if it's a little bit, it's better than a lot of things and knowing that there's so many options out there and that there's, it's hard to mess this kind of thing up. And so as long as you try, it's a good thing. 

[00:26:28] 'Cause a lot of times I've seen so many people where they're just, like, I want to use like this ARIA label thing, but I don't want to mess it up and then like ruin someone's experience. But just trying it I think is worth it. And you're not gonna make it any worse by just trying it if it's not accessible at all in the first place. 

[00:26:47] Hugues: [00:26:47] Sorry, I think that's a really good way to learn. Right? So the way I learned at least was like, all right, this site, I need to do a schedule. Like it's an event site. So I'm going to do the schedule. Like I'm going to go learn on what should be the markup and everything. So now you know how to do schedule. Next time you, it can be cards, right? Because cards components come back all the time. 

[00:27:10] So now you know how to do schedule, you know how to do cards. And then the next one can be, I don't know, sliders or whatever. But then after your five, six, seventh site, then you have like really good baggage of how to make all these components. So I think that's a really good way to, to type it. 

[00:27:28] Leslie: [00:27:28] It's important to educate yourself as you go too, right? Like I really do believe anything is better than nothing. On the flip side, too much ARIA can be really challenging for people to use. Right? If you put ARIA in too many places or in the wrong places, potentially, you could be creating an experience that's really still, maybe it's overly accessible? Or is really frustrating for someone to navigate around because then they're waiting for all these labels to be read out. Or I already had the context from the semantic element you used, you didn't need to add an ARIA label on top of it. 

[00:27:54] So it's one of those things that's like, yes, anything is better than nothing, but also make sure you're learning as you go. And my rule with ARIA in particular is like, it's sort of the Fight Club rule. Like try not to use ARIA in general. And if you need it, like, ask yourself why? Just double check yourself there. Try to rely as much as you can on kind of the primitives and semantics first. 

[00:28:22] Phil: [00:28:22] Those weren't the Fight Club rules! [Laughter] They repeated the Fight Club rules and you still botched it. 

[00:28:26] Leslie: [00:28:26] I did, I did. The first rule of Fight Club is you don't talk about Fight Club, so I guess don't talk about ARIA? I don't know.  

[00:28:32]Amberley: [00:28:32] Don't use ARIA unless you have a compelling reason to use ARIA. Now, I was just going to, I was just going to back up that point, Leslie, with, you know, trying any time to tie back to something concrete.

[00:28:45] I think this is also from the WebAim reports, but there's actually a correlation between higher usage of ARIA and higher incidents, instances of accessibility errors. So a lot of times when you're trying to like throw the kitchen sink at something, you can actually make it worse. So intentionality around ARIA is important.

[00:29:10] Jason: [00:29:10] So I want to, I feel like at this point I'm gonna make an assumption that you, our dear listener, are now super excited to go out and start making these changes. Right? And so for someone who is really excited about this, I know that there are some tools that can automate this, that can send some checks, that can do some things. So if somebody wants to get started, what should they look into adding to their projects today? 

[00:29:32] Hugues: [00:29:32] If you want to start, I wouldn't lean on automatic stuff to be honest. I think automatic stuff can catch some errors, but I think there's a lot of errors that they can't catch. So I would start manually by reading articles about accessibility, about what you want to build. And also reading about how to do testing with voiceovers or another screen reader. Start to do manual stuff and then you can compliment with the automatic tooling after. 

[00:30:04] Jason: [00:30:04] So, so you would recommend not using the automatic stuff until you've done the manual? Or like will the automatic stuff catch more than you would catch on your own? 

[00:30:14] Hugues: [00:30:14] I think the problem with the automatic stuff is it can give you like a false positive that the website is accessible. Like you use the tool, a hundred percent, all right, my job is done. Onto the next thing. And then if you start manually testing, you realize that there's like tons and tons of issues. 

[00:30:33] So I would, personally, get comfortable with like manually testing and, I think, automatic testing for like font sizes, color contrast issues. There's a lot of things that it can catch super easily. But it's never going to beat manual testing. So I would, I would try to learn how to do manual testing before relying on automatic tool. 

[00:30:57] Jason: [00:30:57] Okay. 

[00:30:57] Phil: [00:30:57] That seems to back up that kind of point that's come up a few times that, that word "intentional." It feels like being very targeted and being very intentional about what you're, what you're trying to do and building an understanding of how you can improve things by, you know, taking certain actions. That seems to be a result of, you know, that kind of manual focus and digging in, rather than hoping you can point a tool at it. And then ta-da! You know, you crank that handle and then it's magically accessible.

[00:31:24] Leslie: [00:31:24] It's all user experience. Right? And I think accessibility is the same way that having, again, I am not a screen reader user myself, so I don't know exactly what that's like day in, day out. So I can't purport to say that's my experience, but using a screen reader or using some of these assistive technology devices allows me some understanding of what that user experience is like.

[00:31:44] You know, I use apps all the time visually with my mouse and so I know what that user experience feels like. Actually, you trying out a screen reader or trying out some of these, the actual assistive technology devices, gives me a better sense of what that user experience is like, which allows me to fix the errors better, to understand why I'm coding the way I am. 

[00:32:00] Why did I use that semantic element instead of that one? Why do I need ARIA here? Understanding the why is a lot easier, I think, when you're actually testing them out yourself and trying to tap through, you know, to see where the focus goes. 

[00:32:11] You kind of experience it firsthand as opposed to just seeing an error and saying, oh, I'm going to go fix the error. Right? Which can help once you're kind of further along in your accessibility journey. 

[00:32:20] Amberley: [00:32:20] Well, I've done a lot of thinking about how people can get started in accessibility. And like you said, okay, you're starting from the point of, I understand why this is important. I have a general understanding. I'm bought-in. Where do I go?

[00:32:33]I actually wrote a resource site along this progression where you start with this is why you should buy in, this is why you should care. Quick wins - for, here are the six most commonly reported accessibility errors caught by automated testing tools. And then how do you start testing? Right?

[00:32:52] And so going into that if anyone's familiar with Madeline Parker, Madeline has this really wonderful sort of metaphor that she's developed for accessibility testing, specifically, around coffee which is like, if anyone here is a coffee fan, if you think of something like a French press, you know, it's coarse grind, you use it, you'll end up sort of with more grinds in your coffee. And it's better than nothing, but it's not necessarily the smoothest experience. That would be something like automated testing where the numbers vary, but generally what I see for automated testing is it's something like 30 to 40% of accessibility errors can be caught by automated testing.

[00:33:31] So nodding back to what Hugues was saying about it can give this false sense of security if you run an axe Audit or a Lighthouse audit and you get a hundred or you get no errors, you can feel confident-ish about 30% of your experience. Like that doesn't mean that you're done. But it does give you a strong sort of like beginning. 

[00:33:51] But then as you sort of go along that spectrum of - like Lighthouse, I think, would be one of the examples of the most top-level introductions where it doesn't get super deep into the errors, it doesn't have a strong interface for you to really dig in, but it's a great start. And then along the spectrum to something like axe, which will surface more detail and more errors. And then all the way to something like live user usability testing. 

[00:34:20]So I think moving along that spectrum, you'll learn a lot as you progress through those different types of testing, but keeping in mind that any one particular type of testing is not going to be a sort of a catch-all or a solution for everything is important. 

[00:34:39] Jason: [00:34:39] Well, I mean, I feel like we could continue talking about this for days and days, but in the interest of time, we're going to move into Tara's favorite section - Tidbits and Thought Things. 

[00:34:50] All: [00:34:50] Yay! 

[00:34:51] Jason: [00:34:51] So we're going to ask a rapid-fire question of everybody in the room, and today's question is what's one thing in your house that you wish you could click your fingers - snap your fingers is, I think, the phrase - and change the accessibility of? 

[00:35:03] Phil: [00:35:03] I mean, if you want to make this inclusive so that the Brits can understand it, click your fingers means snap your fingers.  

[00:35:08] Jason: [00:35:08] Snap is American, click is British? 

[00:35:11] Cassidy: [00:35:11] You say click? 

[00:35:11] Phil: [00:35:11] Yeah, click. Like this. Snapping is crunching and breaking a thing. 

[00:35:16] Cassidy: [00:35:16] I don't know if I believe you. 

[00:35:17] Leslie: [00:35:17] Does that mean in Avengers that Thanos clicked his fingers? Is that the thing? The click heard round the world?  

[00:35:23] Phil: [00:35:23] It was a bit of a scat, jazz version.

[00:35:28] Leslie: [00:35:28] That's amazing. 

[00:35:29] Jason: [00:35:29] All right. Focus up everybody. Cassidy, what is one thing that you would snap your fingers, click your fingers and change the accessibility of in your house? 

[00:35:36] Cassidy: [00:35:36] My humidifier. It's such a pain to refill that thing because you got to like take it off of the base, refill it, and then like do the whole upside down flip thing. It's a pain in the butt. I would change the accessibility of that and make it easier to refill and to just use. I'm sure there's advances in this technology out there, but every humidifier I've had has been such a pain to refill. 

[00:36:00] Phil: [00:36:00] You had that loaded up. 

[00:36:01] Cassidy: [00:36:01] I was ready as soon as I saw this question. [Laughter]

[00:36:07] Phil: [00:36:07] Who's next? Amberly? Do you have one? 

[00:36:10] Amberley: [00:36:10] I'm a very pragmatic person. And I feel like I have a very pragmatic and not-creative answer to this, but my house was built in the sixties. So what I always think about, especially for like aging in place, if I live here for a long time or resale for someone who may have mobility issues or buying the house later would be like, my house is older. So narrow doorways, narrow hallways, narrow ways to get around. Widening hallways and widening doorways, sort of making it easier for anyone to get around. 

[00:36:45] And steps. Steps is also a huge thing with entries into the house and stuff like that. So very pragmatic answer. But that is what I would do. 

[00:36:53] Cassidy: [00:36:53] That's real. All those old houses have so many, just like, we're going to step down into the living room for no reason. Like, they did a lot of that. 

[00:37:00] Leslie: [00:37:00] That's like my seventies sunken living room. Yes. It doesn't work with a Roomba. Really problematic with a Roomba. Not a fan. 

[00:37:08]Hugues: [00:37:08] They didn't think of the Roomba in the seventies. 

[00:37:10] Amberley: [00:37:10] Think of the Roomba! 

[00:37:11] Cassidy: [00:37:11] Come on.

[00:37:12] Phil: [00:37:12] Think of the Roomba, people, come on. There's the real victim here. 

[00:37:17] Leslie, how about yourself? 

[00:37:19] Leslie: [00:37:19] So I've got a nice little backyard with a nice little fence and there's a gate in the fence, but the gate only has a latch from the inside. So there's no way, I mean, for safety reasons, I guess it's very smart because no one can just come into my backyard. But this is a little bit problematic when people come to, I don't know, mow my yard. Or in non-COVID times, if I were to have friends come over and I wanted them to meet me in the backyard.

[00:37:40]So it'd be really nice to have a, snap my fingers not have to go through the effort of figuring out how to like, get the lock on the other side and then figure out how to lock it. Not great.  

[00:37:50] Phil: [00:37:50] Makes sense. Yep. 

[00:37:53] Who's next? Me? 

[00:37:55] Jason: [00:37:55] You are. 

[00:37:56] Phil: [00:37:56] Okay. So mine isn't in my house. So sorry, I'm probably bending the rules a bit. 

[00:38:01] Cassidy: [00:38:01] This sounds like cheating already.  

[00:38:01] Jason: [00:38:01] You're immediately disqualified. Moving on. 

[00:38:03] Phil: [00:38:03] It's in my car. It's in my car. Because I'm really, I was really excited to get a car that had a radio that has like CarPlay on it. You know, where it kind of picks up the controls from your phone. But it means that the screen for the controls for the radio are a big kind of glass panel. So big touch screen, and that's really flexible and really cool. And it's great if you're in the passenger seat and the car isn't moving, but if the car is moving and it's bumping around and if you're driving, having no physical feedback, when you reach out to touch control. 

[00:38:34] I don't know how I'm still alive, if I'm honest. The number of times I was trying to just press a giant button that's big on the screen, but I can't reach out and just feel it. And I'm just like hunting around. Not great. 

[00:38:46] Leslie: [00:38:46] So what town are you in? Everyone there stay off the road.

[00:38:52] Phil: [00:38:52] I'll stay put. 

[00:38:53] Amberley: [00:38:53] Having been rear-ended by a guy who was fumbling with the radio, I'm firmly on your side with this. 

[00:39:00] Cassidy: [00:39:00] It was Phil! 

[00:39:01] Phil: [00:39:01] I mean, the fact that I'm - 

[00:39:04] Cassidy: [00:39:04] It was Phil! 

[00:39:07] Phil: [00:39:07] If anyone from my insurance company is listening, I'm sure they are, that wasn't me. Please don't make my premium go up. 

[00:39:13] Amberley: [00:39:13] Where were you in the summer of 2018? 

[00:39:18] Phil: [00:39:18] I don't know. It was a rainy one here. It wasn't '98. [Laughter] 

[00:39:24] Cassidy: [00:39:24] Callback!

[00:39:24] Phil: [00:39:24] Hugues, how about you? 

[00:39:25]Hugues: [00:39:25] I'm going to go with the appliance route also. But I'm going to go with my washing machine. I don't know why there's twenty-five settings. I just want, it should be one button, wash my clothes - and maybe wash my clothes. Maybe like water temperature. But other than that, like, I don't know why it's so complicated.

[00:39:46] Jason: [00:39:46] I'm actually going to go the other way with it because I have a whole bunch of, like, small electronics in my house that tried to simplify their interfaces by having one button that does seventeen things. And so if I press it once it does one thing. If I hold it, it does another thing. If I tap it three times, it does a third thing. And I have no idea how any of these things operate.

[00:40:08] So I'm constantly breaking my settings and then I have to go to the internet to look at their, their docs to figure out how it works. And I'm like running a stopwatch to know how many seconds I need to hold this button for it to get to the right mode. It's - come on. That is not a usable device. 

[00:40:22] Cassidy: [00:40:22] Speaking of humidifiers and those kinds of things, I have this desktop humidifier and you press the nose.

[00:40:28] Phil: [00:40:28] What is that? 

[00:40:32] Jason: [00:40:32] In order to continue talking about this we have to describe it. Cassidy is currently holding up to the camera what looks to be a tiny little Kawaii cat with a propeller coming out of its head. 

[00:40:44] Leslie: [00:40:44] And it's a humidifier. 

[00:40:45] Jason: [00:40:45] Please continue. 

[00:40:45] Leslie: [00:40:45] It's cute. 

[00:40:46] Cassidy: [00:40:46] It's cute. It's a pain because for the same reasons Jason said. You press the nose to turn it on, but depending on how long you press the nose, it changes things. So for example, if I press it for like three seconds, the face lights up. I don't need my humidifier to light up. And then if I press it for a few seconds the fan will go on. And then if I tap it, it's like spurts of water versus a steady stream. This is a very confusing humidifier. And it's a pain to refill! 

[00:41:24] Jason: [00:41:24] All right. I think we need to, we need to go ahead and call this one before we go into a humidifier review hour.

[00:41:32] Amberley: [00:41:32] Before Cassidy finds anymore humidifiers. [Laughter] 

[00:41:35] Jason: [00:41:35] All right, everybody. That's going to do it for us this week. We are so excited for having you here with us. Join us next time, where we are going to talk about the Jamstack Can Do That: Theee Fuuuturrrrre.

[00:41:47] Phil: [00:41:47] Is that a Halloween episode? Is that a Halloween episode you were just trying...? 

[00:41:54] Jason: [00:41:54] Is that not how - what's the future thing? Like we might need Chris's help for this. Do some big, like reverb in space. Like [echoing] the future! 

[00:42:03] Cassidy: [00:42:03] I just kind of think of Squidward and SpongeBob going like "Futuuuure," while doing crunches on the ground. [Laughter]

[00:42:11] Jason: [00:42:11] All right. So you'll just have to tune in next time to figure out what the heck that's all about. Thanks for joining us. I've been, Jason always-take-some-dishes-while-I'm-walking-down-the-stairs Lengstorf. 

[00:42:24] Amberley: [00:42:24] I'm Amberly can-usually-find-that-where-you're-looking-for Romo. 

[00:42:29] Cassidy: [00:42:29] I'm Cassidy will-always-offer-you-part-of-my-snack Williams. 

[00:42:34] Hugues: [00:42:34] I'm Hugues I'll-always-make-breakfast Tenue. 

[00:42:36]Leslie: [00:42:36] I'm Leslie writes all-the-notes Conewhy. 

[00:42:39] Phil: [00:42:39] And I'm Phil I-well-actually-people-who-misremember-the-rules-of-Fight-Club Hawksworth.

[00:42:44] Amberley: [00:42:44] [Laughter] I love that we started this episode calling out Leslie, and we're ending this episode calling out Leslie. 

[00:42:54] Cassidy: [00:42:54] Full circle. 

[00:42:55] Jason: [00:42:55] [Outro music fades in softly] Just to put a bow on it, Phil, one more time before we leave, can you talk about what A11Y is? 

[00:43:04] Phil: [00:43:04] That is a numeronym. A numeronym. 

[00:43:10] Cassidy: [00:43:10] Wow. 

[00:43:11] Jason: [00:43:11] Thanks everybody. This has been Remotely Interesting. We'll see you next time. 

[00:43:17] Phil: [00:43:17] See you next time. Bye. Bye. Bye

[00:43:24] Music: [00:43:24] [Outro music] 

[00:43:31] Why is that so hard?

[00:43:37] It was the worst day, by the way, I think it was 

[00:43:39] Leslie: [00:43:39] the worst. Definitely. 

[00:43:42] Amberley: [00:43:42] What, a way to kick off insulting your guests. 

[00:43:47] Cassidy: [00:43:47] , that's what it's 

[00:43:48] Leslie: [00:43:48] all about here. 

[00:43:50] Phil: [00:43:50] This is just for Chris is a joy at the moment.