Ask Me Anything — #a11y, Web Dev, and More!

Transcript

Howdy, howdy, y'all. I just realized I did not turn on my light. There we go. Beautiful, beautiful. As you can see, we've got a Tuna. We've got me. We've got… I mean, that's basically it. So today's going to be a little different. I had to do some rearranging for today's guest. We wanted to make sure we could put on the kind of best possible strea, that we could together, and we just needed a bit more time for that. He'll be coming back in May. No worries.

Good to see a few people already in the chat! And some people are already starting to abuse the !tuna command. Please feel free to go ahead and use !tuna. It's going to cause some excellent, excellent chaos. I figured, you know, really and truly Tuna is the star of Some Antics, even when he's napping or especially when he's napping as he is.

Yeah, so [00:01:00] today is going to be a little different. Today's going to be an Ask Me Anything where you can just kind of fire away at all of your accessibility questions, webdev questions. I'll try to answer them the best that I can.

Hello to everyone who's already in the chat! Anthony, I will add that command. It's not quite there yet. We do need an !chan command, though. Absolutely.

So yes, feel free to come just drop your questions in the chat and I'll try to answer them the best I can. Transparently, Ask Me Anythings are always a bit of a gamble, right? Because they really depend on audience participation. And so if we don't have questions and then we might have to pack our bags early!

Hi, Pritam! Good to have you here. Hello everyone in the chat, by the way. We've got a lot of great friends.

So, Isabel is asking [00:02:00] whether Zoom just uses aria-live="extra-super-duper-assertive". It's so weird, right? So if you're not familiar with the hellish combination that is trying to do anything with VoiceOver and Zoom, anytime literally anything happens in Zoom, Zoom has to announce that thing to your screenreader and it does so in a super slow voice. And the weird thing that I can't figure out is, it does so at the same time that VoiceOver announces other things. So you have two announcements. You cannot interrupt the Zoom announcement whatsoever. I have no clue how to fix that. Like, you can turn off some of the announcements, but there are just some that you can't, like the chat, which is always super great whenever I'm demoing VoiceOver to some of the, like, new hires at work. Because we've all been remote, we all hop on a [00:03:00] Zoom call and I demo VoiceOver, and inevitably, someone wants to ask, like, a question, and so they drop it in the Zoom chat so as not to distract me. And then VoiceOver goes on this, like, long, slow tirade where it has to announce that chat message. I have no clue what Zoom is doing there, but I wish they would not. So yeah. Hopefully… I mean, I guarantee that that did not help whatsoever, but at very least, I hope the commiseration helps.

Okay, so, "You've cautioned us from using too much ARIA on a site. I'm still not super sure when it would be a bad thing to use more ARIA. I think it's just that it's better to use more semantic tags, but still unsure." Yeah, that's a great point! [00:04:00] So, I do think there's that spectrum there, right? Where it's like, where possible, use semantic markup. If it helps, ARIA is explicitly specifically for assistive technology, which means that you're not getting any of the other lifts that pure, hard semantic markup would give you. So, for instance, search engines aren't likely to be using ARIA as cues. Voice assistants like Siri or Alexa aren't likely to be using ARIA as cues. Like, ARIA is explicitly to try to hijack things and curate experiences for assistive technology. So semantics-first, as an approach, is going to be the most robust approach that you can take there. ARIA… So, the issue with ARIA is that it can [00:05:00] be misapplied, and browsers use ARIA as a cue to curate the accessibility tree, which is the version of your page that assistive technology consumes, because browsers use ARIA to curate that tree, and that tree is the only representation that assistive technology users get access to, then that means if you break things with ARIA, there is no recourse. Right? Whereas if you have poor semantics, at the end of the day, you have poor semantics, right? The content is still there. You're maybe not overwriting things.

So that's, I guess, that's kind of the caveat, right, is because ARIA directly manipulates the experience that assistive technologies' users can have and [00:06:00] because those users have no recourse, no way to correct the page, no way to correct the experience, then that means that ARIA really is using a sledgehammer in place of a chisel, if that makes sense. What I would recommend, if you're interested in learning more, is the ARIA Authoring Practices. This document is incredibly good and it starts off with — I've just put this in the chat — but it starts off with some, like, "Read me first," and it gives, like, "Hey, here's basically, like, the rules of ARIA," and it says "No ARIA is better than bad ARIA." And really and truly, it's about kind of the, like, manifold concerns of you can break things really bad with ARIA in a way that's irreparable for the end user and also ARIA is really only for assistive technology which means you don't get the other benefits that semantic markup might provide.

