Fullstack Accessibility with Ben Myers

Episode Description

Web accessibility advocate Ben Myers discusses designing for disability, testing with screen readers, and building inclusive processes for full stack developers.

Episode Summary

In this episode, web developer and accessibility advocate Ben Myers joins Anthony Campolo and Christopher Burns to explore how full stack developers can build more accessible websites. The conversation begins with Ben's background, his inspiration from Jason Lengstorf's Learn With Jason show, and his own Twitch stream called Semantics. The discussion quickly moves into the core argument that inaccessible websites are products of broken processes, not just technical failures, meaning accessibility must be embedded in design, requirements, and testing rather than treated as a post-development checkbox. Ben walks through practical considerations like color contrast, placeholder pitfalls, keyboard navigation, and focus management, illustrating how different categories of disability interact with the web in distinct ways. The group explores the relationship between operating systems, browsers, and websites in delivering accessible experiences, with Ben emphasizing that developers hold the most control. Testing strategies are covered in depth, from manual keyboard and screen reader testing to automated tools like axe DevTools and Lighthouse, with Ben noting that automation catches roughly 57% of defects while contextual problems still require human judgment. The episode also addresses accessibility overlays, design systems like GOV.UK, and the curb cut effect, ultimately reinforcing that accessibility is good design and that beautiful websites can absolutely be accessible.

Chapters

00:00:00 - Introductions and Background

Ben Myers introduces himself as a web developer and accessibility advocate who recently launched a weekly Twitch stream called Semantics, where guests teach him and his audience about core web technologies and accessibility. He credits Jason Lengstorf's Learn With Jason as a primary influence for the format, appreciating its open and inviting community approach.

Ben also shares his personal journey into programming, from being a computer-obsessed toddler who cleverly bypassed a sticky-note "no" on the power button, to building his first website in elementary school and eventually studying computer science in college. His lifelong relationship with computers naturally led him toward web development and a focus on foundational web building blocks over framework-specific knowledge.

00:04:34 - The Accessibility Mindset and Process

Anthony frames the accessibility discussion around two pillars: the mental model for thinking about accessibility and the tools for testing it. Ben immediately steers toward process, arguing that inaccessible sites typically result from workflows that fail to incorporate accessibility rather than from technical shortcomings alone. He outlines how design teams, product owners, and developers each carry responsibility for different aspects of accessibility.

The conversation explores what it means for solo full stack developers to shoulder all of those roles simultaneously. Ben emphasizes that accessibility requirements should be encoded into acceptance criteria and agile workflows, and that color palettes, typography, and keyboard focus management need to be decided before any code is written. This framing sets up the episode's recurring theme that accessibility is a design and organizational challenge first and a coding challenge second.

00:08:01 - Understanding Disability and the Placeholder Exercise

Christopher raises the idea that accessibility exists on a spectrum rather than as a binary checkbox, prompting Ben to walk through common disability categories including visual, auditory, motor, and cognitive impairments. Ben cautions against treating these categories as monolithic, noting that two people with the same disability may experience it very differently and that comorbid conditions are common.

To make the discussion concrete, Ben leads an interactive exercise around form placeholders, asking the hosts to identify access issues. The group uncovers problems ranging from poor color contrast for low-vision users to the cognitive burden of disappearing placeholder text for people with short-term memory loss or attention disorders. This exercise demonstrates how a single, seemingly simple design choice can create barriers across multiple disability types.

00:12:54 - Designing for Accessibility Before Writing Code

The conversation shifts to pre-development design decisions that determine a site's accessibility baseline. Ben highlights key considerations including ensuring sufficient color contrast, avoiding color as the sole indicator of information such as red and green form validation, and planning keyboard behavior and focus management for interactive elements like modals and dialogs.

Christopher then asks about the interplay between operating systems, browsers, and websites in delivering accessible experiences. Ben explains how the browser constructs an accessibility tree from the DOM and exposes it to the operating system for assistive technologies, but stresses that the developer's markup has the greatest impact. A broken site cannot be fixed by the browser or OS, making semantic HTML the developer's most powerful accessibility tool.

00:18:52 - The Curb Cut Effect and Centering Disabled People

Ben introduces the idea that the web is fairly accessible by default when semantic elements are used, and that inaccessibility is often something developers actively introduce. He argues that accessibility is fundamentally good design and illustrates this through the curb cut effect, recounting how Berkeley's curb cuts designed for wheelchair users ended up benefiting parents with strollers, travelers with luggage, and many others.

