Accessibility and Web Standards with Ben Myers
Ben Myers joins JavaScript Jam to discuss web accessibility basics, advanced resources, CSS framework pitfalls, and single-page app routing challenges
Episode Description
Ben Myers joins JavaScript Jam to discuss web accessibility basics, advanced resources, CSS framework pitfalls, and single-page app routing challenges.
Episode Summary
In this JavaScript Jam Twitter Space, Anthony Campolo hosts Ben Myers, a front-end developer at Microsoft who specializes in accessibility and semantic HTML. Ben shares his personal connection to accessibility as someone who is physically disabled and hard of hearing, then walks through recommended resources for developers at every level—from beginner-friendly sites like WebAIM and the A11Y Project to advanced resources like the W3C ARIA GitHub repo. The conversation touches on Eleventy's 2.0 release and its philosophy of minimizing client-side JavaScript, before a listener question about writing alt text for complex diagrams leads to a practical discussion about providing both concise alt attributes and detailed in-body descriptions. Ben critiques how CSS frameworks like Bootstrap and Material Design popularized inaccessible design patterns, and argues that tying CSS selectors to ARIA states can help developers enforce accessibility by making interfaces only look correct when they behave correctly. The discussion culminates in a deep look at how single-page application routing is fundamentally broken for screen reader users, since client-side navigation doesn't trigger the document-load announcements that assistive technologies depend on. Ben closes by promoting axe-con, a free virtual accessibility conference where he'll be speaking about how CSS can mislead screen readers.
Chapters
00:00:00 - Introduction and Live Captioning Setup
Anthony Campolo opens the JavaScript Jam Twitter Space and welcomes Ben Myers, who has set up a live captioning system for the event. Ben explains the technical details behind his approach: he's using Chrome's built-in speech-to-text engine through a site called Web Captioner, routing the Space's audio through his computer speakers and feeding it back as microphone input to generate open captions via a shareable link.
This improvised captioning solution sets the tone for the episode's focus on accessibility and inclusion. Ben notes that Twitter Spaces previously offered built-in captions but no longer does, making workarounds like this necessary. The setup itself becomes a natural segue into the broader accessibility discussion that follows.
00:04:20 - Ben Myers' Background and Accessibility Passion
Ben introduces himself as a front-end developer at Microsoft working on the Microsoft Learn platform, with deep expertise in accessibility, web standards, and semantic HTML. He shares that he is physically disabled with limb abnormalities and is hard of hearing, making accessibility a deeply personal subject. He also mentions his streaming show Some Antics, where he brings on guests to explore building great web experiences.
Ben emphasizes that many front-end developers genuinely want to build inclusive products but simply don't know where to start. His content creation work—blogging, streaming, and community engagement—is aimed at bridging that gap by making accessibility hands-on and approachable rather than abstract and intimidating.
00:09:16 - Accessibility Resources for Beginners and Experts
Anthony asks about good starting points for learning accessibility, and Ben recommends several tiers of resources. For beginners, he highlights individual bloggers like Emma Dawson and Elena, the WebAIM website for its approachable communication style, and the A11Y Project's checklist as a springboard for deeper investigation. He cautions against treating checklists as one-and-done tasks, urging developers to understand the context behind each recommendation.
For more advanced practitioners, Ben suggests following the W3C ARIA GitHub repository to see how specs and guidelines evolve through active discussion. He also points to TPGI (formerly the Paciello Group) for deeply technical content, Adrian Roselli for an excellent middle ground, and Scott O'Hara as someone both newcomers and experienced developers can learn from.
00:15:35 - Eleventy 2.0 and the Static Site Generator Philosophy
The conversation pivots to Eleventy, which Ben describes as a classic static site generator focused on transforming Markdown and data into plain HTML without shipping heavy client-side JavaScript. He notes that Eleventy recently reached version 2.0 with improvements to its dev server, though he admits he hasn't been deeply involved lately. He also mentions Zach Leatherman's ancillary projects like WebC.
Ben frames Eleventy's evolution as a compromise with broader industry trends like islands architecture, popularized by tools like Astro. While Eleventy's core ethos remains reducing JavaScript, it's beginning to incorporate patterns that acknowledge the need for selective interactivity. The key distinction, Ben argues, is that Eleventy aims to avoid shipping entire frameworks, unlike approaches where you still send a full runtime over the wire even with islands.
00:22:56 - Writing Alt Text for Complex Diagrams
Listener Lucia asks about writing alt text for complex backend architecture diagrams, where a thorough description can become so lengthy it defeats the purpose of the visual aid. Ben recommends a two-layer approach: provide a brief, surface-level alt attribute describing what the diagram is, then follow the image with detailed paragraph-form descriptions in the body of the page.
Ben explains that this strategy benefits not just screen reader users but anyone who struggles with visual flowcharts, and it also provides resilience when images fail to load. He notes that the understanding of alt text has shifted over time—historically there was a long description attribute for extended image descriptions, but as that was deprecated, developers have increasingly crammed longer descriptions into the alt attribute itself, which isn't ideal.
00:29:14 - The Evolution of Alt Text and Design System Pitfalls
Ben traces how social media platforms shaped modern alt text practices by exposing alt fields without context about providing multiple levels of description. He then broadens the discussion to CSS frameworks like Bootstrap and Material Design, arguing that many popularized design patterns were never built with accessibility in mind. The trend toward minimalism—such as replacing form labels with low-contrast placeholder text—emerged from these frameworks and persists even as developers move away from them.
Anthony asks whether any CSS frameworks get accessibility right, and Ben acknowledges that progress has been made but points to a fundamental tension: CSS frameworks intentionally decontextualize styling, while accessibility is deeply contextual. He critiques the wave of component libraries that promised anything could look and behave like anything, noting this directly conflicts with semantic HTML principles.
00:36:24 - CSS Classes, ARIA States, and the Limits of Styling
Ben articulates his nuanced critique of utility-first CSS approaches like Tailwind, arguing that CSS classes alone are an insufficient API for user interfaces. When developers rely too heavily on visual styling, they tend to neglect semantic markup, ARIA attributes, and JavaScript interactions that are essential for accessibility. Since most developers are sighted, there's an inherent bias toward making things look right without ensuring they behave correctly for assistive technology users.
His proposed solution is to tie CSS selectors directly to ARIA states—for example, styling based on the aria-expanded attribute rather than a custom class. This way, interfaces only appear correct when the underlying accessibility semantics are properly implemented, effectively using visual design as an enforcement mechanism for accessibility compliance.
00:43:29 - Single-Page App Routing and Accessibility
Ben and Anthony discuss one of the most significant accessibility challenges in modern web development: client-side routing in single-page applications. Ben explains that browsers and screen readers were designed around full document loads, which flush announcements and reset focus. SPA routers that swap DOM elements without triggering a real navigation leave screen reader users unaware that a page change occurred, and shared elements like nav bars can trap focus on the previous link.
Ben references Marcy Sutton's user testing work with Fable Tech Labs and notes that despite her research establishing best practices, most major client-side routers still haven't fully implemented the necessary feedback mechanisms. Nick Taylor joins to ask why browsers haven't made the History API's pushState more accessible, and Ben agrees this remains an open problem, suggesting the community needs a shared manifesto defining what accessible routing requires.
00:56:38 - Closing Remarks and axe-con Promotion
Ben wraps up by promoting axe-con, a free virtual accessibility conference hosted by Deque Systems scheduled for March 15th and 16th. The conference features multiple tracks covering development, design, business, and marketing. Ben will be delivering the final talk in the developer track, presenting on how CSS can be used to mislead screen readers—a talk he describes as both surprising and entertaining, using humorous examples as a springboard into browser and OS internals.
Anthony thanks Ben for joining and reminds listeners that JavaScript Jam runs weekly on Wednesday at the same time. He invites anyone interested in being a future guest to reach out via DM, closing out an episode packed with practical accessibility guidance and thought-provoking critique of modern web development practices.
Transcript
00:00:28 - Ben Myers
Howdy. Howdy.
00:00:29 - Anthony Campolo
Hey, how's it going, Ben?
00:00:32 - Ben Myers
It's going. Let me see if I can actually get this audio to play on my desktop so I can run those captions.
00:00:45 - Anthony Campolo
Yeah, I'm grabbing the link for that right now.
00:00:50 - Ben Myers
Cool. Yeah, captions seem to be working on my end. Yeah, I actually did just tweet something out, so if you wanted to pin that tweet, that might be a good way to get the word out about these.
00:01:02 - Anthony Campolo
I can do that. What's up, Luc? Boom. Okay, welcome everyone to JavaScript Jam. Super happy to have my good friend Ben here. He actually set up this cool captioning thing. I'm curious, how exactly is this captioning working? Still with us, Ben?
00:02:06 - Ben Myers
It turns out I need to unmute my mic. That is apparently important. Yeah, so just a quick caveat here on the captions. I see that Anthony's pinned the tweet with a link to the captions in the Space. Twitter Spaces once upon a time offered captions. However, Nick Steenhout brought to my attention that it no longer does that. So I've jury-rigged this solution. It's actually quite interesting. Chrome, Chromium, ships with a speech-to-text engine, and so there's a website called webcaptioner.com that will basically just take whatever input is coming into the mic and spit it out as captions, open captions specifically. The idea is like, oh, if you're streaming or sharing your screen, you might have a little pocket window in the corner of your screen with your captions, or it could be an OBS source. Because I do streaming of my own, I happen to have some tooling, some software installed, that'll audio-loopback some stuff. So basically what's happening is I am playing this Space through my computer speakers and then using my computer speakers as the microphone input to Web Captioner, and I have a little share link.
00:03:28 - Ben Myers
Might be worth actually putting out a little blog post about that, just in case folks need to do something like this in the future. I feel like this dovetails really well with today's topic.
00:03:41 - Anthony Campolo
Yeah, it's super fascinating how you were able to rig this together. I'm looking at it right now as it's going, and it seems like it's doing pretty good in terms of actually capturing. Let's see. Yeah, that's really cool. Why don't you go ahead and introduce yourself and let our listeners know who you are? And for everyone out there listening, just be aware that this is an open mic. If anyone wants to come up and ask questions, you're welcome to. Me and Ben will be chatting about various topics in Ben's purview, and if anyone wants to come up and pick his brain, you're more than welcome to.
00:04:20 - Ben Myers
Yeah, thanks for the little segue there. So my name is Ben Myers. I am currently working at Microsoft as a front-end software developer on the Microsoft Learn platform. You might have previously known Microsoft Learn as Microsoft Docs. I have a huge passion for front-end development, but specifically my specialties are around accessibility and web standards and semantic HTML. I recognize that this isn't a video format, so people can't exactly see me, but I'm physically disabled. I've been disabled all my life. I have some limb abnormalities and I'm hard of hearing. So accessibility is a subject that's near and dear to my heart because it's personal for me. And I'm really passionate about providing great user experiences for people. And I'm also really passionate about helping developers build really great experiences. I've found in my years as a software developer that oftentimes you can find people who are willing to be champions for users, right? People who are in the business because they want to build things that people can and will use. And I think accessibility is such a great way to really hammer that mission home.
00:05:43 - Ben Myers
So I allegedly blog about accessibility at benmyers.dev. I also allegedly stream on Some Antics. I host a show called Some Antics where I bring on guests from around web dev and web design to teach me something about building great user experiences for the web. I actually see a couple of former guests in this chat. Some Antics has been on a bit of a break. I will likely bring it back sometime in March, maybe, but I've just had a lot going on, needed to take some time to set aside for work work and personal work and stuff like that. So hopefully Some Antics will return. But in the meantime, you get to settle for me hijacking some Twitter Spaces.
00:06:34 - Anthony Campolo
Oh yeah, and also pinning some links to your homepage and to someantics.dev. Yeah, Some Antics is a really fantastic resource even though it's not currently airing right now. There's a huge backlog of excellent episodes, many of which I am in. And as Ben said, lots of people who are hanging out here have also been former guests. You want to give some of the topics you've covered and some ones that have kind of stuck out in your mind as favorites?
00:07:07 - Ben Myers
Yeah. So again, this kind of hits on it. I generally believe that a lot of front-end developers really care about building good user experiences and just often don't know where to start. And so with Some Antics, my goal was really to bring things to the hands-on level, right? Bring things to viewers in ways where it's a friendly chat with folks from around the space. So we've had various streams where, for instance, actually I see Lucia in the chat, and Lucia was on one time just showing how to use automated accessibility testing tools, for instance. Homer's been on as well. Homer, man, I really enjoyed chatting with Homer. We chatted about accessibility and design systems and specifically championing those causes within a company. Y'all, if you ever get a chance to speak with Homer, just speak with Homer. Homer's great.
00:08:11 - Anthony Campolo
Love Homer.
00:08:13 - Ben Myers
But yeah, so we've covered tons of subjects. A lot of times it looks a lot like, let's build a small thing and let's do so in an accessible way, or let's spend the hour playing with some tool that you likely haven't played with. I had one stream that I did with Eric Bailey that was about forced-colors mode, which used to be known as high-contrast mode. And it was just a matter of pulling up a page in forced-colors mode and just seeing, hey, yeah, this looks mostly right, but there's a few things here and there. Let's remediate it. And that's just really what I love. It's kind of like the first step of showing you the extent of what you might not know about the space. So yeah, if that sounds interesting to you, when it returns, it is Tuesdays at 2 p.m. Central Time, which is 12 p.m. Pacific Time, at twitch.tv/someanticsdev.
00:09:16 - Anthony Campolo
Yeah, yeah. One of the things I really enjoy about the show is that, as you say, it's very hands-on. And I find with accessibility and things where it's really interaction-based, even with a really well-done blog post, it can be hard to get all the information from that. And actually seeing people work with the tools directly is really, really useful. I'd actually be curious because I found that when I was first trying to learn accessibility, people would point me to the specs and the things that are required to be compliant in very specific ways. But I found that it could be very dense and hard to get into. Are there any good, simple beginner resources that you would point people to beyond the stuff you've done on your own stream?
00:10:05 - Ben Myers
Okay, well I would hope that my blog post would fill that gap. Yeah, it's really interesting, the spectrum of what's out there. And also I will say, since I've entered the content-creation world around accessibility, tons of people have popped up, and I think that they're providing this information in even better ways than I can. Someone I want to shout out, actually, who's in this Space is Emma Dawson. Emma has been regularly tweeting out accessibility tips that are just hugely actionable, just bite-sized bits with a really impressive cadence. So following Emma is absolutely something I recommend. I see Elena applauding. Elena's in the same camp. Elena is also someone to follow for a lot of those really actionable, bite-sized pieces. So these are people who are listening today, go follow them, because these are people who are doing this with even more cadence than I am. But there's such a spectrum of resources, and picking and choosing the resources that work for you and what you need is so important, right? Because I agree, going to the specs is incredibly heady, and especially the newer success criteria are a beast to work your way through.
00:11:34 - Ben Myers
Like Anthony, have you had a chance to read the new specs around the requirements for focus indicators? There are like four different categories of ways that a focus indicator could be compliant. It all has to do with basically how much of the perimeter is used up and how thick these outlines are, or what the adjacent colors are. It is a lot. And when you're just starting out, I think it is impenetrable, right? And so I really like blog posts, especially blog posts written on someone's personal blog, because those are usually of the nature that they have a specific problem, a specific context that they're trying to address, and they're going to tell you about it. And oftentimes they're going to tell you what they tried and what didn't work and what ultimately worked and why they went with what they went with, letting you see kind of the full process, whereas specs aren't the full process, right? They are the final guidelines, more or less, right? And that is just what they're trying to be. They're not really trying to walk you through a whole thought process.
00:12:51 - Ben Myers
And so, yeah, just in general, finding bloggers, like personal bloggers, I think is so, so huge. And I think that there are a couple of other organizations out there that are putting together some excellent resources that I find very approachable. One that I would recommend is WebAIM. That's W-E-B-A-I-M, I think, webaim.org. I think that their website is a masterclass in how to communicate the nuance of accessibility in such a way that it's still approachable for someone who's very unfamiliar. Also, in the camp of if you're looking to just get started and don't know what to do, there's a website called the A11Y Project, and they have a checklist. I think you can get to it at a11yproject.com/checklist. I forget. I generally am very careful when it comes to checklists because I think that we oftentimes treat it as a one-and-done type thing of like, oh, I just need to go through these very surface-level things. But what I encourage is, if you find a checklist that seems helpful, investigate every item in that checklist. See if you can understand the context that those things are being recommended to you in.
00:14:14 - Ben Myers
And that's a good springboard toward really, really trying to understand the scope and breadth of accessibility so then you can work your way up to perhaps the more technical resources, such as those shared by TPGI in some contexts. Adrian Roselli, I find, is an excellent middle ground. Someone that I think newcomers and experienced developers alike can learn so much from is Scott O'
00:14:44 - Anthony Campolo
Hara.
00:14:46 - Ben Myers
That's my crash course in people that I'm learning from and people I would recommend for people at various stages.
00:14:56 - Anthony Campolo
Sweet. I'm grabbing those links and getting them up there one by one. Yeah, this is really great stuff, and I'll be digging into some of these. I'm looking at Scott's right now, and I think you had shared his ChatGPT blog post with me.
00:15:14 - Ben Myers
Yep.
00:15:16 - Anthony Campolo
Yep. Yep. Very cool. Yeah, awesome. Great. So for anyone out here who already is kind of an accessibility expert, is there something that you would say is like advanced accessibility, what someone who's already kind of learned the basics should do next?
00:15:35 - Ben Myers
Ooh, I think that at a certain point you start getting involved in the specs. You start following the specs.
00:15:46 - Anthony Campolo
I think
00:15:48 - Ben Myers
It is incredibly interesting. Following W3C's GitHub repo for the ARIA specs, that is a very fun repo to follow, just to see the conversation on what's recommended in ARIA, what the guidelines should be, how things should be implemented in browsers, implemented in assistive technologies. So if you're interested in seeing what the future of accessibility looks like, that is absolutely a place I would check out. I also think that there's a good number of blogs and resources that tackle very, very specific technical stuff. I mentioned TPGI, which is a resource that was formerly known as the Paciello Group. I think that they do a whole lot of the nitty-gritty stuff of like, we're revisiting inline text-level semantic elements like the mark, insert, or delete elements just to see how the support is for these things. That's a good way to get very technical, specific stuff that maybe doesn't broadly need to be broadcast far and wide on a megaphone, but is still contextually good information to have for accessibility people. So yeah. Additionally, I would recommend, if there are resources that anyone in the chat is learning from that they want to recommend, please, just respond to the Space's
00:17:21 - Ben Myers
tweet with some resources you recommend because, yeah, there are so many people out there. I know I'm missing people. I know I'm missing so many people. And yeah, it's a very wonderful space.
00:17:38 - Anthony Campolo
Yeah, you're always good at throwing out lots and lots of references, I guess. Still need to grab that GitHub link, but I think I got everyone else.
00:17:47 - Ben Myers
Yeah, that would be here: github.com/w3c/aria.
00:17:53 - Anthony Campolo
Interesting. I found w3c.github.io/aria.
00:17:59 - Ben Myers
That is the draft spec, yeah. I think that's the draft spec.
00:18:04 - Anthony Campolo
Gotcha. Sweet. Awesome. Just a reminder for anyone who wants to hop up and ask questions, you are welcome to. I think if we want to pivot a bit, I'd be curious to hear a little bit about Eleventy and what's going on in the Eleventy world these days. First you should say, what is Eleventy, if everyone hasn't heard about it? And then we can kind of get into what's the hotness with it.
00:18:30 - Ben Myers
Yeah, so Eleventy is a static site generator. I say that phrase and people in their minds turn to tools like Gatsby, perhaps things that claim to be static site generators but still introduce a whole lot of overhead and still ship a lot of client-side code. Eleventy is perhaps in the classic school of static site generators in that you have content, you have data, you have Markdown, and you're just transforming it into HTML, good old-fashioned static HTML. And I made a bit of a name for myself in the Eleventy community a year or so ago when I published a blog post about a process that Eleventy has called the Data Cascade. And I actually haven't been quite so heavily involved in Eleventy these days. I've just spent less time on personal projects and on things like Eleventy. Eleventy is not my thing. I didn't make it. I purely advocate for it. But it was created by Zach Leatherman, who currently works at Netlify. And Eleventy just hit 2.0, which is fairly exciting. It comes with some improvements to the dev server that should make it easier to onboard. I know that there is a bunch of other stuff as well, but truthfully I've been out of the game for so long that I'm forgetting what all of it is.
00:20:02 - Ben Myers
I believe Stephanie Echols has on her Eleventy Rocks site a list of the things that are new to Eleventy. But what we're seeing a lot is this kind of, I would almost describe it as, a compromise with the industry, where for a while it seemed like the core ethos of Eleventy and tools like it is that, you know, static HTML, good. Minimize client-side JavaScript where possible because client-side JavaScript imposes larger bundle sizes, it imposes larger risk, it slows things down, stuff like that. If you can get away with statically rendering HTML, you can and should. That seems to be the ethos of it. Since then the industry has more or less been dabbling in other techniques, including islands architecture, I know is a big one, and stuff like that. This recognition that, well sure, we can reduce JavaScript as much as possible, but you still need pockets of JavaScript here and there, right? And so there have been a myriad of different approaches out there to get that to work. Some tools that are built around that idea, notably Astro, which I'm loving, by the way. Astro is fantastic. Would also highly recommend Astro.
00:21:23 - Ben Myers
But yeah, in addition we're seeing Eleventy starting to incorporate more and more of these things. Zach has been working on these ancillary projects that can slot really nicely into Eleventy, such as WebC, which is a way to... it's hard to describe, and without showing you it's very hard to articulate the use case for this, but it lets you, I'm going to hand-wave around this, serialize web components, stuff like that. It's interesting.
00:21:59 - Anthony Campolo
Sounds fancy.
00:22:00 - Ben Myers
Yeah, very fancy. Again, I haven't had a whole lot of time to play around with these things, but yeah, this is, I think, an interesting direction to see Eleventy take. The ethos is still very much so, we need less JavaScript. But how do you do that in a way that... because, I mean, when we talk about Astro, right, and Astro is doing its islands architecture and stuff like that, if you want pockets of interactivity, you still end up shipping a framework, and that's still sending a hammer over the wire. It's still a sledgehammer of an approach. It's just that you can kind of cheat yourself in when that gets shipped or how many client-side JavaScript components are shipped as well. So Eleventy still very much so has got this ethos around not sending a whole bunch of JavaScript.
00:22:56 - Anthony Campolo
Awesome. It looks like we got Lucia up here to ask a question.
00:23:01 - Lucia
Yeah. Ooh, excuse me. Hi, Ben. Hi, Anthony. So I have an accessibility question. I've been working on advocating around a lot of backend technologies recently, and in any backend technology you're going to see these rhizomatic diagrams with all these nodes and these lines between them. And I just have the hardest time writing alt text for that because it seems like the alt text almost defeats the purpose. By the end of it, you'll be like, so at the top you have five red blocks, and then there's an arrow from one going down to... on the bottom left there's a purple block... and the words just become very tedious. And the point of the visual aid for people who can use visual aids is to make it a little less tedious to understand the concept, right? So I was wondering if either of you have any ideas for solutions for that scenario.
00:23:56 - Ben Myers
Oh, that's tricky. Yeah, man. Okay. How best to approach this? So the problem that you're describing here is you've got a massive diagram, right? It's very complex, and to be able to meaningfully describe it, you kind of defeat the purpose of the diagram, right?
00:24:20 - Lucia
And imagine that, given that the diagram has a degree of complexity, but it is actually a clear diagram, right? I mean, that's hard enough right there.
00:24:31 - Ben Myers
But yeah. So I would be inclined, alt-text-wise, to... because I think as time has gone on, the understanding of what constitutes alt text has kind of shifted. It used to be that there was a sense of, like, you could provide a brief, succinct alt text, and then you could provide what was called a long description, which is the most creative name possible, right? But basically you could provide a very surface-level visual interpretation of what was being provided, followed by a much more detailed explanation. And so your alt would be something like, you know, flowchart describing a request flow through X, Y, and Z services, right, without necessarily going in depth into whatever every flow is. But then I would still recommend describing in paragraphs after the image what the diagram contains. And the reason for that is that, I mean, images are hard, right? Images are very hard, and your image might fail to load. For instance, even people who are not as enmeshed in the developer space, and even people who are, may still struggle to read flowcharts.
00:26:06 - Anthony Campolo
Right?
00:26:06 - Ben Myers
Like, tons of people could benefit from having a more fleshed-out description kind of outside of the metadata of the image. So that is probably how I would handle this: just providing a very surface-level alt text, like literal alt text, alt attribute there, and then follow it up with text that describes the image in immense depth. And I would actually consider that a usability win. These two things can complement each other, right? Some people would probably prefer to look at the image and make sense of things. Some people probably would struggle with that. Even if they are capable of visually seeing the image, they may still prefer things broken down in words. I don't know. Text is kind of the universal medium, so where possible I default toward having more text. Does that help?
00:27:01 - Lucia
So, yeah, yeah, the recommendation would be don't say, and here is this diagram that explains it, and then don't explain what's actually going on behind the scenes.
00:27:11 - Ben Myers
Right. It would be, take a look at this diagram that demonstrates the flow of this request through these services. Then you have the diagram, and the alt would be something like, you know, flowchart of a request through X, Y, and Z services. And then after the image you'd have paragraphs that are like, in the above diagram you can see that the request first hits the authentication portal, or whatever. I don't know, breaking it out like that. I still think that would be probably the most broadly usable, and it's also the most resilient because again, images might not load or something like that.
00:27:52 - Lucia
Right. Like most accessibility things, it just ends up being good design. Thank you, thank you for that guidance. I appreciate it.
00:27:58 - Ben Myers
Absolutely. By the way, again, I don't want to make out like I am the end-all, be-all of accessibility. That is absolutely not my intent. I know that there are people here who have some really, really great expertise in this kind of stuff. So I would encourage, if you disagree with me, please feel free to request the mic or reply to the Space tweet with your context there, because I am just one guy sharing my thoughts on this.
00:28:32 - Anthony Campolo
Yeah. Something I appreciate, though, is that you always, I feel like, do a good job of sometimes giving me your opinion of what you think a quote-unquote best practice would be, and then also, if there's a kind of consensus view, not consensus, but something approximating a consensus, because it seems like you're very plugged in and you see these conversations going. And even though people differ on certain specific ways of implementing stuff, there are general guidelines that most people seem to agree on when it comes to accessibility. But I found that interesting, how you said that alt text is something that has kind of shifted over the years.
00:29:14 - Ben Myers
Yeah, I would almost definitely blame that on social media. And yeah, blame is kind of the word there because social media, as it's become more common to expose alt-text fields, most people's introduction to the world of alt text is through social media, right? It's through Twitter harassing you for not having included alt text on an image, or people passive-aggressively replying to your images with one of the alt-text bots that'll just spit out whatever the alt text was. But there is no context in those things of providing multiple levels of alt there. And the other thing too is that historically there was better HTML support for these kinds of things. There used to be a longdesc attribute that you could apply on images where the idea is you would actually pass it a URL to a web page, and that web page would contain the full long description just in text. Obviously we don't do that nowadays for a myriad of reasons, and I'm pretty sure longdesc has actually been super deprecated.
00:30:36 - Ben Myers
So it used to be this sense of like, people understood that alt was a very succinct description of, here's what it is. But nowadays, out of necessity, because there is no better tooling to provide descriptions unless you're very contextually, like in the tweet or something, giving a fully fledged image description, nowadays pretty much the only API we have for that is the alt attribute. And so as a result it has shifted to longer and longer alts instead of doing more and more in-body descriptions.
00:31:19 - Anthony Campolo
Right, that's interesting. Do you feel like there's any other things that come to mind that are like, used to be something that might be like a common thing to do, but because of the shifting APIs and shifting standards is no longer kind of like a best practice that someone may still be doing that they should update?
00:31:40 - Ben Myers
I mean, the web is full of those things. Like if you've ever used a table, for instance, for layout, right? That's what that is. But also, what I would say too is I think that we had a period of web development where it was very common to rely on third-party styles, for instance, third-party style libraries, CSS frameworks, whatever, right? Twitter's Bootstrap was one of the big offenders here, right? But then we also had Material Design and whatnot, right, kind of trusting that third parties or other companies would have had things settled, right? Like obviously Google is so big, they have to be doing something right, when in truth a lot of those Bootstraps and Material Designs and other CSS frameworks were not built with accessibility in mind. And this is pretty clearly demonstrable when you actually test it and run accessibility tests on things. And so kind of what I've been seeing over the past few years is, especially as tooling for creating your own self-serve design systems improves, people have moved away from CSS frameworks like Bootstrap or Material Design,
00:33:15 - Ben Myers
and yet a lot of the design patterns that we popularized as a result have stuck around. And a lot of these are not for the better. We have minimalism, which is one of those things where it can almost be a bit of a dirty word among accessibility people because we've all seen designs where, oh, we don't really want to show labels for these form fields, so instead we're going to use placeholders, and those placeholders are going to have abysmal color contrast, but we're going to recommend it because minimalism, it's better, right? And so I think as we move away from defaulting to those CSS frameworks, we've still had some of those design patterns linger. And I think that's something we're only now starting to dig our way out of and be like, oh, wait, actually no, Google didn't know best this whole time. So yeah, I think that answers it.
00:34:19 - Anthony Campolo
No, yeah, that definitely did. And I would imagine with a lot of those projects, you know, they are something that gets put out by the company and they're like, hey, look, we have an open source thing. And then it may not necessarily have like, ongoing investments and, you know, upgrades and new versions and bug fixes and all that kind of stuff. But I'd be curious, are there any CSS frameworks that you do think kind of get accessibility, right?
00:34:45 - Ben Myers
Well, I work on one at Microsoft, but it's largely designed for Microsoft Learn. I spend fewer days with CSS frameworks too. I tend to enjoy bespoke CSS as well. So, yeah, I would say that I know that a lot of work has been put into ensuring that CSS frameworks are more and more accessible. Not to open a can of worms, but I'm pretty sure that's a big thing for Tailwind, for instance, right, is ensuring that you have colors that can be used in contrasting ways, stuff like that. But I also think that CSS frameworks have a bit of a problem in general that makes them hard for accessibility, which is that CSS frameworks intentionally decontextualize something. But accessibility is so innately contextual a lot of times, right? It really matters where a thing is and what state it's in. And so there was a wave of, particularly early on in React's prominence, CSS and component libraries that, one I'm remembering is called Semantic UI, where there was kind of this notion of like, oh, anything can look like anything and behave like anything.
00:36:10 - Ben Myers
And kind of a core tenet of anyone who cares about semantic HTML is that not everything should look like everything, right? Like, sure, it can.
00:36:19 - Anthony Campolo
Yeah. Except the screen reader is like, what do I do with it? It could be anything.
00:36:24 - Ben Myers
Yeah, exactly. When you put too much stock in your CSS framework for solving things, you end up missing out on other things that are necessary to provide an equitable user experience. It's not enough to change the CSS class to make something red to indicate a warning sign. You have to also display an icon. You have to do some ARIA stuff. And this is my grand nuanced take on Tailwind and things like it, not specifically about Tailwind, but around the philosophy of Tailwind, which is that CSS classes by themselves are not a sufficient model for user interfaces, a sufficient API for them. And I worry about this notion of using CSS class as the omni-API for these things. I think when you do that, you de-emphasize the importance of things like semantic HTML and ARIA and the necessary JavaScript interactions for things. Because the majority of developers are sighted, we're going to be biased toward things that visually look right. So if you're not super diligent about things like your semantic markup and your ARIA and stuff like that, if you're instead leaning more heavily on things like CSS classes, including those provided by CSS frameworks, you can have things that look right but don't behave right.
00:38:06 - Ben Myers
So I have actually a blog post about this called Style with Stateful Semantic Selectors. But that's my grand nuanced take about things like Tailwind and really just CSS frameworks in general. I think they overemphasize the role of the CSS class in building a usable interface.
00:38:26 - Anthony Campolo
Yeah, now that makes sense. And we've talked about this, you and me, before, but if you try and kind of shove all of this into just doing it with CSS classes, what stuff are you missing that maybe you'd want to fill in with JavaScript?
00:38:43 - Ben Myers
Sure, you're going to have things like focus management. That is a really big one as we have more and more dynamic apps with modals popping up and all sorts of stuff. The nifty CSS-only hacks or whatever, like the famous or infamous, notorious perhaps, checkbox hack. I don't know if you've ever done that, but it's like using a hidden checkbox and then using the :checked pseudo-state to key off of whether to show or hide a sibling. Those are nifty hacks that ultimately fall super flat when it comes to how
00:39:25 - Anthony Campolo
else can I make CSS Turing-complete though?
00:39:28 - Ben Myers
Yeah, no, that is a fantastic question, and I'm going to again question whether it should be. We can talk about could, but I'm more about the should. And I like my CSS Turing-incomplete, perhaps. No, but yeah, you can do some really clever things, but ultimately user interfaces on the web are a combination of HTML, CSS, and JavaScript, and they all work together. They all harmonize. It's beautiful when they work well. And I think sometimes we get a little too clever with how CSS-only we could be, and we miss out on things like focus management if you open up this modal or whatever, open up a pop-up. And then also ARIA is a big thing. So ARIA states in particular, for those who are unfamiliar, ARIA is a set of attributes, there's like 36 of them, I think, last I counted. They don't add any functionality. All they do is curate how an element is exposed to assistive technology such as screen readers. And some of these are classified as ARIA states. Like, for instance, if you have a button that toggles whether some content is shown or hidden, kind of accordion style, you could apply aria-expanded to it.
00:40:54 - Ben Myers
And when a screen reader navigates to that button, if the contents aren't being shown, it'll say the contents of the button and then "collapsed." And then if you properly toggle that when you press the button, then it'll say the button contents and then "expanded" so the user knows what state that part of the page is in. And you can't do that with just CSS or just HTML, right? And you could have some sort of toggled shown-hidden state with CSS alone. You could hack your way to that. But it's incomplete, right? We recognize that there are experiences that could or should be conveyed to disabled people, real disabled people, who are missing a key context. And so we could be a bit more strategic about this. I see you've pinned my Style with Stateful Semantic Selectors article and very succulent blog post. Thank you, thank you. And one of the things I recommend is, if we recognize that in certain contexts, like aria-expanded, we need that ARIA attribute, that is a core part of providing an equitable accessible experience, then maybe we start with that.
00:42:13 - Ben Myers
We start with aria-expanded, and then we use aria-expanded in our CSS selectors. That way we ensure that our CSS is harmonizing with our HTML. We're providing everything we need. Going back to countering the biases that the vast majority of developers will have, the vast majority of developers are sighted. So again, they're going to prioritize what visually looks right. If you, for instance, tie your CSS to your ARIA, then things are only going to look right if you're using the ARIA correctly. It's a good way to hack that bias, that visual bias, toward enforcing your own accessibility. So yeah, I don't know, it's tricky, but anytime someone's like, oh, you can do an X-only thing where X is CSS or HTML or something like that, you should maybe be a little skeptical, perhaps, and ask yourself, does this provide all of the necessary key events? Does this provide all the ARIA states? Stuff like that.
00:43:29 - Anthony Campolo
Yeah, I found that that was definitely the hardest thing for me when I was first learning this stuff. It's like, how do you create minimum viable accessibility? Because especially with single-page apps, it's so easy to just blow away everything the browser knows or expects, and you're just throwing it JavaScript that could be doing anything. So if someone's working in that single-page-app kind of paradigm, are there some things that they need to watch out for that they may be screwing up without even realizing it? This is a thing you bring up a lot.
00:44:01 - Ben Myers
Oh yeah, there's a lot. And actually someone I want to shout out here is Manuel Matuzovic, who recently published on his blog an article about some of the criticisms, accessibility-wise, that he has of single-page applications. And his criticisms largely line up with mine. But aside from things like performance and stuff like that, which are absolutely big, important pieces of the pie here, single-page applications do pose accessibility problems in part because they're so dynamic that if you're not accurately handling all of the keyboard events, or if you're not handling focus management or anything like that, you're going to create an experience that again looks right but leaves people behind. Additionally, it's introduced a whole class of bugs in and of itself. One that you and I have talked about quite extensively, Anthony, is routing. Routing in single-page applications is fundamentally broken. That is because browsers were built and screen readers were built with this understanding that what a navigation means is you get a new document and you are pulling up a new document. When you're navigating between pages with a screen reader active, navigating that page basically counts as a way to flush the screen reader of its announcements.
00:45:33 - Ben Myers
And the screen reader will start announcing things like the page title and stuff like that. But the single-page-application model, which is really just cleverly hot-swapping the elements that are on the page with elements that aren't on the page quite yet, because you don't actually have that hard document load, you don't get the screen reader announcements about this. The user isn't actually properly told that they're on the new page. They don't get the page title and stuff like that. And things can get even messier when you have elements that are shared across the different routes. For instance, a navbar. If you click a link in the nav bar and you go to another page which has that same nav bar, your focus actually stays on the link that you were on because as far as your keyboard cursor is concerned, nothing changed. The screen reader doesn't announce anything either. And so it can seem like you didn't actually navigate at all if you were blind and using a screen reader. And there have been user tests done. Marcy Sutton is kind of the big champion here. She worked with Fable Tech Labs while she was at Gatsby to put together some user-testing best practices around client-side routing in single-page applications.
00:46:51 - Ben Myers
But to my knowledge, a lot of those things haven't been implemented in client-side routers today. There are kind of half implementations in some routers. Some try to do live-region announcements, some try to guess at some focus-management stuff, but it's really, really tricky. It is fundamentally unsolved and is even more fundamentally unsolved in a lot of the big routers that people use today. There are some routers that, if I were to start reciting them, you would know the names of, that just haven't implemented this feedback at all. This leaves people in a position where if you're building a single-page application for your users, you have to roll your own routing solution, which is also not great because I for one don't really want to rely on or count on every team across every company being able to have the wherewithal, the expertise, the knowledge, whatever, necessary to handle that routing. I would prefer this be sensibly solved, and we just haven't gotten there. So this is one of those things that's really tricky. I also just think in general the component-based paradigm does introduce some accessibility tradeoffs.
00:48:15 - Ben Myers
I think that there are ways in which components can make accessibility easier. But this idea that you could have an encapsulated bit of UI that handles all of its own logic and doesn't really need to know anything about the greater context it's in means that that falls apart when you need to know about the greater context you're in. If you have a component that introduces a heading, what heading level should it be? Well, that depends on where the component is rendered, right? And that is messy and stuff like that too. So I think this class of client-side rendering and single-page applications and componentization, they all kind of have this interrelated muck of accessibility issues that you can work around, but I think it just introduces a whole lot of extra load for teams working in that space that I don't think we as an industry are always truthful about. Tons to think about there.
00:49:13 - Anthony Campolo
Yeah, it's really tough too, especially because those tend to be the tools that we give to beginners, and it's like, here you go, build sites with this. And then we also don't really teach them much about accessibility, so we're setting them up with the least accessible tools possible and none of the knowledge to fix it. So it's a huge cluster.
00:49:33 - Ben Myers
Yeah, absolutely.
00:49:37 - Anthony Campolo
We got about 10 minutes left here. Everyone's still welcome to come up and ask questions if you got them. I would be curious though, to get a little bit into Show My Chat. Is that still a going concern for you?
00:49:51 - Ben Myers
I haven't done a whole lot of work on it, but what this is is... when I got into streaming, I wanted to show off the chat as part of my stream overlays. It turns out you can do that with web tech because Twitch provides all of the chat through IRC, so you can access it with WebSockets and stuff like that. What ended up happening was I found that I had a couple of other streamer friends who wanted to do something very similar. We were all basically writing the same code in different ways. And if you're not a web developer and you want to show your chat on your stream, it is kind of unfair that you have to resort to either some super proprietary tech or you have to be a web developer, right? Neither is particularly ideal. So I created a website called ShowMy.Chat, which is an on-demand Twitch chat generator that lets you pick a theme. I've got some themes in there I'm quite proud of, and some of them are interesting thought experiments, I guess. Horses. Yes. And so if you're interested in using Twitch for content creation, I would highly recommend checking it out.
00:51:11 - Ben Myers
It's designed to basically spit out a URL that you can plug into OBS and display your chat. But yeah, I again haven't had a whole lot of opportunity to work on that or maintain it as of late, but it works, and it works pretty reliably. So I'm always looking for more people who could get involved in that. But yeah, I think we got...
00:51:34 - Anthony Campolo
Speaking of streaming, Nicky T. Hey, what's up, friends?
00:51:39 - Ben Myers
Hey, Nick.
00:51:39 - Nick Taylor
Hey. Yeah, speaking of ShowMy.Chat, that's not what I was going to ask. I raised my hand just as you transitioned to talking about ShowMy.Chat.
00:51:48 - Anthony Campolo
That's all good. Yeah, feel free to.
00:51:49 - Nick Taylor
Yeah, but I was going to say ShowMy.Chat's pretty awesome. I've been using it on my stream for a long time. It's only recently that I'm starting to use Restream, so I'm using their overlay because I need it for both outputs. But that's just a side note. I know you had talked about YouTube integration for ShowMy.Chat then, so I wonder if we could somehow make Restream work with it too.
00:52:11 - Anthony Campolo
But anyways, that's a little controversial.
00:52:14 - Nick Taylor
Yeah, I'm getting spicy here kind of.
00:52:15 - Anthony Campolo
Not really.
00:52:17 - Nick Taylor
Yeah, no, the question I had, and it's really open-ended, is just in regards to the routing, which is an accessibility issue. It's just funny because the Gatsby team is at Netlify now, and we just had an overview of Gatsby the other day. Marcy Sutton had worked, because Marcy used to work at Gatsby like you said, and she worked on Reach Router. And Reach Router is... Reach UI is built by the same people that create React Router and Remix and React Consulting and all that stuff. They basically had other things to do, but they forked it and they kept working on it, and that's what's in Gatsby at the moment. But the thing I was curious about is I'm kind of surprised that browsers haven't made pushState in the History API more accessible, you know what I mean? Like when you push a state onto the history, you're altering the history. So I'm surprised they haven't, unless there's something I'm not aware of, been like, hey, if I pushState and say go to here now, reread the page title and so on, and readjust the navigation.
00:53:32 - Nick Taylor
I don't know, readjusting the focus might not be part of that, but I'm just kind of surprised there hasn't been any kind of movement on that in the browser space, less in developer land.
00:53:47 - Ben Myers
Yeah, I would need to look into that more thoroughly as well. And part of this too is I know that browsers have been working on things like view transitions, I think is what it's called now, which is the whole bit where if you wanted to smoothly, animatedly transition from one page to another, you can do that and you can take advantage of the Navigation API as a part of that. But as for whether that pushes state to assistive tech, in the kind of client-side-routing sense of when you do pushState, I'm not entirely certain. I would need to look into that. But I mean, the proof is in the pudding, like if you're using a lot of those single-page apps and you test it, you realize like, oh hey, this single-page-app framework isn't actually doing for me what I thought it might be doing. I'm not getting those announcements, yeah, stuff like that. And it seems like new routers are coming out every day too, which is also interesting. But yeah, I would love to just, I don't know, have a come-to-Jesus meeting with the developers from all the different routers and be like, we need a manifesto of what it is a single-page-application router needs to do.
00:54:59 - Ben Myers
We need to publish this online. And then anyone who's looking to build their own bespoke router can just look at this checklist and be like, oh yes, I am handling focus management.
00:55:10 - Anthony Campolo
Yeah, no, for sure.
00:55:12 - Nick Taylor
Let's make Router Fest 2023 happen.
00:55:15 - Ben Myers
There we go. I would attend. I would attend. But here's the thing: if we do RouterFest, in the middle of RouterFest it has to move elsewhere and then not tell the disabled people where it's gone.
00:55:30 - Nick Taylor
All right, all right. I don't think I would put that in place because I would feel very uncomfortable. But that could, it's performance art. It could make for a very interesting and probably last venue ever.
00:55:42 - Ben Myers
Did somebody mention performance?
00:55:47 - Nick Taylor
Is that how you call Henry El Verraca? You just say the word performance.
00:55:54 - Ben Myers
That or Toronto.
00:55:57 - Anthony Campolo
Ah, yes, Mr. Elvetica. Cool. Anything else you want to ask Nick while you're up here?
00:56:03 - Nick Taylor
No, that was it, and it's really more open-ended. It wasn't so much for you to answer it then. I was just more curious about it. Yeah, yeah. No, thanks, man.
00:56:13 - Ben Myers
Absolutely. Always good chatting.
00:56:15 - Anthony Campolo
Yeah, yeah, yeah. I think the idea of some sort of spec-like thing to say what a single-page-app router would need, that would be, I think, really valuable. I've kind of seen Redwood struggle with this, and yeah, that would be pretty interesting. It would require a lot of coordination though, I would imagine.
00:56:35 - Ben Myers
Absolutely.
00:56:38 - Anthony Campolo
Awesome. Well, we're getting close to the top of the hour here. Is there anything else you'd like to leave our audience with or links or just words of wisdom?
00:56:49 - Ben Myers
Sure. So for anyone who's looking to learn more about accessibility, there is a conference coming up in March called axe-con. It is hosted by Deque Systems, which is a pretty well-known accessibility resource. They provide a whole lot of accessibility consulting for companies. axe-con will be, I believe, March 15th and 16th. It is totally free. It's totally virtual. There are several tracks, so whether you're involved in development or design or business or marketing or whatever, there's a track for you. And I'm actually speaking. I will be the last talk in the developer track on Thursday the 16th, and I will be giving a talk on hijacking screen readers with CSS. This is absolutely my favorite talk to give. We go through some absolutely astonishing and, I think, hilarious examples of misleading screen readers with CSS alone. And we use those as a springboard to go on an odyssey through the history of screen readers and dive into browser and operating-system internals, all in the name of providing good user experiences for people. So if that sounds interesting to you, or if any of the other talks sound interesting, y'all should go sign up.
00:58:03 - Ben Myers
I believe it's deque.com/axe-con, but yeah, you see it, it's been pinned now. Y'all should absolutely attend. There are tons of great talks going on, and it's just a great way to kind of learn more and see what people are thinking about in the space.
00:58:31 - Anthony Campolo
Awesome. Yeah, definitely. Highly recommend people check that out. It should be a wealth of great knowledge. I've seen you give this talk a couple times, and it's definitely a really fun one and opens your eyes to a lot of interesting stuff. Well, thank you so much, Ben. It's been a real pleasure chatting with you as always. And yeah, I think this will just about close it out for us now, and I hope you enjoyed your time here. This is JavaScript Jam. We do this every Wednesday at this time. And yeah, if you're interested in speaking here and want to join us as a guest, feel free to DM. And yeah, I think this will just about close it out, so thanks so much, Ben.
00:59:14 - Ben Myers
Thank you all for having me.
00:59:17 - Anthony Campolo
All right, later everybody.
Discover Related Content
- Fullstack Accessibility with Ben Myers (Podcast)
- Eleventy with Ben Myers (Podcast)
- Secrets of Accessible Routing with RedwoodJS Core Team (Video)
- Social Cards with Ben Myers (Video)
- What is Partial Hydration (Blog)