[00:07:00] So, alright, we've got a few questions down… "What's the worst accessibility flaw you've ever encountered?" Oh, man, that is hard! I think I'm going to go ahead and take this opportunity to dunk on accessibility overlays. If you're unfamiliar, there are some third-party widgets out there that, like, some businesses subscribe to that it's like, "Oh, here, you can just add this one line of script to your page and we'll make your experiences magically more accessible." If you've ever been to, like, a business website and seen in one of the corners, like, an accessibility icon. If you, like, click on that, it, like, opens up a panel, an overlay that's, like, "Here's all the different accessibility modes that we've enabled." Those experiences themselves are pretty dang inaccessible. They're not [00:08:00] keyboard-navigable, or not incredibly well keyboard-navigable. They violate several Web Content Accessibility Guidelines requirements, all in the name of making your page more accessible. It actually creates a worse experience. And because what accessibility overlays are selling is peace of mind rather than actual accessibility, it means that businesses that implement overlays don't actually, like, they don't feel compelled to fix their issues, right? They're not treating it as a bandaid, they're treating it as a cure-all, whereas it literally just makes your experience worse. And so I would say that that's probably the worst accessibility flaw, is overlays that claim to fix things, but actually introduce more problems and do so in a way where businesses think that they're actually fixing things. If you're interested in learning more about that, I believe it's overlayfactsheet… Yeah. [00:09:00] Stick that in there. Go learn. There's also a thing, if you're as fired up about overlays as I am, you can scroll down to the bottom, there's a list of, like, accessibility advocates who have signed their name in terms of, like, "Hey, I promise to not promote inaccessible overlays," and stuff like that, and you should definitely add your name to that.

Anthony is asking — I believe this is a question on behalf of Lucia — "Are there any CSS frameworks that prioritize accessibility?" I think "framework" can mean a good deal many things, but I'm willing to bet that what you mean is something along the lines of Bootstrap or Tailwind or Chakra. I would say that Chakra's a really good… Chakra UI, as far as CSS, frameworks go, like, it [00:10:00] was kind of the first one to really, like, popularize, really mainstreamify accessibility as a selling point for UI libraries. The trick is that a lot of these CSS frameworks come with UI libraries, come with like component libraries rather, and that makes them difficult to extricate, but really and truly, it sounds like a lot of component libraries and CSS frameworks are moving in this direction of accessibility as a selling point. I know Tailwind has been working on this. Tailwind Labs has hired, I believe, David Luhr, who is a pretty prominent accessibility advocate. So, Tailwind, weirdly enough, might be a good place to look there. Yeah, this is something that I don't know a whole lot about. It's something I want to learn more about, so if anyone out there [00:11:00] knows a thing or two about CSS frameworks and accessibility or about UI libraries and accessibility, come reach out! I'd love to have you on.

Let's see. Adrianne, I appreciate you bringing the popcorn for everyone.

"Some recommendations about accessibility and using colors. I've heard that color is not a good way to communicate some information to users." Yeah, codelex, that is a fantastic question. So color is a fantastic tool for communicating information to people. It can be used… I mean, even here on the Chakra page, we can see that, like, hey, some of the really important stuff on here, the really prominent stuff — We've got, like, the "with speed" and then we've got this call to action, right? And they're in this very prominent, popping teal. Color is a fantastic tool for communicating information, but not everyone perceives color, and not everyone perceives color in the same [00:12:00] way that you or I might. So the advice is that color should not be the only indicator of information.

You've likely seen graphs, for instance, that'll compare two datasets and they'll have, like, two lines and maybe one of those lines is red, another is blue. But if you're color-blind, you may not be able to tell the difference between the red and the blue line. And so some advice that you might give is, hey, those data points should also include, for instance, shapes to go along with it to distinguish.

So the advice I would give is not "Be afraid of color." It's "Color alone should not be the sole indicator of information." And that wording is, by the way, not a coincidence. I'm pulling that from the Web Content Accessibility Guidelines, which has several good recommendations about how to use color. So, [00:13:00] Success Criterion 1.4.1 is Use of Color and, in full, what it says is "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."

So, links, for instance. It's incredibly popular to make links just blue, right? Get rid of that underline, just make the links blue. But the problem is, again, iif you're color-blind, those links may not be distinguishable from their surrounding text, so you would want to add some other indicator. Maybe it's an underline, or maybe it's, like, the box with an arrow that indicates an external destination. Basically adding in redundancy into your experience, into the way that you communicate information so that people have multiple ways to get information. [00:14:00] So that's one thing you have to keep in mind, is that if you're going to use color to distinguish information, make sure you provide a redundant means of accessing, like, getting that same information.

Thing #2 to keep in mind is color contrast. So the Web Content Accessibility Guidelines provides actually several different requirements to deal with color contrast. By and large, text should have a color contrast ratio of 4.5:1 against its background. And everything else, all your other controls, by and large, should have a color contrast of 3:1.