He extends the analogy to closed captioning, sharing his own experience as someone who is hard of hearing and noting how captions also help people with auditory processing disorders, non-native speakers, and those in noisy environments. However, Ben offers an important caveat: leaning too heavily on the "accessibility benefits everyone" narrative risks de-centering disabled people, whose experience must remain at the heart of accessibility advocacy to prevent it from devolving into developer preferences.

00:22:13 - Testing Tools: Keyboards, Screen Readers, and Automation

Anthony pivots to practical testing, and Ben recommends starting with keyboard navigation as the most intuitive entry point for developers who are already power users. He then encourages developers to become proficient with screen readers, describing key navigation modes including tab-based focus, virtual cursors for reading static content, and element-skipping tools like the VoiceOver rotor or JAWS keyboard shortcuts.

Ben also discusses automated testing tools such as the axe DevTools Chrome extension and Lighthouse, sharing data from Deque Systems showing that automation surfaces roughly 57 percent of accessibility defects, predominantly straightforward issues like color contrast failures and missing alt attributes. He explains why automation cannot reach 100 percent by illustrating how the same image might need different alt text depending on its page context, reinforcing the need to combine automated and manual testing.

00:27:08 - Overlays, Design Systems, and GOV.UK

Christopher asks about accessibility overlay products like UserWay, and Ben explains that accessibility experts generally distrust these tools. He notes that overlays often duplicate functionality users already have through their own assistive technology, have been shown to introduce their own errors, and emerged primarily as a response to the growing threat of accessibility lawsuits rather than from genuine user advocacy.

The discussion then turns to design systems as a more promising approach, with Christopher highlighting the UK government's GOV.UK design system as an example of accessibility baked into a standardized component library. Ben agrees that design systems are powerful for codifying accessibility best practices across organizations but cautions that because accessibility is highly contextual, developers must still test their own implementations regardless of how good the underlying component library is.

00:36:42 - Final Thoughts and Where to Find Ben

Ben wraps up with key takeaways, urging developers to center disabled people in their accessibility work and to view their primary job as building usable interfaces rather than simply writing code. He recommends resources like WebAIM, Deque Systems, and the A11Y Project for developers looking to deepen their knowledge, and encourages everyone to find one thing they can improve today.

Christopher closes with a pointed yes-or-no question: can beautiful websites still be accessible? Ben answers with an emphatic yes, adding that emotional appeal is itself a dimension of accessibility and that in many cases beautiful design actually enhances it. The hosts direct listeners to Ben's Twitter, blog, and his Tuesday Twitch stream for ongoing accessibility content, closing out the episode at 00:39:12.

Transcript

00:00:00 - Ben Myers

All right. That seems to be doing it now.

00:00:12 - Anthony Campolo

Ben Myers, welcome to the show.

00:00:14 - Ben Myers

Howdy. Good to be here.

00:00:16 - Anthony Campolo

Why don't you introduce yourself to our guests and let us know who you are and what you do?

00:00:21 - Ben Myers

Absolutely. My name is Ben. I've been doing web development full time for nearly three years now. I try to be a force in the community for accessibility advocacy. Web accessibility is a big passion of mine. I like to blog about it, and recently I've started a weekly Twitch stream where I bring on guests and they teach me something about web development, core web tech, or accessibility. So if you've seen me around, that's likely why.

00:00:49 - Anthony Campolo

We've gotten to know each other through the React Podcast Discord. We actually just talked with Chan yesterday. So you have now spun off your Twitch channel, Semantics, which I really like. That's a really great name for an accessibility channel. I was really excited that you were doing it because we'd already been talking about doing some sort of accessibility themed stream for RedwoodJS. And so we got to do that for Semantics, and I had a great time. I would love to hear a little bit about who your influences were in terms of creating it. I kind of have an idea, but I think our listeners would find it really interesting.

00:01:27 - Ben Myers

In terms of that stream, the main influence would be Jason Lengstorf and his Learn With Jason show. For viewers or listeners who are unfamiliar, Learn With Jason is a twice-weekly show where Jason brings on guests and they cover various aspects of the Jamstack. It's really great because you get to see a wide variety of the web development world, and it's such an open, inviting community, which I really appreciate. I've been trying to, I don't want to say ape that whole thing, but I've been inspired by that approach of bringing on people in the web development world, people who can show off interesting things that perhaps they don't always have the platform to do, and teaching me and the audience a new thing about the web.

