Episode 31 - Fullstack Accessibility with Ben Myers
Ben Myers is a web developer, accessibility advocate, and human T-rex. He is also the host of Some Antics, a weekly educational livestream. We discuss the processes that lead to inaccessible websites, the mental models fullstack developers need to build accessible websites, the tools they can leverage to improve their site's accessibility, how to keep a healthy skepticism towards accessibility focused products, and the necessity of centering accessibility efforts on the experiences of disabled users.
Ben MyersLinks
Ben Myers, welcome to the show.
Ben
Howdy. Howdy. It's good to be here.
Anthony
Why don't you introduce yourself to our guests and let us know who you are and what you do?
Ben
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. Recently I've started a weekly Twitch stream where I bring on guests and they teach me something about web development, core web tech and/or accessibility. So if you've seen me around, that's likely why.
Anthony
We've gotten to know each other through the React Podcast Discord, we actually just talked with Chan yesterday. You have now spun off your Twitch channel, Some Antics, which I really like I think that's a really great name for an accessibility channel.
I was really excited that you were doing it because we had already been talking about doing some sort of accessibility themed stream for RedwoodJS. We got to do that for Some Antics 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 interesting.
Ben
So in terms of that stream, the main influence would be a Jason Lengstorf and his Learn with Jason show. For viewers, or I guess 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 just a wide variety of the web development world. It's such an open, inviting community, which I really appreciate.
I've been trying to sort of, I don't want to say like, ape that whole thing. But, I've been inspired by that approach, 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 just teach me and teach the audience a new thing 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 and 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.
Anthony
I'd be really curious to hear, how did you first get it programming? Like what was the first kind of program you ever wrote or your first programming language or your first website? Anything like that?
Ben
Okay. I have always been a computer guy. This goes back to even as an infant, as a toddler. One of my favorite like 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 them off of that." They turned the computer off and you know, this was in the day where all computers by default had towers and everything that people weren't really using laptops.
They turn the computer off and they stuck a post-it note over the power button on the tower. If it 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, turn the power on and started using the computer. Just really and truly computers have been a big part of just me growing up. They were a big part of my childhood.
I actually made my first website back in like 4th and 5th 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, perhaps, 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, a childhood full of computers.
Anthony
Yeah, it definitely resonates with, I'm sure, 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 this is FSJam, fullstack 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, I see, of having a whole end to end understanding of the project.
You need to know where hangups could be or where faults could be. Accessibility can be something that tends to get kind of shuffled around to different departments or different developers and there's not always the investment that can be made into having just an accessibility expert. I think it's really important for people who are working in these kinds of spaces to make sure that they are thinking of accessibility and that they have a mental model about accessibility and they have the tools they need to make accessible websites.
For me, I think of it in those two kind of buckets, I think of the mental model. Of how do you think about whether your site or your app is actually accessible and then the tools you use to test and to verify, and to improve the accessibility of that site. So do you think that's a good framing and then which one would you like to kind of go into from there?
Ben
Yeah, I think that's a fantastic framing. You really do have to consider both the actual accessible experience and the process that you're going to take to get there. I would give the caution that in my experience, accessibility tends to fall apart not so much in the technical execution but in the process. Inaccessible sites are the product of processes that don't facilitate accessibility.
Anthony
Great and can we go into that? What are the processes that are failing us and how should they be altered?
Ben
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 a design team and that design team is going to share some of the responsibilities. They are 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.
Developers, and this is increasingly likely in a full-stack world, might be responsible for that testing yourself, but all of these roles have to be met. It's not just, it's 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.
Chris
One of the things, things that I always like to think of when it comes to accessibility is a spectrum. It's not just binary. Some people are colorblind. When you put a warning sticker and a success sticker, they may look exactly the same to some people or another instant is mouth support. Could be limited when they prefer to use a keyboard.
So could you tab down the entire page, you know, to the section you need. As I see it, yes, we could all always be better accessibility, but it's not necessary. Like how do I complete accessibility? How do I take it off? It's more, what am I doing to try my best? I believe if you're trying to even just do something is better than nothing.
Ben
I think there's a lot of truth to that. And I think there's a lot of truth to, as you're kind of talking about this spectrum of ability. When you're first coming to learn accessibility, and the importance of accessibility, you'll often find resources that break down disabilities into several categories. Those categories, for instance, might be vision impairments, like blindness, low vision, colorblindness, etc. 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, live loss and paralysis. There's cognitive disabilities as well, learning disabilities and dyslexia and, and stuff like that. The thing about those categorizations as well, I think they can be helpful for developers to step outside of their bubble step outside of their comfort zone. And imagine what navigating the web, what that experience 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 a 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've actually have three disabilities, cause things are comorbid and they build on top of each other.
While disability is not one concrete experience, breaking it down into those categories of visual, auditory, cognitive motor can be a helpful way to start approaching experiences. We start breaking things down in terms of how might someone with those experiences navigate the page. Do y'all mind if I go through a quick exercise with you?
Anthony
Let's do it, yeah.
Ben
All right. Y'all have seen forums before. I'm pretty confident you've seen forms before. Um, and 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. And once you start typing in that form field, the placeholder text goes away. Based on kind of the like categories of disabilities, the visual auditory, cognitive motor, what are some possible access issues you might, uh, think of with a placeholder.
Chris
You could on the placeholder put a pattern. It needs to be two letters. Space, two letters space, two lies like a sort code. And 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 place holder becomes the label. When you start typing, I hate them. Please everybody stop doing them.
Ben
There are tons of things to side eye about that. But even if we're just talking about like the native placeholder, right? Like we're, we're talking like Symantec input element with type equals text and we're using the placeholder attributes. What are some possible access issues that we might get from that?
Anthony
An issue is as soon as you start typing and you lose the placeholder, then if you don't remember what it says, you like get lost. So I know people who have like, Attention disability type. That could be a problem.
Ben
Absolutely, or people with short term memory loss. We're providing a 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. 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 they're nightmarish for color contrast.
Anthony
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 is. The types of considerations you can make before a single line of code is written. And so what are some of those considerations you can make? And how can we design for accessibility before we even start coding?
Ben
When we work in 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 kind of like second highest group that 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 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, foreign validation often requires, uh, we, we show, Hey, you filled this out correctly with green and you filled this out incorrectly with red. Well, for someone who has red, green colorblind, those colors are likely the same color to them, or very similar. Right? So making sure that color isn't the only indicator of information is hugely important. Also keyboard behavior, focus management is absolutely.
One of the things that I think it's forgotten about is if you're opening modals and sidebars and dialogues, where should the focus go? Where should we put the users' cursor so that their screen reader announces where they're at and where should it go when you close that experience? And all of these things need to be decided before you ever write a line of code. And ideally if you're in an organization that has the design team to support it, Ideally that should be the design team that's documenting those requirements.
Chris
I've heard the iPhone is very good at accessibility. iOS is done by Apple. Where does the most impact come in accessibility: from an OS and then an app or from the app and then the OS? Does picking a browser matter more in terms of accessibility than the website?
Ben
That's a fantastic question. And the answer is specs are great. I love specs. So 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 us to the operating system in such a way that strangers can pull from and figure out like 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. So if 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 browser just 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.
So this is just one way, like you have to write a meaningful page so that your browser can translate it in a way that's meaningful for assistive technology and all of these three things work together that 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 there they're usually adhering to specs that are put together by the worldwide web consortium, uh, specifically the web accessibility initiative team there they're conforming to those specs pretty well, decently consistently. So 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.
Chris
It's that question of how much you can control. You can control to support our year 11 or not. And you can control to support accessibility or not just things that 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 rabble as like built into the website.
I'm dyslexic myself. For so much of my life, I thought dyslexia was at disability, but now I view as a and I removed 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 properly, fully navigate a website using your keyboard, small things like that is things that you only get when you view the abilities from disabilities.
Ben
I think there's also something to be said for the web by default is pretty accessible. If you're using semantic elements you're a large chunk of the way there. This 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, etc.
I really, truly believe that accessibility is good design, no qualifiers there. Accessibility is good design. It does help everyone, right? Everyone benefits from a more accessible site. Chris, what you're referring to is an effect that in the disability community, we call the curb cut effect. Back in, I want to say it was the sixties, 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 the downtown Berkeley.
The city implemented these curb cuts, Chris, I believe they're called pram cuts or pram 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 on 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 like straight carts, just bring stuff along. Like many people were able to benefit from this. A modern day example of curb cuts might be closed captioning. So I mentioned I'm hard of hearing.
I often use captions as a way to just 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 who 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. 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. Like at its heart, accessibility is advocating for disabled users. If we de-center 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.
Chris
I wish I could have closed captions for real life. My girlfriend tries to talk to me, but if there's a washing machines going, I can hear what she's saying, but I can't comprehend what she said. It's just like, I can't explain it. It's so weird.
Ben
The single biggest use case, for me, for closed captions has been watching Dr. Who. Love Peter Capaldi but his accent was difficult for me to comprehend. It was a very, very strong accent. And yet I need my British Sci-fi, you know?
Anthony
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 we have a site that we've done our best to design. 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?
Ben
I think one of the easiest for people to wrap their head around is keyboard navigation. I think many developers, I'm not going to make this like 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 a form 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, right? When the focus order hops around or when something we expect to be focusable or keyboard navigable isn't focusable or keyboard navigable. Keyboard navigation is one of those things that I think for many of us will come pretty familiarly and is something that I think 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, by necessity they become power users of their assistive technology. They have to, that's how they navigate the world. You have to get good at it. As developers who are committed to meeting accessibility needs and committed to meeting the needs of people with a wide variety, with a wide array of experiences, we have to test for those experiences.
So get familiar with screen readers. If you're on Windows, the screen reader that you're going to want to look into is JAWS, which is a paid screen reader. It's quite expensive, that's the most commonly used streaming, There's NVDA, which is free and I believe open source. If you're on Mac there's VoiceOver, which is built into the operating system. There are screenwriters for mobile operating systems as well. You can find those with a quick Google search.
But by and large screen readers are going to have several navigation modes. Tabbing. The focus that you're used to, focus implies interactivity. If you can tab to something that implies that it's interactive, so you should be able to tab to, for instance, links, buttons, and foreign 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, "just read everything" mode. So if you want to skim through all the static texts and the images and stuff like that, you're going to want to find whatever your screen readers virtual cursor is.
And the next thing is that screen readers, and this is something that I think a lot of developers don't actually really know about screen readers, most stream readers come with a way to hop between different elements of the same type. For JAWS it's a plethora of keyboard shortcuts, with Mac it's 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. Screen readers provide whether it's the rotor or the keyboard shortcuts. They provide ways to skip through parts on the page to get to the parts that you care about really quickly.
That can often be very unintuitive. Like, we as sighted people, the three of us on this call, we 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. So figure out what your equipment for the reader that you're testing with 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, I suspect. But there are a plethora of tools to use and 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, etc, but I think you have to do all of the above to really, truly get a holistic understanding of the experience.
Chris
What's your opinion on tools, like UserWay where it's like a SAS product to do accessibility for you? Is that a definitely no or is that just like a bandaid on the issue?
Ben
I have to be very careful about this. You're talking about tools called accessibility overlays for listeners who might not be familiar. You might go to a site and sometimes see 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 texts large, stuff like that. Or we can read your page aloud.
The way I will word this is, Accessibility experts do not trust accessibility overlays. The truth is many of them do not do anything that the user would and already have the assistive technology to do, right? Like they're simulating a screen reader, but a simulated stream 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 accessibly 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 lawsuits were going to get more and more common and they started getting venture capital checks their way. I don't believe that they provide anywhere near the support for accessibility that just fixing your dang site would do. And I don't believe that they ever can.
Chris
It's interesting. If there's anything I'm proud about being British is our government websites. The UK government has that UI totally open on GitHub. I hear for accessibility it is really, really good. It's called like govuk-react. I think it is. But that's supposedly like really good for accessibility as that was one then main goals as like, how do you fully make something that everybody needs to use? Because to give the backstory that I do know before.
GOV.UK standardized that interfaces. Every single government agency had that own website, own forms, own styles, own system. All of it never spoke the same style or language. 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 is next to none. Every time I use it. It's great.
For example, in the UK right now, we have a thing called a census. So that's every single house old in the country. You have to go onto the centers 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 them things, every single person in the UK has to do it. It's a really interesting thing to look up about the gov UK and how they achieved. I believe a very good accessibility record. Well, I'm not the answer about that.
Ben
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 was a design system called grommet. I guess it's more of a component library than anything, but I think design systems and/or component libraries are a powerful tool.
They can standardize accessibility practices across a product and across an enterprise. I would encourage you, if you're working in the design space in your company, if you're working in part of a larger enterprise, to 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.
I think this is one of the recurring things I learned from accessibility. 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.
Anthony
Do you ever use the accessibility score from lighthouse? Because lighthouse gives you a whole bunch of metrics for like performance, SEO, and one of them is accessibility. I've always wondered about that metric and what goes into it and if it's useful to optimize around or not.
I once saw that we had deployed a Redwood to Netlify and Vercel, it was the exact same app deployed from the exact same code base and each deployed project got a different accessibility scores. I thought that was really interesting. The whole lighthouse thing is kind of a black box to me. I didn't really know how to drill into that, so I'm curious if you know anything about that.
Ben
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-y opinions in there, but I don't know what specifically might've caused your discrepancies that you were seeing there. But I think 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 an accessibility expert.
I would hope that would be part of the expectation, but the truth is there are so many things on our plate. So many things can slip under the radar. One of the really important things is figuring out how to surface accessibility issues that might be lying latent in our app. I think automation fills a very powerful role. Deque system the company puts together the axe DevTools extension. They have just wrapped up their axe-con, 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 2000 audits that Deque performed 57% of defects are surfaced by automation. And the bulk of these are going to be things that you can pretty easily calculate with a machine, right? 30% of all defects were color contrast issues, according to this report. And I can put the report in the show notes for y'all cause 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 texts meet color, contrast requirements? That is something that to test that manually would be a waste of your developer or testers time. I'm really good at checking. Do all images have an alt attribute, but something that computers can do really quickly, it would be a waste of your testers time. You want accessibility engineers thinking about higher order problems. Like. Complex interactions.
I do want to talk about the limitations, though, of automation in this regard. We might be asking ourselves, well, why only 57%? Why can't the tools find 100%? Why can't they find 90%? Like why 57%? And 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 texts depending on what page it's on.
We could have, for instance, the example of 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. It might just simply be president George Washington. It's 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. It might be all you have is 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 brush strokes.
It's very contextual and 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 like low level, easily calculable binary pass-fail stuff so that your accessibly engineers can focus on solving the bigger, harder, more contextual problems.
Anthony
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 is really important for developers to keep in mind?
Ben
Accessibly is important and there often times aren'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 web.dev or Deque systems or the a11y project. That's a 1 1 Y 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, 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. Take some time to figure out what you 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 app?
Anthony
Thanks so much, Ben. I've really enjoyed getting to pick your brain in this episode, but also over the many months that we've gotten to know each other. I highly, highly encouraged people to check out both your streaming show and also your blog. You're one of these developers out there putting out this really fantastic accessibility content that I think people should know about. Why don't you also make sure that people know where they can find your stuff and how they can get in contact with you?
Ben
So, first of all, you should follow me on Twitter @bendmyers. You can also find me on my blog at benmyers.dev where I post mostly about accessibility stuff. And then finally, every Tuesday on Twitch at twitch.tv/someanticsdev where we will be sharing, just learning, following along with core web technologies, as well as with accessibility. It's been a great time and I would love to see y'all there.
Chris
My final question is simple. Yes or no, can beautiful websites still be accessible?
Ben
Yes.
Chris
There you go. Simple.
Ben
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.
- Putting RedwoodJS Docs to the Test
- JAWS - Website
- NVDA - Website
- VoiceOver - Website
- axe DevTools
- axe-core
- axe-con
- GOV.UK Design System
- GOVUK-react
- Grommet
- Lighthouse accessibility scoring
- Lighthouse accessibility audits
- The Automated Accessibility Coverage Report
- Web Accessibility in Mind (WebAIM)
- Deque Systems
- The A11Y Project
Ben Myers, welcome to the show.
Ben
Howdy. Howdy. It's good to be here.
Anthony
Why don't you introduce yourself to our guests and let us know who you are and what you do?
Ben
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. Recently I've started a weekly Twitch stream where I bring on guests and they teach me something about web development, core web tech and/or accessibility. So if you've seen me around, that's likely why.
Anthony
We've gotten to know each other through the React Podcast Discord, we actually just talked with Chan yesterday. You have now spun off your Twitch channel, Some Antics, which I really like I think that's a really great name for an accessibility channel.
I was really excited that you were doing it because we had already been talking about doing some sort of accessibility themed stream for RedwoodJS. We got to do that for Some Antics 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 interesting.
Ben
So in terms of that stream, the main influence would be a Jason Lengstorf and his Learn with Jason show. For viewers, or I guess 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 just a wide variety of the web development world. It's such an open, inviting community, which I really appreciate.
I've been trying to sort of, I don't want to say like, ape that whole thing. But, I've been inspired by that approach, 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 just teach me and teach the audience a new thing 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 and 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.
Anthony
I'd be really curious to hear, how did you first get it programming? Like what was the first kind of program you ever wrote or your first programming language or your first website? Anything like that?
Ben
Okay. I have always been a computer guy. This goes back to even as an infant, as a toddler. One of my favorite like 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 them off of that." They turned the computer off and you know, this was in the day where all computers by default had towers and everything that people weren't really using laptops.
They turn the computer off and they stuck a post-it note over the power button on the tower. If it 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, turn the power on and started using the computer. Just really and truly computers have been a big part of just me growing up. They were a big part of my childhood.
I actually made my first website back in like 4th and 5th 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, perhaps, 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, a childhood full of computers.
Anthony
Yeah, it definitely resonates with, I'm sure, 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 this is FSJam, fullstack 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, I see, of having a whole end to end understanding of the project.
You need to know where hangups could be or where faults could be. Accessibility can be something that tends to get kind of shuffled around to different departments or different developers and there's not always the investment that can be made into having just an accessibility expert. I think it's really important for people who are working in these kinds of spaces to make sure that they are thinking of accessibility and that they have a mental model about accessibility and they have the tools they need to make accessible websites.
For me, I think of it in those two kind of buckets, I think of the mental model. Of how do you think about whether your site or your app is actually accessible and then the tools you use to test and to verify, and to improve the accessibility of that site. So do you think that's a good framing and then which one would you like to kind of go into from there?
Ben
Yeah, I think that's a fantastic framing. You really do have to consider both the actual accessible experience and the process that you're going to take to get there. I would give the caution that in my experience, accessibility tends to fall apart not so much in the technical execution but in the process. Inaccessible sites are the product of processes that don't facilitate accessibility.
Anthony
Great and can we go into that? What are the processes that are failing us and how should they be altered?
Ben
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 a design team and that design team is going to share some of the responsibilities. They are 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.
Developers, and this is increasingly likely in a full-stack world, might be responsible for that testing yourself, but all of these roles have to be met. It's not just, it's 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.
Chris
One of the things, things that I always like to think of when it comes to accessibility is a spectrum. It's not just binary. Some people are colorblind. When you put a warning sticker and a success sticker, they may look exactly the same to some people or another instant is mouth support. Could be limited when they prefer to use a keyboard.
So could you tab down the entire page, you know, to the section you need. As I see it, yes, we could all always be better accessibility, but it's not necessary. Like how do I complete accessibility? How do I take it off? It's more, what am I doing to try my best? I believe if you're trying to even just do something is better than nothing.
Ben
I think there's a lot of truth to that. And I think there's a lot of truth to, as you're kind of talking about this spectrum of ability. When you're first coming to learn accessibility, and the importance of accessibility, you'll often find resources that break down disabilities into several categories. Those categories, for instance, might be vision impairments, like blindness, low vision, colorblindness, etc. 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, live loss and paralysis. There's cognitive disabilities as well, learning disabilities and dyslexia and, and stuff like that. The thing about those categorizations as well, I think they can be helpful for developers to step outside of their bubble step outside of their comfort zone. And imagine what navigating the web, what that experience 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 a 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've actually have three disabilities, cause things are comorbid and they build on top of each other.
While disability is not one concrete experience, breaking it down into those categories of visual, auditory, cognitive motor can be a helpful way to start approaching experiences. We start breaking things down in terms of how might someone with those experiences navigate the page. Do y'all mind if I go through a quick exercise with you?
Anthony
Let's do it, yeah.
Ben
All right. Y'all have seen forums before. I'm pretty confident you've seen forms before. Um, and 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. And once you start typing in that form field, the placeholder text goes away. Based on kind of the like categories of disabilities, the visual auditory, cognitive motor, what are some possible access issues you might, uh, think of with a placeholder.
Chris
You could on the placeholder put a pattern. It needs to be two letters. Space, two letters space, two lies like a sort code. And 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 place holder becomes the label. When you start typing, I hate them. Please everybody stop doing them.
Ben
There are tons of things to side eye about that. But even if we're just talking about like the native placeholder, right? Like we're, we're talking like Symantec input element with type equals text and we're using the placeholder attributes. What are some possible access issues that we might get from that?
Anthony
An issue is as soon as you start typing and you lose the placeholder, then if you don't remember what it says, you like get lost. So I know people who have like, Attention disability type. That could be a problem.
Ben
Absolutely, or people with short term memory loss. We're providing a 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. 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 they're nightmarish for color contrast.
Anthony
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 is. The types of considerations you can make before a single line of code is written. And so what are some of those considerations you can make? And how can we design for accessibility before we even start coding?
Ben
When we work in 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 kind of like second highest group that 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 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, foreign validation often requires, uh, we, we show, Hey, you filled this out correctly with green and you filled this out incorrectly with red. Well, for someone who has red, green colorblind, those colors are likely the same color to them, or very similar. Right? So making sure that color isn't the only indicator of information is hugely important. Also keyboard behavior, focus management is absolutely.
One of the things that I think it's forgotten about is if you're opening modals and sidebars and dialogues, where should the focus go? Where should we put the users' cursor so that their screen reader announces where they're at and where should it go when you close that experience? And all of these things need to be decided before you ever write a line of code. And ideally if you're in an organization that has the design team to support it, Ideally that should be the design team that's documenting those requirements.
Chris
I've heard the iPhone is very good at accessibility. iOS is done by Apple. Where does the most impact come in accessibility: from an OS and then an app or from the app and then the OS? Does picking a browser matter more in terms of accessibility than the website?
Ben
That's a fantastic question. And the answer is specs are great. I love specs. So 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 us to the operating system in such a way that strangers can pull from and figure out like 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. So if 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 browser just 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.
So this is just one way, like you have to write a meaningful page so that your browser can translate it in a way that's meaningful for assistive technology and all of these three things work together that 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 there they're usually adhering to specs that are put together by the worldwide web consortium, uh, specifically the web accessibility initiative team there they're conforming to those specs pretty well, decently consistently. So 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.
Chris
It's that question of how much you can control. You can control to support our year 11 or not. And you can control to support accessibility or not just things that 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 rabble as like built into the website.
I'm dyslexic myself. For so much of my life, I thought dyslexia was at disability, but now I view as a and I removed 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 properly, fully navigate a website using your keyboard, small things like that is things that you only get when you view the abilities from disabilities.
Ben
I think there's also something to be said for the web by default is pretty accessible. If you're using semantic elements you're a large chunk of the way there. This 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, etc.
I really, truly believe that accessibility is good design, no qualifiers there. Accessibility is good design. It does help everyone, right? Everyone benefits from a more accessible site. Chris, what you're referring to is an effect that in the disability community, we call the curb cut effect. Back in, I want to say it was the sixties, 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 the downtown Berkeley.
The city implemented these curb cuts, Chris, I believe they're called pram cuts or pram 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 on 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 like straight carts, just bring stuff along. Like many people were able to benefit from this. A modern day example of curb cuts might be closed captioning. So I mentioned I'm hard of hearing.
I often use captions as a way to just 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 who 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. 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. Like at its heart, accessibility is advocating for disabled users. If we de-center 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.
Chris
I wish I could have closed captions for real life. My girlfriend tries to talk to me, but if there's a washing machines going, I can hear what she's saying, but I can't comprehend what she said. It's just like, I can't explain it. It's so weird.
Ben
The single biggest use case, for me, for closed captions has been watching Dr. Who. Love Peter Capaldi but his accent was difficult for me to comprehend. It was a very, very strong accent. And yet I need my British Sci-fi, you know?
Anthony
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 we have a site that we've done our best to design. 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?
Ben
I think one of the easiest for people to wrap their head around is keyboard navigation. I think many developers, I'm not going to make this like 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 a form 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, right? When the focus order hops around or when something we expect to be focusable or keyboard navigable isn't focusable or keyboard navigable. Keyboard navigation is one of those things that I think for many of us will come pretty familiarly and is something that I think 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, by necessity they become power users of their assistive technology. They have to, that's how they navigate the world. You have to get good at it. As developers who are committed to meeting accessibility needs and committed to meeting the needs of people with a wide variety, with a wide array of experiences, we have to test for those experiences.
So get familiar with screen readers. If you're on Windows, the screen reader that you're going to want to look into is JAWS, which is a paid screen reader. It's quite expensive, that's the most commonly used streaming, There's NVDA, which is free and I believe open source. If you're on Mac there's VoiceOver, which is built into the operating system. There are screenwriters for mobile operating systems as well. You can find those with a quick Google search.
But by and large screen readers are going to have several navigation modes. Tabbing. The focus that you're used to, focus implies interactivity. If you can tab to something that implies that it's interactive, so you should be able to tab to, for instance, links, buttons, and foreign 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, "just read everything" mode. So if you want to skim through all the static texts and the images and stuff like that, you're going to want to find whatever your screen readers virtual cursor is.
And the next thing is that screen readers, and this is something that I think a lot of developers don't actually really know about screen readers, most stream readers come with a way to hop between different elements of the same type. For JAWS it's a plethora of keyboard shortcuts, with Mac it's 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. Screen readers provide whether it's the rotor or the keyboard shortcuts. They provide ways to skip through parts on the page to get to the parts that you care about really quickly.
That can often be very unintuitive. Like, we as sighted people, the three of us on this call, we 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. So figure out what your equipment for the reader that you're testing with 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, I suspect. But there are a plethora of tools to use and 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, etc, but I think you have to do all of the above to really, truly get a holistic understanding of the experience.
Chris
What's your opinion on tools, like UserWay where it's like a SAS product to do accessibility for you? Is that a definitely no or is that just like a bandaid on the issue?
Ben
I have to be very careful about this. You're talking about tools called accessibility overlays for listeners who might not be familiar. You might go to a site and sometimes see 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 texts large, stuff like that. Or we can read your page aloud.
The way I will word this is, Accessibility experts do not trust accessibility overlays. The truth is many of them do not do anything that the user would and already have the assistive technology to do, right? Like they're simulating a screen reader, but a simulated stream 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 accessibly 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 lawsuits were going to get more and more common and they started getting venture capital checks their way. I don't believe that they provide anywhere near the support for accessibility that just fixing your dang site would do. And I don't believe that they ever can.
Chris
It's interesting. If there's anything I'm proud about being British is our government websites. The UK government has that UI totally open on GitHub. I hear for accessibility it is really, really good. It's called like govuk-react. I think it is. But that's supposedly like really good for accessibility as that was one then main goals as like, how do you fully make something that everybody needs to use? Because to give the backstory that I do know before.
GOV.UK standardized that interfaces. Every single government agency had that own website, own forms, own styles, own system. All of it never spoke the same style or language. 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 is next to none. Every time I use it. It's great.
For example, in the UK right now, we have a thing called a census. So that's every single house old in the country. You have to go onto the centers 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 them things, every single person in the UK has to do it. It's a really interesting thing to look up about the gov UK and how they achieved. I believe a very good accessibility record. Well, I'm not the answer about that.
Ben
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 was a design system called grommet. I guess it's more of a component library than anything, but I think design systems and/or component libraries are a powerful tool.
They can standardize accessibility practices across a product and across an enterprise. I would encourage you, if you're working in the design space in your company, if you're working in part of a larger enterprise, to 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.
I think this is one of the recurring things I learned from accessibility. 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.
Anthony
Do you ever use the accessibility score from lighthouse? Because lighthouse gives you a whole bunch of metrics for like performance, SEO, and one of them is accessibility. I've always wondered about that metric and what goes into it and if it's useful to optimize around or not.
I once saw that we had deployed a Redwood to Netlify and Vercel, it was the exact same app deployed from the exact same code base and each deployed project got a different accessibility scores. I thought that was really interesting. The whole lighthouse thing is kind of a black box to me. I didn't really know how to drill into that, so I'm curious if you know anything about that.
Ben
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-y opinions in there, but I don't know what specifically might've caused your discrepancies that you were seeing there. But I think 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 an accessibility expert.
I would hope that would be part of the expectation, but the truth is there are so many things on our plate. So many things can slip under the radar. One of the really important things is figuring out how to surface accessibility issues that might be lying latent in our app. I think automation fills a very powerful role. Deque system the company puts together the axe DevTools extension. They have just wrapped up their axe-con, 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 2000 audits that Deque performed 57% of defects are surfaced by automation. And the bulk of these are going to be things that you can pretty easily calculate with a machine, right? 30% of all defects were color contrast issues, according to this report. And I can put the report in the show notes for y'all cause 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 texts meet color, contrast requirements? That is something that to test that manually would be a waste of your developer or testers time. I'm really good at checking. Do all images have an alt attribute, but something that computers can do really quickly, it would be a waste of your testers time. You want accessibility engineers thinking about higher order problems. Like. Complex interactions.
I do want to talk about the limitations, though, of automation in this regard. We might be asking ourselves, well, why only 57%? Why can't the tools find 100%? Why can't they find 90%? Like why 57%? And 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 texts depending on what page it's on.
We could have, for instance, the example of 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. It might just simply be president George Washington. It's 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. It might be all you have is 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 brush strokes.
It's very contextual and 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 like low level, easily calculable binary pass-fail stuff so that your accessibly engineers can focus on solving the bigger, harder, more contextual problems.
Anthony
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 is really important for developers to keep in mind?
Ben
Accessibly is important and there often times aren'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 web.dev or Deque systems or the a11y project. That's a 1 1 Y 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, 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. Take some time to figure out what you 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 app?
Anthony
Thanks so much, Ben. I've really enjoyed getting to pick your brain in this episode, but also over the many months that we've gotten to know each other. I highly, highly encouraged people to check out both your streaming show and also your blog. You're one of these developers out there putting out this really fantastic accessibility content that I think people should know about. Why don't you also make sure that people know where they can find your stuff and how they can get in contact with you?
Ben
So, first of all, you should follow me on Twitter @bendmyers. You can also find me on my blog at benmyers.dev where I post mostly about accessibility stuff. And then finally, every Tuesday on Twitch at twitch.tv/someanticsdev where we will be sharing, just learning, following along with core web technologies, as well as with accessibility. It's been a great time and I would love to see y'all there.
Chris
My final question is simple. Yes or no, can beautiful websites still be accessible?
Ben
Yes.
Chris
There you go. Simple.
Ben
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.