And I realize I've thrown out a few numbers, so let's go ahead and go to… I tend to use the WebAIM Contrast Checker. This was, I guess, just the first tool I found. [00:15:00] So to put these numbers into context, if I have an all white background and an all black text, that is the most contrasty I can get, and so that's going to have a color contrast ratio of 21:1. Whereas if I have white text on a white background, that's no contrast, it's literally the same color, and so the contrast ratio is 1:1. So that's the range that you've got: 1:1 all the way up to 21:1. And I want to say it's #797979, I think is… Yeah, maybe we need to go a little… Yeah, there we go. So it's actually #757575, this gray right here that we can see, this is the lightest a gray can go to have sufficient contrast against the white background. So y'all can see the [00:16:00] examples down here — I don't know, maybe the stream compression might be munging the colors a bit — but you can see, like, this is the absolute lightest you can go and still meet color contrast requirements.

I think there are other tools that people use. Like, one of them I think is called "Coolors," which is supposed to, like, help make this a little easier as well. I could be wrong. We'll see! Okay, that doesn't seem to provide color contrast, but there are tools that — Oh, hello, there's a colorblindness filter. So Coolors right here — I'll put a link to this tool because it's absolutely gorgeous — but it's got this, like, sidebar that I enabled. I clicked the little glasses up here, and then I can go in here and I can try different flavors of colorblindness just to see how these colors actually do play together. [00:17:00] So that would be a good thing to check there.

So, when you're building out, like, if you're in the position where you're building out a design system, you broadly speaking need to find sets of colors that will all broadly speaking have those color contrast requirements with each other. And yeah. So the advice I would give is bear in mind what are your backgrounds. Right? Because text is, or really anything that you want to check the color contrast of, you would want to make sure, hey, does this thing contrast against this background? So that means you need the foreground color, you need the background color, and then if there's anything surrounding it. For instance, links need to contrast both with the background and with the surrounding text.

[00:18:00] Let's see, what is that color contrast triangle? It's been a while since I've pulled this up. But this is another… Yeah, here we go. contrast-triangle.com. This is a tool that I love because it introduces kind of the three-way color contrast stuff. So it tells you like, hey, if you've got like a solid blue link color, like that blue might work pretty well against the background, that blue stands out against the background, and the text in general stands out against the background, but the link does not stand out very much from the text, at least not in so far as color contrast requirements are. So this is also a helpful tool.

So those are, in general, the two things I would advise with color, right, is if you're going to use color as a means of indicating information, make sure you provide a redundant backup way to get that same information, and then the second thing is color contrast. Again, by and large, your text should have a ratio of [00:19:00] 4.5:1 against its background and anything else should have a ratio of 3:1 against its background. I hope that helps, codelex! I would love to take any follow-up questions you have on that, because color is fun and color impacts so much of what we consider web design because web design is so prominently visual in nature.

Let's see. "How does the virtual DOM" — this is from Anthony — "How does the virtual DOM affect the accessibility tree in comparison to JavaScript frameworks without a virtual DOM?" The truth is, from what I understand, not really much of anything because the accessibility tree is directly forked from the DOM itself. I guess I should take a step back. The virtual DOM is, in frameworks like React, it's basically a data structure that the framework [00:20:00] itself maintains to be able to, like, handle updates in a batch. So instead of making DOM manipulations one by one, the framework will maintain its own representation of the page that it can then make updates to, and then it can update the DOM in one batch update. And that's pretty cool. What that means is the virtual DOM actually is entirely meaningless in terms of the actual DOM — it's more of, like, a staging area. And the accessibility tree, the representation of the page that is exposed to and consumed by assistive technologies, the accessibility tree only cares about the actual DOM. And as far as I know — and I could be totally wrong here — as far as I know, the virtual DOM doesn't tap into that at all.

Let's see! Oh, man, I'm way behind on the chat here. Pritam is [00:21:00] saying, "For the checkbox role, we add an id and a for" — Actually, you know what I'm going to do? I'm going to bring my chat in here too, so that y'all can kind of follow along where I'm at, even though I know we've got the chat behind and people who are watching live can see the chat as well. So, "For the checkbox role, we add an id and a for, or if you're in React, it's, like, the htmlFor abstraction. So adding an id on the checkbox input — No side effects in React? (Since React also adds its own id for different against the VDOM)." Yeah, several questions about the virtual DOM. Maybe I need to find someone who knows the virtual DOM better than I do. But at the end of the day, the only thing you really need to worry about is the end DOM representation. And I believe the IDs, I [00:22:00] mean, the IDs that we write when we're authoring React code, those are the IDs that are gonna get used in the final DOM output, and so that's all we really need to worry about. Again, virtual DOM isn't really connected at all to the accessibility tree in any way. It's more of just a staging area that React has created behind the scenes.