I focus on core web technologies because I think that's really foundational to the stuff that we do on a day-in, day-out basis. We have tons of frameworks. We have meta frameworks. I'm sure at some point we'll have meta meta frameworks, but at some point it all comes down to the building blocks. And I think the single most impactful thing I can do for web development is really focusing on getting absolutely solid with those building blocks.

00:02:43 - Anthony Campolo

I'd be really curious to hear how you first got into programming. What was the first kind of program you ever wrote, your first programming language, or your first website?

00:02:54 - Ben Myers

I've always been a computer guy. This goes back to even as an infant, as a toddler. One of my favorite family stories that gets passed around every once in a while is that my parents realized, like, oh, Ben's probably been on the computer too much as of late, and we need to wean him off of that. So they turned the computer off. This was in the day where all computers by default had towers and people weren't really using laptops. They turned the computer off and they stuck a Post-it note over the power button on the tower that said, no. Little toddler me really wanted to use the computer, so he took the sticky note off, turned it upside down so it said on, stuck it back on, turned the power on, and started using the computer. Computers have been a big part of me growing up. They were a big part of my childhood.

I actually made my first website back in fourth and fifth grade. I used one of those free website builders and it was atrocious. I do not look back on that site with the most kindness, but it was my first site. I got to college, and I had this idea that I was probably going to end up doing something technical, but I wasn't sure what that would be. I was undecided for my major, but I figured, you know what? I like computers. I'm going to play around with computer science as well as the business IT program that we had. Ultimately, I ended up taking computer science and really enjoying that. That's kind of my journey to getting into programming. It's a childhood full of computers.

00:04:34 - Anthony Campolo

Yeah, definitely resonates with me and Chris, same sort of situation growing up. We're really excited to have you here because something that I talked about when I was on your stream is that we're really focused on full stack development here. Obviously, the Full Stack Jamstack. Part of what we really enjoy about that is that it allows solo developers to go really far by themselves with these tools, but what comes along with that is a responsibility to have an end-to-end understanding of the project, where hangups could be, where fault could be. Accessibility can be something that tends to get shuffled around to different departments or different developers, and there's not always the investment that can be made into having an accessibility expert.

I think it's really important for people who are working in these kind of spaces to make sure that they are thinking about accessibility, that they have a mental model about accessibility, and that they have the tools they need to make accessible websites. So for me, I think of it in two buckets. I think of the mental model of how you think about whether your site or your app is actually accessible, and then the tools you use to test, verify, and improve the accessibility of that site.

So do you think that's a good framing, and then which one would you like to go into from there?

00:05:59 - Ben Myers

Yeah, I think that's a fantastic framing. Accessibility is something where you really do have to consider both the accessible experience and the process that you're going to take to get there. I would give the caution that in my experience, where accessibility tends to fall apart is not so much in the technical execution, it's in the process. Inaccessible sites are the product of processes that don't facilitate accessibility.

00:06:25 - Anthony Campolo

Great. Can we go into that? What are the processes that are failing us? How should they be altered?

00:06:30 - Ben Myers

This is largely going to depend a whole lot on the context of the work that you do. My experience is in enterprise. I'm able to take advantage of the teams that we have. I work with the design team, and that design team is going to share some of the responsibilities. They're going to have to pick color palettes that are accessible. They're going to have to pick accessible typography. Business takes some ownership. As a product owner, you need to be including accessibility requirements in your acceptance criteria. To consider a story done, accessibility requirements have to be documented and met.

You need testing. You may have a centralized accessibility team. You may have quality assurance engineers who work with the team directly or you as developers. This is increasingly likely in a full stack world. You as developers might be responsible for that testing yourself, but all of these roles have to be met. It's not just about developing the accessible site, it's about designing the accessible site. It's about encoding those accessibility requirements into the agile workflow or into the requirements themselves for the stories. It's about the testing. It's about all of these things. There's so many different parts of this picture. If you're living that full stack Jamstack dream of being the lone developer that can build the site, that also means that you're taking on every piece of that puzzle as well, which can be a challenge for sure.

00:08:01 - Christopher Burns

