 Hello everyone and welcome back to the State of the Web. My guest is Marcy Sutton, head of learning at Gatsby and former developer advocate at DQ Systems. And today we're talking about web accessibility. Let's get started. So Marcy, thanks for being here. What exactly does accessibility mean? To me it means building websites that include people with disabilities, both building for people with disabilities and with people with disabilities, including them as stakeholders, hiring them to work on their teams, paying them for their work to review things for accessibility and give us feedback along the way. So when a website isn't accessible, what's at stake? A lot. If you think about how many services are moving online, if accessibility isn't built in then it could present barriers for people with disabilities where they can't use the service, they might give up and leave, or worse it might cause harm to them if they have something like a traumatic brain injury or seizure risk. So there's actually quite a bit at stake if the Web isn't accessible. So even with the Domino's lawsuit recently that came out where they lost their appeal, do you think that websites will actually have a push towards more accessible websites, especially now that lawyers realize the legal risk? In the United States legislation can certainly help and people can lean on the law in this country to enforce their civil rights. So having rulings like the Domino's ruling could potentially help since there has been an absence of rulings in favor of including websites under the Americans with Disabilities Act. But I think there will be more to watch in that space. I have seen and read and heard about companies looking at competitors that have been sued and sort of feeling like, oh, maybe we're next. So there can be some market pressure if there are legal actions being taken. And if that's what it takes to make something accessible, then I think that's moving in the right direction. Where do the breakdowns typically happen when a website becomes accessible or inaccessible? Are the managers just not buying into it? Are the developers unaware of the importance of it? Lack of developer tools? All of the above? I think it's mostly an education issue and awareness. So to sort of try and solve this problem, I advocate building a culture around accessibility so that everyone at the company is involved and invested from project managers to designers and developers. We all have a part to play in making the web more accessible. And it is true that a lot of people just aren't aware of the impact that they could have. There's also the misconceptions that accessibility is costly and maybe not worth it. It's too niche of an audience. But actually it can improve things for a lot of people. If you think of it in terms of inclusive design, the benefits that we put into our websites like keyboard support, improving contrast, and font size, those can help a lot of people. So it's definitely worth it. And it's easier and less costly if you do it from the beginning. Is it something 10% of the population has some form of disability? So it's more than niche. It actually affects a lot of people. I think it's more than that actually, one in five people. And the range of disabilities is pretty wide. So there's all kinds of scenarios that people can be browsing your website and they might have situational or temporary disabilities. People are born with disabilities and there's a whole spectrum of how people use the web. That's really kind of beautiful. And if we can embrace that like we did with responsive design and letting go of some of that control over pixel perfection and how the user actually visits our website, there's some real opportunities there to innovate and make things that are way more robust. What did you mean by situational disability? If you break your arm, if you have a baby in one arm or a cup of tea or coffee, you might hold your phone in a different way or have to switch arms. If you are born with something like that, you might permanently not be able to use your arms. And so you have to use other input modalities like voice or maybe you use a joystick with your mouth or something. And so there's new devices and ways of navigating that don't rely on the default of perfectly working limbs and the abilities that most people think of. So there are some opportunities and people are pretty resilient. They figure out ways to navigate the web and if we can support them better, then that's pretty awesome. That reminds me of like Android Auto, whereas if I'm driving my car, my phone is not necessarily the thing I'm putting right directly in my face. So the way of interfacing with devices changes entirely depending on your situation. Yes. Some of those technologies were developed for people with disabilities. So it's worth considering that maybe some of the things that we appreciate and we can use every day were invented for people who needed it. I want to go back to something that you mentioned earlier about having users with disabilities or even people with disabilities on your team as part of the development process. How can you implement accessibility as part of the process in a way that ensures that the website is going to be accessible? Well, certainly including people on your teams to be stakeholders and provide feedback in regular intervals. That would be the best way is to have people embedded on your teams who have disabilities, mainly because they have experiences and perspectives that as able body developers, we just can't make that up. It's not your lived experience. So having that feedback all the time would be truly valuable and people get to work on your teams and you pay them for their work and I think that's a really good way to go. How about part of the design process? If a website, for example, is built to be entirely using like Canvas or like Flash or something, if people have a specific technology in mind where it's just never going to be accessible, how can you actually prevent that from happening? Where in the design process do you actually make those decisions to be accessible? I think having some requirements about how users should be able to navigate the site should definitely start and design. I mean, hopefully you're not getting too locked down on a given technology in the design phase. Yeah, Flash, no way, but Canvas, there have been whole websites built with Canvas and accessibility, unfortunately, wasn't afterthought in a lot of those cases. We do have some standards for Canvas that are better than they were four years ago, but you still have to reimplement a lot of native functionality that you would get for free if you used the DOM or the document object model. According to the accessibility object model? No, so with Canvas, if you provide fallback content, there's a method called draw focus if needed. You can pass off some of these interactions from the two-dimensional Canvas, which is essentially a bitmap to that fallback content and try to create some sort of a semantic experience, but that's a lot of work. If you can use the document object model, which does feed into what's called the accessibility tree, which is a fancy term for a structure with accessibility information, you can do a lot and communicate to users of assistive technology what's going on on the screen. What's the current state of accessibility and developer tools, either in the browser as part of testing? Pretty great, actually. From when I got started as a front-end developer, everything for accessibility in terms of this accessibility tree that I mentioned, all of that information was sort of hidden under the hood and you had to go crawl through the DOM and go look at what was on the page and sort of just know what was going on there. And now we have developer tools like in Chrome and in Firefox. And it's amazing how much you can learn about accessibility through those tools. It would be great to have more, but we've come a really long way, both with built-in DevTools and browser extensions and automated tools. So I think the future is pretty bright in terms of tooling. What was your experience with Axcore and what did it do? Axcore is an accessibility API written with JavaScript. It's an open source library that I used to work on full time. And it's used in both Lighthouse and Accessibility Insights from Microsoft. So it's sort of an engine and a common rule set for testing accessibility. And it's used a lot of places, it's pretty cool. There's other APIs as well like Wave and some others that aren't coming to mind at the moment. But it's nice to have a common set of rules and the engine that people can count on. And they can use it in different ways such as in browser extensions and in automated tooling to use a common rule set. So that some testers on your team aren't using a different set of rules than the developers, for example. Because then you're working off two different sets of requirements and it can be hard to meet in the middle. You had mentioned that Axcore is integrated with Lighthouse. The HHB Archive runs Lighthouse on like five million websites. So we can get some of that analysis from Axcore aggregated to the scale of the web. I actually have a few stats. So 22% of web pages tested past the color contrast audit from Axcore. 50% of pages are passing the Lighthouse image alt attribute being present audit. So it's kind of surprising to see how low accessibility adoption is in certain areas of the web and having a tool like Axcore is just really great to be able to get that visibility. Sadly, it's actually better than I expected. That is pretty sad. It is sad. Yeah, it's depressing. There's a project from WebAIM called the WebAIM Million where they ran the Wave automated tool against the top one million homepages. And that was also a very sad set of results because as an industry, we have a lot more work to do, a lot of work to do to make that better. Tools are helpful in highlighting some of these low hanging fruit things that we need to fix. But if we look at it in aggregate, the picture is not very pretty at the moment. You co-authored Smashing Book 6 with your chapter titled Accessibility in Times of Single Page Apps. So in what ways do accessibility and single page apps not play well together? Quite a few, unfortunately. I mean, all of the basics of accessibility apply if you're building a website that's heavy with JavaScript. So things like image, alt text and color contrast. But when we have this JavaScript layer that's taking over a lot of the interactions that would be happening in a web browser, we have to do a bit more to support users who are navigating with assistive technology and using the keyboard. Things like focus management, making announcements, using unobtrusive motion if we're using a lot of JavaScript to try and delight users. We have to try not to cause harm with those. But I'd say probably the focus management piece is the biggest thing that we have to handle, because if the browser is not refreshing the page when the page changes, the user using a keyboard might be stuck in the tryer part of the screen or they have no idea what happened if they're in a screen reader or something. So we have to manage their experience going through the application. And that can be pretty cool actually. I think it's another area that we can innovate. And I'm hoping that frameworks and potentially browsers could help make this easier. So that would be a good space to try and move the needle a bit to support developers without them all having to reimplement all of the same things. Even kind of more of an old school UI component like modal dialogues has its own focus problems. Describe some of the accessibility issues with modal dialogues and what's being done on the HTML standard side to fix that. Sure. Yeah. So modal dialogues are an example of some of these same things I was talking about with focus management. So you have a layer that opens up over the screen. It probably has content behind it, maybe a screen curtain to gray it out. When that modal opens, you have to send focus into it. So the keyboard user or screen reader user is in the right part of the page. They're not left behind the modal window. So that means that you also need to disable any interactive content behind that modal window. And that part can get pretty tricky. You have to do some DOM walking, potentially set already a hidden and tab index on interactive controls. And most people are not going to do that DOM walking. It's hard. It's expensive, performance-wise. And you have to do it every time the modal opens, walk it down. And it's like you're doing it in inverse, both directions. So what would be great is in the standard space if we could have something like HTML inert. It's an attribute that was proposed a while back. I think it was at risk of being removed and nobody is convinced that we really need it. This is me officially saying yes, we need it. Because the alternative is a lot of DOM walking that, frankly, very little people are going to do. So what that would do for us is make it a lot easier to set a Boolean attribute in HTML to effectively disable whole subtrees of the HTML DOM. And that way, when we send focus into a modal, we don't have to do as much in the background. It helps to have sibling elements. So maybe the modal and the content behind it are siblings. That way you can just turn off all the other content. So that does take a bit of work from the developer to structure their DOM that way. But that attribute would solve a whole lot of pain, as well as the dialogue element in HTML. That's another one that's at risk of being removed. I think it's Firefox at this point that we need to implement dialogue. That could give us some of this behavior for free, like focus management, having a semantic HTML element that would tell users of assistive technology that it is a dialogue. So there's some patterns here that to have every developer in the world have to re-implement the same things over and over again seems like we should have some more primitives for making that easier. Yeah, that sounds super important. And complicated. Evapocating in the past for something called an accessibility statement. What is that, and why is that so good for accessibility? Accessibility statements are great tools, no matter what kind of a website you're making, whether it's with heavy JavaScript or not. So an accessibility statement is generally a page on your website that's easy to find. Maybe it's linked in your website footer. And it has things like what you're doing to improve accessibility, maybe what level of the web content accessibility guidelines that you're aiming for. It's nice to have that goal and that target, whether or not you've actually met it, but you have to keep actively working at that to improve. You can also collect any accessibility tips or information about keyboard shortcuts or ways to use your website for accessibility and ways for users to contact you. That's one of the most important pieces. Having an affirmative statement that says, hey, we might not be perfect at this, but we'd love your feedback and get in touch with us. And if people do, act on that feedback. So it's opening that conversation to bring people in and make them feel included and give them a way to give you feedback. Because a lot of these websites that have glaring accessibility issues, we have no way to contact them. So you might see some tweets of people calling out companies because they can't use the website or the service. Maybe an update to the website or application breaks what used to work. So if you have that statement, it gives people a way to contact you in an official channel so that you can act on that feedback. It must be really reassuring to go to a website and see that they actually care about accessibility. Absolutely. So what resources would you recommend for people, web developers who want to learn more about creating accessible websites? So many. The A11Y project is really great. There's an accessibility course from Alice Boxhall and Rob Dodson at Google on Udacity. I have a page on my website. It's marcisetten.com. There's a web accessibility resources guide there. And I collect things like books and tools and articles and things that I refer to a lot. There's quite a bit out there from companies like WebAIM. They have really great articles. DQ, my former employer has a thing called DQ University. They offer free accessibility training to people with disabilities, which is really great. So there's definitely a wealth of information out there. Just getting it to the people to solve this education problem is sort of the gap that we need to figure out. And how about NoMouse Mondays or what do you call it? Yes, I released an NPM package this week to sort of put a tool in the hands of developers to turn off the mouse cursor for everyone. It was sort of a joke, but actually could be useful as a dev tool. So something to pull into your project maybe one day a week to actually have a NoMouse day of the week. That reminds me of 2G Tuesdays or something to get the feel for slow performance. I think that's a good idea. Yeah, sort of a chaos monkey approach to things of like, if you unplug your mouse or don't have that capability, how resilient is your design? Can you actually use it? And some of the most glaring accessibility challenges I see are with color contrast and lack of keyboard access. So if we could somehow culturally build in tools and processes to get us thinking about that, that would help. So the NoMouse Mondays, the first experimental version, but I have plans for it, so. That's a good idea. All right, Marcy, this has been great. Thanks for coming on the show. Thank you so much for having me. You can check out links to everything we talked about in the description below. Thanks for watching and we'll see you next time.