So let's see what else we got. codelex: "About semantic and accessibly context: what is your opinion about the <span> tag? Because sometime ago, a friend told me that the <span> tag doesn't mean anything." That's absolutely correct! So semantic markup, broadly speaking, is the understanding that every tag out there, every HTML tag that you can use has its own defined meaning and expected use and expected functionality. And the exception to that [00:23:00] rule is <div> and <span>. Those are two elements that have been explicitly defined to not have any semantics associated with them, so no semantic baggage. They are a blank slate. That means that they aren't, in and of themselves, providing any meaningful information to assistive technologies. That's totally fine! That is totally fine. That means they're really good for, if you, for instance, needed to wrap a bit of your text in some styles, for instance, you could use a <span> for that, and that would be fantastic. Or, for divs and spans, you can start to add in ARIA on top of that, and that means that you can equip those divs and spans with meaningful information for assistive technology, but you won't be competing with any of the assistive [00:24:00] technology information baggage that you would be getting from using a semantic element.

So for instance, if I were to create an experience that maybe was similar to a radio button, I could start with radio buttons. But if I need to start adding ARIA on top of that to make a bit of a custom experience, then my ARIA is going to compete with the native semantics of radio buttons, so it might make sense for us to start with something like a <div> or a <span>, which has no baggage to start out with. And that way we're not, like, competing with any of that semantics. So divs and spans are very valuable in that regard, but the caveat I would give there is really and truly what you're saying most of the time with a <div> and <span> is "I need an element here for something. Like, I need some wrapper here. But also, this wrapper or this element or this control or whatever you want to call it doesn't meaningfully add anything, [00:25:00] any information or any interaction as far as assistive technologies are concerned. By and large, if there is a semantic element that has the desired meaning and functionality that you want, you should be using that.

I wrote an article, a blogpost, a long time ago. It was actually the second blog post I wrote. But it was… Let me get it up. It was about how some people will try to recreate a button using a <div>, because divs come completely without styles. But if you want to make it an accessible button, you have to hijack in a whole bunch of stuff — you have to add in ARIA and you have to add in keyboard navigability and all that jazz — when you're really recreating the <button> element and you should just start with that. So if you can use a semantic element, you should. It's going to be [00:26:00] far more robust. There is stuff that browsers have baked into those native semantic elements that you or I are likely very clueless about, right? We would miss it if we were to try to roll our own in some regards.

So, <div> and <span>, they're fine if you need to wrap some content, maybe provide some styles or maybe you need just a wrapper that you could use, like, querySelector on, but you don't want to introduce any accessibility baggage into. They're fine for that. And they're fine if you really, truly need to start from scratch with, like, building an ARIA-based widget. So that's the recommendation I would give there.

Alright. Let's see. Whoo!

Next question is from Adrianne. Adrianne's asking if we could talk about the accessibility of emojis. "Compared to emoticons, and also best practice of emoji use." Y'all, I love emojis so much. They're great. [00:27:00] I think they can actually add a whole lot in very little space, and they can just make content very fun. The truth is… So first of all, emojis, behind the scenes, are Unicode characters just like any letter you type. It's just that Unicode, when defining those characters, said, "Hey, as part of the specs, like, these characters we think you might be able to represent well with a color font." But other than that, they are more or less the same as any other Unicode character. That means they're text that screenreaders, for instance, might read aloud. But not all screenreaders support emojis. Not all of them have, like, a viable announcement for emojis. So if you're using emojis to convey information, that could be a problem. Alternatively, some screenreaders totally do announce emojis. VoiceOver is pretty [00:28:00] powerful when it comes to announcing emojis just fine. So, some screenreaders, don't announce it. Some screenreaders do announce it, but what they're going to announce is, like, the official Unicode name of the emoji, and those can usually get very, very long and not usually descriptive of the emotion that you're trying to convey, the simple idea that you're trying to convey. So some screenreaders don't announce it. Some do announce it, but don't announce the helpful parts, or they'll announce like an incredibly cluttered version of the emoji. And so using just native Unicode emojis might work in certain contexts, but something that you might want to be careful about. You probably don't want to rely too heavily on that experience in and of itself. You'd probably want to do some extra work around it. And the thing I'm going to recommend here is…

[00:29:00] I think that's what an Ask Me Anything really is for accessibility, is "Here, let me share you some really good blogposts that I've read," right?

So Adrian Roselli has a post about accessible emoji. Actually, it comes from… Like, it starts with Léonie Watson's "Accessible Emoji," so I'll share that first. This is really good. And then Adrian Roselli adds onto that. But the idea here is, and this actually goes back to the idea of using a <span> as a solution — I'm going to scroll down to see Léonie's solution here — is you could wrap the emoji… This right here, this is an HTML entity. It's like a fancy way for us to encode some of the, like, higher-order Unicode characters. So this right here, this is the [00:30:00] entity that corresponds to a particular emoji. And Léonie shows how you can wrap that in a <span>. You can override that <span>'s role to say that this is an image because, you know, that's what emojis are, right, is we kind of conceptualize them as images. And then you can add an aria-label, and this is how you might give, like, a really helpful description for an emoji. So this way, instead of getting either nothing like some screenreaders would give you or an overly verbose announcement like other screenreaders would give you, instead this would be treated as effectively an inline image, and it would announce as though that inline image had an alt of "Snowman." And so that's a way that we can provide context about, like, what this emoji is for, what it shows, in a way that's reliable and consistent across all the different experiences.