One of the things that I always like to think about when it comes to accessibility, it's a spectrum. It's not just binary. Some people are colorblind. When you put a warning sticker and a [unclear] sticker, they may look exactly the same to some people. Another instance is mouse support could be limited when they prefer to use a keyboard. So could you tab down the entire page to the section you need? As I see it, yes, we could all always be better with accessibility, but it's not necessarily like, how do I complete accessibility? How do I tick it off? It's more, what am I doing to try my best? I believe if you're trying to even just do something, it's better than nothing.

00:08:50 - Ben Myers

I think there's a lot of truth to that, and I think there's a lot of truth to it as you're talking about this spectrum of ability. When you're first coming to learn accessibility and the importance thereof, you'll often find resources that break down disabilities into several categories. Those categories might be vision impairments like blindness, low vision, colorblindness. There might be hearing impairments. I'm, for instance, hard of hearing, so I need to leverage captions and transcripts quite often, or they assist in my comprehension. There's motor disabilities, limb loss, and paralysis. There's cognitive disabilities as well, learning disabilities and dyslexia and stuff like that.

The thing about those categorizations is, while I think they can be helpful for developers to step outside of their bubble, step outside their comfort zone, and imagine what navigating the web might be like for people with disabilities, I think it risks turning disability into a bit of a monolith, into saying, these are the properties that disabled people have, these are the experiences that they have, and that's just simply not true.

Two people with the same disability will experience it very differently based on their life circumstances. In fact, many disabled people have multiple disabilities. This is kind of a recurring joke I see in the disability community that if you have one disability, you actually have three disabilities because things are comorbid and they build on top of each other. So disability is not one concrete experience. But breaking it down into those categories of visual, auditory, cognitive, motor can be a helpful way to start approaching experiences.

We can start breaking things down in terms of how might someone with those experiences navigate the page? Do you all mind if I go through a quick exercise with you?

00:10:45 - Anthony Campolo

Let's do it. Yeah.

00:10:46 - Ben Myers

All right. Y'all have seen forms before. I'm pretty confident you've seen forms before. Sometimes those forms are prone to having placeholders. If you're unfamiliar with the placeholder, that's the little grayed-out text that exists inside of an empty form field. Once you start typing in that form field, the placeholder text goes away. Based on the categories of disabilities, the visual, auditory, cognitive, motor, what are some possible access issues you might think of with a placeholder?

00:11:17 - Christopher Burns

You could, on the placeholder, put a pattern. It needs to be two letters, space, two letters, space, two letters, like a sort code. Then obviously you don't copy the same structure. Error, but that's one of them. I'm actually going to say my favorite, Google's accessibility placeholder label. They are all awful. Where the placeholder becomes the label when you start typing, I hate them. Please, everybody stop doing them.

00:11:50 - Ben Myers

There are tons of things to say about that, but even if we're just talking about the native placeholder, we're talking like semantic input element with type equals text and we're using the placeholder attribute. What are some possible access issues that we might get from that?

00:12:06 - Anthony Campolo

An issue is as soon as you start typing and you lose the placeholder, then if you don't remember what it says, you can get lost. I know people who have attention disabilities, and that could be a problem.

00:12:17 - Ben Myers

Absolutely, or people with short-term memory loss. We're providing key context about the page and how we expect you to do it, and then we take it away from you the moment you start doing anything with it. So yeah, if you have short-term memory loss, if you have attention disorders, if you have really any cognitive disability that makes complex experiences difficult for you to understand, placeholders are an access problem there. We could also talk about the vision aspect of it. Placeholders usually appear in a very light gray, which means that they're nightmarish for color contrast.

00:12:54 - Anthony Campolo

I'd like to get into this. You had mentioned something I wanted to drill in on. You talked about designing for accessibility before even developing, and I think this is kind of some of the things that we're talking about right now, the types of considerations you can make before a single line of code is written. So what are some of those considerations you can make, and how can we design for accessibility before we even start coding?

00:13:15 - Ben Myers

When we work on the web, we usually talk about making things accessible for people with vision disabilities because much of the web is inherently visual in nature. I would also add that the second highest group you need to consider is anyone who needs to navigate the page using the keyboard. We often make this assumption that our users have similar experiences and capabilities as we do, but the truth is, you are not your user as you're considering accessibility from a design perspective.

Before any code is written, you do need to consider, hey, these colors, do they have sufficient contrast? That's super important. You also need to consider, is color the only way we're indicating information? If we're showing a graph, if part of our experience is data visualization and we have a couple of lines and one of those lines is blue and another is green and this is our big important data, what if someone's colorblind? Or to tie it back to work that I do on a day-to-day basis, form validation often requires we show, hey, you filled this out correctly with green and you filled this out incorrectly with red. Well, for someone who is red-green colorblind, those colors are likely the same color to them or very similar.