[00:31:00] Worth mentioning that emojis can be overwhelming. Not just like an individual emoji provides clutter, but also you'll see on Twitter all the time, you'll see just gobs and gobs of emoji in a single tweet. And that can be very hard to get through. Like, you have to announce every single emoji in that series, and that can make a single tweet, which is supposed to be something really snappy, it can make it a slog to get through. So the advice that I've seen is to consider using no more than three of the same emoji in a row, or even just like no more than three emojis in a row. And maybe, maybe don't use the, like, clapping emoji to separate all your different words, because that's gonna create, like, an experience where every other word is interpuncted with [00:32:00] "image, clapping hands," the next word, then" image, clapping hands," and so forth.

So with emojis, I think they can be powerful tools. Use them carefully, use them to punctuate a point, but definitely, definitely you can risk overwhelming people, especially screenreader users, with your emojis. So just be careful with that.

Oh my god, this is more questions than I thought I was going to get. This is fantastic.

Yeah, codelex is circling back on the color contrast stuff. "Combining colors and icons to assure that some message is received? For instance, success gets a check or error gets an X." 100%, I would recommend that. I think it's going to depend on your design system. Again, 'cause, like, icons can create clutter as well. So it's always a balancing act, right? I realize I'm giving mixed messages, but yes, icons are a super [00:33:00] powerful way to provide redundant meaning as well as colors.

Alright, Adrianne's asking what advice would I give to developers very early in their accessibility learning and feeling overwhelmed? "I encounter this a lot." The advice I would give is start with learning a screenreader. Screenreaders are the kind of thing that can feel overwhelming, but with enough practice, you can find your way around them. Especially, if you're on a Mac, then you can use VoiceOver which is built in. And I find VoiceOver is the most intuitive of the screenreaders out there in terms of just the kind of keyboard interface it provides. And the reason I say start with a screenreader is, even though accessibility is not exclusively about screenreaders, as we've kind of seen today, like, the combination of announcements and the requirement [00:34:00] of keyboard navigation, I think can give you a very strong feel as to when something is wrong, because something's going to announce that's different than what you'd expect or might seem unhelpful or unintuitive. Screenreader testing, I think is a powerful window into a good deal many accessibility concerns that we might want to test for it, and so that I think is the testing ground, I would say.

The other thing is take a look at the Web Content Accessibility Guidelines. While they are a baseline, I find that they have great documentation for explaining why something's a requirement, who it's for. Whenever you hear about something accessibility, you should always ask the question of "Who is this for? What problem is it trying to address?" And I think the Web Content Accessibility Guidelines do a great job answering that question, and that [00:35:00] will kind of open your mind to more disability experiences that you can test for. More personas, if you will, if you're kind of in the design space. So, what you could almost do if you've got a down day at work, a kind of slow day, just kind of pop open the Web Content Accessibility Guidelines, find a success criterion, and just seek first to understand. Read through it, try to understand what problem it's trying to address, what needs it's trying to meet, how it's going about that, and how that might apply to sites that you've built. And then just kind of play around with can you fix it your own site with that. Don't try to digest all of WCAG in one go, but just kind of take it one success criterion at a time and really understand what it's about. And just focus on expanding your experiences kind of in a piecemeal, [00:36:00] step-by-step, progressive approach there.

Adrianne's also asking what are some technical or non-technical benefits of web accessibility that I think are less well known. So, search engine optimization is kind of one of the easy ones, because accessibility often leans very heavily on semantics as providing a foundation that's robust regardless of what devices and software you're using, and it turns out that that's the same foundation that search engine optimization uses. So, you're going to have your site be easier to find.

I also love, when you start really building with accessibility in mind — I had, with Michael Chan, he and I were on a call at one point and he was kind of talking through some semantics issues he was having and some accessibility issues that he was [00:37:00] having, and ultimately, the question kind of at hand was "I'd like to be able to disable a link and I don't know how to do that." And we looked into the underlying semantics and it turns out you can't disable a link. You have to, if you're going to try to disable a link, you have to do a whole bunch of really just absurd workarounds, right, and it just felt not robust at all. And ultimately we kind of realized, like, hey, maybe if you're showing a link that's not clickable, like, you're not providing context as to why it's not clickable. And it turns out, we realized, like, this was a window into just talking about user experience as a whole. We were talking about how do we accessibly disable links and it turned into "Does it make sense to have disabled links at all? Why are we showing links that people can't use? What does that even mean?" So accessibility is a great window into user experience as a whole. [00:38:00] So that's another thing I would keep in mind.

Another is in disabled spaces, we talk quite a bit about a phenomenon called the curb cut effect. So, the city of Berkeley, back in the '60's, implemented curb cuts around downtown. If you're unfamiliar, those are where, like, when you're on the sidewalk and the sidewalk, like, slopes down gradually into the intersection. That's a curb cut. I believe they're called pram cuts over the pond, across the pond. But these were implemented mainly at the advocacy of several quadriplegic students at UC Berkeley. And what the city of Berkeley found after a year or so of curb cuts existing is of course they weren't only being used by the quadriplegic, wheelchair-riding students. They were also being [00:39:00] used by parents with strollers, or people with luggage, people with big carts, skateboarders, and bicyclists. Like, it turns out many people benefited from an accommodation like this. And so the curb cut effect says… It's really like you could summarize it as "accessibility and accommodations benefit everyone." A modern day example of this might be closed captions, where those are nominally for people such as myself who are hard of hearing or deaf to understand what's being said, but it can also benefit people with auditory processing disorders who can hear but not necessarily parse what's being said, and also benefits people for whom that language might not be their first language, and it benefits people who are in loud environments, such as bars, or people who are in very public environments such as airports or buses where you may not want to play the content aloud. Closed captions benefit all of those [00:40:00] people. So that's something I would say. There are others, but wow, it's already 12:40. I'd like to be able to get to a couple of other questions. That's a fantastic question, and thank you so much for asking, Adrianne.

Robb's asking, "Why is Tuna such a very, very good cat?" And the answer is, he's Tuna. Great question. Happy to have answered that.

Oh man. With HTML5 and web semantics, have I identified some ARIA attributes that aren't necessary now? I don't think there are. I think that the ARIA spec has been very careful to provide ARIA attributes that could, in theory, provide some help in certain contexts. The ones I would say are less necessary now are the ones that where, like, they're designed to help you basically [00:41:00] recreate a semantic element that already exists, like a lot of the ones that have to do with, like, "What if you made your own custom slider instead of using <input type="range" />?" Let's see. And similarly, yeah, there are totally, like, ARIA attributes that are meant to be used together, again in the case of like, if you're recreating an… Like, if you're recreating a slider with ARIA, there's, like, aria-valuemin that's supposed to be used with aria-valuemax that specifies, like, the minimum and maximum ranges of your slider, so they are meant to be used together.

Alright. So, Pritam's asking about the "heading" role, but without understanding much about aria-level. Yeah, so, like, the role="heading" lets you [00:42:00] basically recreate each <h1>s through <h6>s using any text. Now ideally, again, you would be using <h1> through <h6> tags. Sometimes you can't, though. And there's, like, one use case in mind that I can think of, and I'll get to that. But the aria-level is supposed to basically indicate, like, oh, if you've got role="heading", then you could say aria-level="3" to specify that this is effectively an <h3>. And that helps… Again, ideally you would be using the <h1> through <h6> tags. Where going about this role="heading", aria-level business helps is if you're creating, for instance, a reusable component that you would need to, like, plug and play. Because headings really describe like the document structure. They provide kind of an outline to the page and that helps [00:43:00] people navigate the page effectively by skimming, right? Like, whereas you and I, if we're sighted, we might scroll through a page quickly and take a look at the headings, screenreader users use the markup of the headings to decide, like, "Hey, here's how I'm going to skip the parts of the page." And that means that you kind of need to provide an outline that's in order. But if you're creating, like, a reusable component that needs to have a heading, but also needs to be able to slot anywhere, then that means that potentially you need to customize the heading level. And the easiest way perhaps to do that is to have the person who's consuming the reusable component supply, like, a heading level, just to indicate "Here's where this exists in my document." And then you could use that as aria-level. That is an edge case, but it's like, the use case I can think of for aria-level. [00:44:00] Again, prioritize using the <h1> through <h6> tags if you can.

Got a few questions from Chan. I'm going to try to get through these really quickly. These have been fantastic questions! Thank you all so much for dropping these in.

So, first of all, with skip links, "Should they skip the navigation or just the masthead? I'd assumed navigation, but GitHub only skips the masthead." I think this depends a lot on the context of what you're using them for, and I think another thing worth noting is that you can have multiple skip links.

Every time I talk about skip links, there's always someone who's like, "I've never heard of these things," so let me give you really quickly a blogpost I've written about this, which is this one right here. No, it's not. What is… Oh, it's because it's not "blogs." Look at that. I know my own information architecture. [00:45:00] There we go. I'm going to drop this in the chat as well. So, this is a blogpost about skip links. But effectively, many sites frontload. Like, they'll have heavy navigation, like, heavy navbars with a whole bunch of links at the very beginning of the DOM's focus order. But those links are pretty consistently going to be the same across pages, because you tend to reuse navbars across pages for the sake of consistency and you likely probably should. What this means is, if I'm a keyboard navigator and I visit one page on a site, I have to tab through all of those links and then I get to the content that I want. And then if I navigate to another page on that same site, I have to tab through all those links again, and that can be… intense. So what many sites will do is, they'll introduce what's called a skip link. This is the [00:46:00] first focusable link in the DOM focus order, but effectively — So if I hit Tab, you'll see… Ope. If I hit Tab, you'll see that I have a link that just appeared. So this is my skip link, and for me, I actually have it to where, when I click on this, it'll focus on the header based on the way I've got my page set up, but basically it'll let you skip over all the links I've got in the header. So it'll skip over the logo. It'll skip over "About," "Twitch," and "Twitter." It'll take you directly to the header. Much more important for sites that frontload the nav.