Making sure that color isn't the only indicator of information is hugely important. Also, keyboard behavior and focus management is absolutely one of the things I think gets forgotten about. If you're opening modals and sidebars and dialogs, where should the focus go? Where should we put the user's cursor so that their screen reader announces where they're at, and where should it go when you close that experience? All of these things need to be decided before you ever write a line of code. Ideally, if you were in an organization that has the design team to support it, that should be the design team documenting those requirements.

00:15:09 - Christopher Burns

I've heard that iPhone is very good at accessibility, as in iOS that's done by Apple. Where does the most impact come in accessibility, from an OS and then an app, or from the app subsidized by the OS? And what I mean by that, does picking a browser matter more in terms of accessibility than the website?

00:15:36 - Ben Myers

Yeah, that's a fantastic question. The truth is, your operating system, your browser, and your website all work in concert, and they all have different specs that they're trying to meet. Your browser packages up your page, your DOM, into an alternate version of the page called the accessibility tree. It's an alternate version of the DOM, and it exposes it to the operating system in such a way that screen readers can pull from and figure out what's the state of the current application. But browsers are limited by the language that the operating system uses, the primitives that the operating system provides. If the operating system doesn't say that, like, hey, buttons are an element that can exist, then the browser is limited by that. So browsers and operating systems have to work together, but browsers have to work together with your page for browsers to put together a meaningful representation of your page for assistive technology. You, as the developer, have to make sure that your page is descriptive, meaning semantic markup.

This is just one way. You have to write a meaningful page so that your browser can translate it in a way that's meaningful for assistive technology. All of these three things work together. They work together with specs. I would say that as far as we're concerned, while all three of these things work in concert, it is the site that's going to have the most effect. Your browser can't fix a broken site. Your operating system can't fix a broken site. The only thing that can fix a broken site is the developer. Additionally, browsers and operating systems are usually adhering to specs that are put together by the World Wide Web Consortium, specifically the Web Accessibility Initiative team. They're conforming to those specs pretty well, decently, consistently. There is variation there, but you're not going to see nearly as much impact in that regard as you are from just building a strong site.

00:17:40 - Christopher Burns

It's that question of how much you can control. You can control to support IE11 or not, and you can control to support accessibility or not. To some extent, you need accessibility no matter if you have any disabilities or not. For the prime example, as you age, you start relying on things like bigger text. How many websites do you know that have bigger text options by default? I think that's a really rare one built into the website. I'm dyslexic myself. For so much of my life I thought dyslexia was a disability, but now I view it as an ability. You know, removing the dis and keeping the ability, it really changes how you can see and your mind works differently. And that's why I always think about accessibility as this bonus instead of this thing that takes away because, like we say, with good accessibility, you get to probably fully navigate a website using your keyboard. Small things like that are things that you only get when you view the abilities from disabilities.

00:18:52 - Ben Myers

I think there's also something to be said for the web. By default, it's pretty accessible. If you're using semantic elements, you're a large chunk of the way there, which means that inaccessibility is often the product of the process breaking things. Developers implemented the site in a way that broke the native accessibility, or designers designed a site that out of the box was not accessible. I really, truly believe that accessibility is good design. No qualifiers there. Accessibility is good design. It does help everyone. Everyone benefits from a more accessible site. Chris, what you're referring to is, in effect, that in the disability community we call the curb cut effect.

Back in, I want to say it was the 60s, the city of Berkeley decided to implement curb cuts. This was through the efforts of several quadriplegic Berkeley students who pushed for a more accessible path through downtown Berkeley. The city implemented these curb cuts. Chris, I believe they're called curb cuts or ramps on the other side of the pond, but it's where the sidewalk slopes down into the road, into the intersection.

Basically, this would allow wheelchair users to not have to hop the curb every time they wanted to get into the road to cross the road, and not have to hop over the curb every time they wanted to get back onto the sidewalk. What Berkeley found over the next few years was that these curb cuts weren't only being used by wheelchair users. They were also being used by parents with strollers and people with luggage, people with freight carts. Many people were able to benefit from this.

A modern day example of curb cuts might be closed captioning. I mentioned I'm hard of hearing. I often use captions as a way to help my comprehension, even when I can technically hear the thing. It just helps to have that additional aid. However, closed captions can also benefit people with auditory processing disorders or people for whom that language is not their first language, or people who are in loud environments, such as bars where you wouldn't be able to hear the TV anyway.

So accessibility really does benefit everyone. However, I think my caveat there is if we lean too heavily in the accessibility is for everyone aspect, we de-center disabled people and that gets really uncomfortable. At its heart, accessibility is advocating for disabled users. If we decenter their experience, then it often becomes about developer preferences and in many ways about developer egos. At the heart of accessibility has to be disabled people.

00:21:41 - Christopher Burns

I wish I could have closed captions for real life. My girlfriend tries to talk to me, but if there's a washing machine going, I can hear what she's saying, but I can't comprehend what she said. I can't explain it. It's so weird.

00:21:58 - Ben Myers

The single biggest use case for closed captions has been watching Doctor Who. Love Peter Capaldi. His accent was difficult for me to comprehend. It was a very, very strong accent, and yet I need my British sci-fi.

00:22:13 - Anthony Campolo

All right, so we've talked about how to think about designing an accessible website, considerations like semantic markup, color contrast, being able to tab through a page, being aware of different types of disabilities and the different challenges they will each encounter. Now that we have a site, we've done our best to design it. Once we're actually implementing it, what are some of the tools, the tips, the techniques that we can use to verify and test that it is accessible?

00:22:48 - Ben Myers

I think one of the easiest for people to wrap their head around is keyboard navigation, because I think many developers, I'm not going to make this a universal statement, but I think many developers would consider themselves power users of technology, and therefore many of us likely already use keyboard navigation to quickly hop through forms and stuff like that. This is something that's already pretty familiar to us. It's also pretty clear when something doesn't behave as intended. When the focus order hops around, or when something we expect to be focused or keyboard-navigable isn't focusable or keyboard-navigable. So keyboard navigation is one of those things that I think for many of us will come pretty familiarly and is something that can provide immense accessibility testing value.

The next thing I'm going to suggest is getting really good with screen readers. This is something that can seem pretty daunting, but the truth is, when disabled users use assistive technology, they by necessity become power users of their assistive technology. They have to. That's how they navigate the world. And as developers who are committed to meeting accessibility needs and committed to meeting the needs of people with a wide variety of experiences, we have to test for those experiences. So get familiar with screen readers.

If you're on Windows, the screen readers that you're going to want to look into are JAWS, which is a paid screen reader, quite expensive, but it's the most commonly used screen reader. There's NVDA, which is free, and I believe it's open source. If you're on Mac, there's VoiceOver, which is built into the operating system. There are screen readers for mobile operating systems as well. You can find those with a quick Google search.

By and large, screen readers are going to have several navigation modes. Tabbing the focus that you're used to, again, focus implies interactivity. So if you can tab to something, that implies that it's interactive. You should be able to tab to, for instance, links, buttons, and form fields. If you can tab to something and it's not keyboard interactive, that is a wrong experience. Most of the time when you're tabbing, you're looking for keyboard interactive elements.

The next screen reader navigation mode is the virtual cursor. This is usually the read-everything mode. So if you want to skim through all the static text and the images and stuff like that, you're going to want to find whatever your screen reader's virtual cursor is. The next thing is that screen readers, and this is something that I think a lot of developers don't actually know about screen readers, most screen readers come with a way to hop between different elements of the same type. For JAWS, it's a plethora of keyboard shortcuts. With macOS VoiceOver, it's a tool called the rotor. If you can't see the page, then you can't just scroll down the page and quickly skim through it. So screen readers provide, whether it's the rotor or the keyboard shortcuts, ways to skip through parts of the page to get to the parts that you care about really quickly.

That can often be very unintuitive. We as sighted people, the three of us on this call, might go, well, who would ever want to skip through a page by going from link to link? But many people do. So this is a mode that screen readers provide. Figure out what your equivalent for the screen reader that you're testing with is and use that.

There are also automated tools. You can run scans. One of the biggest ones is a Chrome extension called axe DevTools. This will scan through your page and automatically figure out some of the defects. There are limits to automation, and I think we'll get to those in due time, but there are a plethora of tools to use. I think you have to use all of them in concert. You have to test the keyboard navigability. You have to test the screen reader experience. You can run the automated tests, but I think you have to do all of the above to really, truly get a holistic understanding of the experience.