But by and large, the goal here is to help users quickly skip over repeated, cluttered content, and that's going to mean different things on different sites. I give the example here of MDN where, like — here, we've got the MDN page — and based on the way the markup is, if you were to tab, you'd have to tab through [00:47:00] all of these things on the menu here. So I'll, like, start tabbing through this. So you've got the search bar, you've got the "Sign in." Oh, look at that, we got to go through the breadcrumbs. That's fun. "Change language." And then you got to go through all of this stuff over here, and then, finally, you're in the article that you actually care about. That could be a lot. That could be intense, especially on page-by-page, so sites will introduce skip links. And really and truly, that's going to come down to what do you think is going to be repeated on the page. What might users want to skip over and what they might they want to skip to? And so MDN actually provides several skip links. So here's "Skip to main content." That'll take you directly in here to, like, where the header is and everything. You can also skip to the search, which will take you to the sidebar [sic: searchbar]. I think there's one more. No, there's not. So it's just those two.

[00:48:00] So I've talked about skip links that are at the beginning of the page. You can also have skip links on other parts of the page. For instance, if you've got a data table with a lot of focusable elements inside of it, that can be a slog to have to tab through and users might want to be able to tab to get to the other side of the table and not necessarily go through that whole table. So some people, what they'll do is they'll introduce at the beginning of the table, like right before the table, they'll have, like, a "Skip table" link that functions in the same way. Again, depends on the site. It depends on what you think users might need to consistently skip over, what you think they might need to consistently skip to.

Alright. Still more questions. How much more? Okay. We're we're pretty decently caught up here.

Chan's also asking, "There seem to be a lot of weird tricks for making tables on mobile, quote, 'accessible.' Are those tricks [00:49:00] necessary? Or do assistive technologies assist in navigating tables with standard markup? If the latter, whether what are the pillars of a good table markup for assistive technologies?" Yeah, by and large, use a <table> element for tables, right? So <table> elements kind of have a lot to them. Let me actually… I did create a little folder so I can do a demo of some code if I need. So let's go ahead… I'm just going to create a table.html. We'll kind of go through, real briefly, the anatomy of a table, 'cause there's a lot here that there's a potential to forget.

So we could start with a <table>. Right? That's fine. <table>s should have a <caption>. This is one of the things that constantly gets missed, but this is… Think of, like, the <caption> as, like, the <table>'s equivalent of alt text. This is how you give the <table> a name. So this could be something like "Order History," [00:50:00] right? In the past, I know we've talked about, like, visually hiding stuff. You can visually hide this if you want. There are utility classes for visually hiding content accessibly. But this needs to be in there and it needs to be the first child of the table. So that's thing number one for table markup.

The next thing is you can have a <thead> — that's short for "table head" — and in there, you can have a table row and then table header cells, and this should be, like, your column headers. So that's a thing you need. Then after that, you should have table body — the <tbody> element — and that itself should have table row with a whole bunch of <td> table data cells, et cetera. Sometimes you need to have information at the bottom. For instance, if we're talking, like, order history, you might have, like, a totals row at the bottom. So in that case, you'll want a table footer, which is table foot — <tfoot>. [00:51:00] And again, I think that's also, you got a row with probably <td>. It might be <th> — I'd have to look that up.

Mobile is interesting, though, because tables tend to span very wide, right, and often too wide for us to show on the screen at one point. And so, there are tons of people who try to go all in on making a responsive table, and that means collapsing columns and that kind of stuff, maybe providing entirely different markup. I would say that there are different approaches, and again, you're always going to have to figure out what works best for you and what works for your design. But one of the things I've heard is actually just letting the table overflow the window, and then what you do here is you let the user — especially if they're on mobile, they'll likely have, like, gestures where they can, like, swipe left and right — so you put, like… I think you need style and it would be, like, [00:52:00] overflow-x: scroll. So that lets them go left and right. And then you want to give keyboard users the same opportunity, or people who are using screenreaders the same opportunity to scroll, and in that case, what you would need to do is add a tabindex of 0 to add this to the focus order. That way someone could tab to the table, and they're tabbed on the table, they're focused on the table, they could use their left and right arrow keys to scroll left and right. So that's the simplest way to have… It's not really a responsive table, but it's a table that works well for mobile. And the benefit of this is you don't have to try to do a whole bunch of, like, mobile-specific markup, which can get intense sometimes. Ask me how I know!