00:27:08 - Christopher Burns

What's your opinion on tools like UserWay where it's like a SaaS product to do accessibility for you? Is that a definitely not, or is that just a band-aid on the issue?

00:27:21 - Ben Myers

I have to be very careful about this because what you're talking about are tools called accessibility overlays. For listeners who might not be familiar, you might go to a site and sometimes see, like in the bottom left corner, there's a little accessibility symbol. You can click that and it opens up a panel that provides several accessibility features like, hey, we can update your color scheme, or we can make your text large, stuff like that, or we can read your page aloud.

The way I will word this is that accessibility experts do not trust accessibility overlay tools. The truth is, many of them do not do anything that the user wouldn't already have the assistive technology to do. They're simulating a screen reader, but a simulated screen reader is not going to be anywhere near as good as the screen reader you actually use on a day-to-day basis. Additionally, it's been demonstrated that several of them actually commit excessive errors themselves. They have poor focus behavior and stuff like that.

Really and truly what you're looking at there is a field that realized that accessibility lawsuits were going to get more and more common, and they started getting venture capital chucked their way. I don't believe that they provide anywhere near the support for accessibility that just fixing your site would do, and I don't believe that they ever can.

00:28:45 - Christopher Burns

It's interesting. If there's anything I'm proud about being British, our government websites, the UK government has their UI totally open on GitHub. I hear, as far as accessibility, it is really, really good. It's called like GOV.UK React, I think it is, but they're supposedly really good for accessibility as that was one of their main goals, how do you fully make something that everybody needs to use. To give the backstory that I do know, before GOV.UK standardized their interfaces, every single government agency had their own website, own forms, own styles, own system. All of it never spoke the same style or language. So they decided to start an initiative where every government agency would use the same UI library, same user interface patterns. As a user, it doesn't visually look amazing, but for accessibility of a government website, it's second to none. Every time I use it, it's great.

For example, in the UK right now we have a thing called a census. That's every single household in the country. You have to go onto the census and say, like, there's two people living in this house and this is what we do. So the government can allocate spending and voting rights and all those things. Every single person in the UK has to do it. It's a really interesting thing to look up about the UK and how they achieve, I believe, a very good accessibility record. But I'm not the expert there.

00:30:34 - Ben Myers

I've heard fantastic things about the GOV.UK design system, and I'm incredibly excited to see more and more design systems that come out with accessibility baked in as much as possible. For me, the first one that flew onto my radar, a design system called Grommet, or I guess it's more of a component library than anything. Absolutely, I think design systems and component libraries are a powerful tool for standardizing accessibility practices across a product, across an enterprise. And I would encourage, if you're working in the design space in your company, if you're working in part of a larger enterprise and you're in the design space, see how your design system can leverage accessibility and codify that into best practices there.

I think oftentimes with design systems, you still have to do your own testing. One of the recurring themes that I learned from accessibility is that you can have tools that improve the developer ergonomics and handle a lot of stuff right out of the box, but accessibility is so contextual that you have to still test it yourself. You have to still make sure it works for everyone in the context of your own application. Yes, look for tools that are doing accessibility well. Look at tools that make it really easy to be successful at accessibility, and then still test it because every app is going to be different.

00:31:57 - Anthony Campolo

The accessibility score from Lighthouse? Because Lighthouse gives you a whole bunch of metrics for performance, SEO, and one of them is accessibility. I've always kind of wondered about that metric and what goes into it, if it's useful to optimize around ergonomics. Once I saw that we had deployed a Redwood to Netlify and Vercel, the exact same codebase, same repo, and they got different accessibility scores, I thought that was really interesting. The whole Lighthouse thing is kind of a black box to me, so I didn't really know how to drill into that. I'm curious if you know anything about that.

00:32:31 - Ben Myers

The specific stats that Lighthouse looks for you can read about at web.dev. I want to say Lighthouse is, behind the scenes, using the same engine that powers the axe DevTools extension, maybe with some more Google opinions in there, but I don't know what specifically might have caused your discrepancies. Tools like that are incredibly powerful. I'm very passionate about accessibility, but the truth is, I don't think every developer can or will be passionate. I would hope that would be part of the expectation, but the truth is, there are so many things on our plate and so many things can slip under the radar. So one of the really important things is figuring out how to surface accessibility issues that might be lying latent in our application. Automation fills a very powerful role with that.

Deque Systems is the company that puts together the axe DevTools extension. As we talk, they have just wrapped up their AxCon, which is an accessibility conference. I was fortunate enough to attend a talk by Glenda Sims about axe DevTools and the role automation plays in accessibility testing.

One of the things I was really surprised to learn was, of all, I want to say, it was like 2,000 audits that Deque performed on pages, 57.38% of defects were surfaced by automation. The bulk of these are going to be things that you can pretty easily calculate with a machine. Thirty percent of all defects were color contrast issues according to this report, and I can put the report in the show notes because it's good stuff. But yeah, 57% of the issues surfaced in these audits were specifically surfaced by automation because computers are really good at checking a whole bunch of simple rules really quickly.

For instance, does all of your text meet color contrast requirements? That is something that to test manually would be a waste of your developer or tester's time. Do all images have an alt attribute? That's something that computers can do really quickly and would be a waste of your tester's time. You want accessibility engineers thinking about higher order problems like complex interactions.

I do want to talk about the limitations of automation in this regard because we might be asking ourselves, well, why only 57%? Why can't the tools find 100%? Why can't they find 90%? Why 57%? The truth is, again, accessibility is very contextual. It's easy for a computer to say, yes, this image has alt text. What's difficult is deciding whether that alt text is meaningful or helpful, and that's a very contextual thing. The same image might have different alt text depending on what page it's on.

We could have, for instance, I think the example WebAIM uses is George Washington's presidential portrait, the painting that was made of George Washington when he took office, on different pages. The alt text for that might be different. On some pages that might just simply be President George Washington. Simple as that. Totally fine. On a biography of George Washington, we might actually interpret that picture as decorative. It doesn't actually add anything. We're already talking about George Washington. You don't really need to know that there even is a picture of George Washington. So you might have it as the empty string, which causes screen readers to ignore that image altogether. Or if the presidential portrait is showing up on an art blog that's talking about the different painting styles, maybe you don't necessarily need to describe what George Washington looks like, but you do need to describe the brushstrokes.

That's very contextual, and it's something that machines are never really going to be able to solve. As ever, you really need to combine automated testing with manual testing, but in such a way that the automated testing handles all of the low-level, easily calculable, binary pass-fail stuff so that your accessibility engineers can focus on solving the bigger, harder, more contextual problems.

00:36:42 - Anthony Campolo

As we're getting close to the end of our time, are there any last big ideas, things that you think we haven't covered, that are really important for developers to keep in mind?

00:36:51 - Ben Myers

Accessibility is important, and there oftentimes isn't one right answer. Again, make sure you're centering disabled people's experience in your advocacy of accessibility. There's a lot to it, but there are tons of resources out there. I'll make sure that some get added to the show notes. Look for resources like WebAIM or Deque Systems or the A11Y Project. These are developers who are in this space day in, day out, who have done testing and have just a wealth of expertise and a willingness to hop in and help solve problems.

Remember that when we're building experiences, when we're building interfaces, that's our job. Our job is building an interface that users can use. The HTML, the CSS, the JavaScript, the frameworks, the meta frameworks, the Redwood, all of that is incidental. It's how we work. It's not what we do. What we do is we make usable interfaces. That's our job. Definitely take some time to figure out what can you do today to make your experience just a bit more usable, and then what can you do going forward? How can you adjust your process to continue baking accessibility into your apps?

00:38:05 - Anthony Campolo

Thanks so much, Ben. I've really enjoyed getting to pick your brain in this episode, and also over the many months that we've gotten to know each other. I highly, highly encourage people to check out both your streaming show and also your blog. You are one of these developers out there putting out this really fantastic accessibility content that I think people should know about. So why don't you also make sure that people know where they can find your stuff, how they can get in contact with you?

00:38:32 - Ben Myers

So first of all, you should follow me on Twitter at Ben D Myers. You can also find me on my blog at benmyers.dev. I post mostly about accessibility stuff. Finally, catch me every Tuesday on Twitch at Some Antics Dev. We'll just be learning about core web technologies as well as accessibility. It's been a great time, and I would love to see you all there.

00:39:02 - Christopher Burns

My final question is simple, yes or no. Can beautiful websites still be accessible?

00:39:09 - Ben Myers

Yes.

00:39:10 - Christopher Burns

There you go.

00:39:12 - Ben Myers

I think there's something to be said for emotional appeal as a key part of accessibility. I would argue that in many cases, beautiful sites are more accessible.