Let's see. What else, what other questions do we have? Oh, actually I do want to… I'm gonna plug Adrian Roselli again, 'cause he [00:53:00] has… "responsive table…" Yeah, here we go. So there's this one. And then I'm also going to send you the "Under-Engineered Responsive Tables." Give these a read if tables are ever a thing you have to work with. Give these a read. It's basically mandatory. It's very good.

We're getting close to time. I'm going to take a couple more questions. I might not get to everyone, but I do have a question for y'all, which is how is the !tuna command? Are y'all enjoying that? Are there more commands I need to be adding? The answer is probably yes, but I'd love to know in y'all's own words.

Yeah, let's see. Whoo.

Robb's asking, "Why do people lump accessibility and internationalization together? These seem very distinct." Yeah, it's 'cause a lot of times the message of [00:54:00] accessibility is "Everyone should be able to access information regardless of ability," and the message of internationalization is "Everyone should be able to access information regardless of the language they speak." And also, they have convenient, uh, numeronyms. That's the acronyms that contract based on how many letters are in the word. They both have numeronyms! You know, they're both about access, universal access, and they both have numeronyms. They have several concerns in common, I think, in that regard. But yeah, I would say that they're… related? But yeah, definitely not completable [sic: ???].

It's just that people… Like, you start talking about like, "Well, everyone should be able to access the thing," and sometimes people who are well-meaning and sometimes people who just want to be detractors will respond, "Well, what does that mean for people for whom English is not their first language?" Right? Like, [00:55:00] surely access for everyone means access for them as well. And they're right, but once again, kind of depends on your needs, right? "It depends" is the rallying cry of accessibility advocates.

Let's see, Anthony's tackling this. Chan's going, "Today I learned: table caption." Yeah, 100%! Like, that's the thing that gets missed, but it's basically mandatory. I'm going to stick another link about tables and this is… No, it's not WebAIM. W3C has "Tables Concepts." This page is phenomenal. It's got several subpages. Also mandatory reading if you're doing literally anything with tables,

What else have we got? Adrianne… Oh, Adrianne, I'm glad you enjoyed this. I really, I had fun! I I'm so [00:56:00] glad y'all came through with questions. Like I said at the start, this is always a gamble, right? Ask Me Anythings always need audience participation and if you don't happen to get a whole bunch of people in asking questions, then you don't get to do a whole lot.

Yeah, I think… "We should keep a running queue on these and we can do an AMA on a regular." Okay! I might have to consider that.

Oh, and then there's testing strategy. Yes. Okay. So testing strategy for assistive technology. You can and should test with multiple assistive technologies. They are going to behave different. Different screenreaders will behave differently and they'll all behave differently on different browsers as well. So my advice in that regard, if you're looking to get up to speed with assistive technology testing [00:57:00] is… So VoiceOver is free and it's built into macOS. NVDA is free for Windows. JAWS, however, is by far and away still the most commonly used screenreader, so don't leave it out of your testing, but if you only have Mac, you're not going to be able to test with it. But include multiple screenreaders. Get familiar with high-level ways in which people use assistive technology. That can be, each screenreader, for instance, will have several navigation modes such as the virtual cursor, which is how you get through all the static text. There's, like, tabbing, which is how you get to all the interactive stuff. Then VoiceOver provides a tool called the Rotor. JAWS provides keyboard shortcuts for the same thing. But basically it's a way to skip from element to element of the same type, so skip from link to link or skip from table to table. That can be an incredibly powerful way to navigate a [00:58:00] page really quickly if you know what it is you're looking for. It is totally a valid way to navigate a page. It's just one that we don't frequently end up testing with. So get familiar with kind of those navigation principles there, the ways that people use those assistive technologies.

I think there might've been a question in there about automation. Automation, there are libraries like axe-core — I'll stick that in the chat here. Yeah, axe-core and similar libraries do let you do automated testing in the pipelines. At some point I really, really need to, like, talk more in full about automated testing in general, because there are so many caveats here. But basically automated testing help you catch… say roughly half of your defects. There are stats there. I will get those for you all another time. But those [00:59:00] are, like, the lintable errors. It's not going to catch, like, experience concerns. So automated tools like axe-core can help you maintain regression on those very lintable errors, so that you don't have to, like, manually test all of those things.

Wow. I have been going like a propeller. Y'all, this has been so good. Thank you again so much for your questions. I've really enjoyed this time. I hope y'all have found this valuable and helpful. We may have to do an Ask Me Anything sometime soon. But it's not going to be quite soon 'cause we have a pretty full April. Follow me on Twitter at @SomeAnticsDev. I'm going to be tweeting out the upcoming streams. But Joe, who's been in the chat as NastyDirector03, he's actually going to be hopping on next week. We're going to be talking about how [01:00:00] personalization can empower accessible interfaces, and we're going to talk about what on earth that has to do with toilet paper. I'm incredibly excited for that. I hope you all will join me again. That's 12pm next Tuesday, 12pm CT, and I will see you all then. It's been real. Have a good one, y'all.