Check out a free preview of the full Web App Accessibility (feat. React) course

The "ARIA" Lesson is part of the full, Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy dives deeper into the Accessible Rich Internet Application (ARIA) specification. While ARIA can help assistive technology better recognize elements on a page, it can also be misused or overused. Built-in, semantic-based accessibility information on elements is typically favored over ARIA added after the fact.


Transcript from the "ARIA" Lesson

>> So we've looked a lot at HTML. Let's talk about ARIA. We've already kind of been touching on ARIA quite a bit. We've looked at some ARIA attributes, we've seen some roles, but let's dive further into what is ARIA. So ARIA stands for Accessible Rich Internet Applications. It's a specification, it's a standard, it's a way to add accessibility information through your web apps.

I think historically, the idea of it was for things like XML. It is pretty useful in SVG. I don't know how useful it ever was with XML, but in HTML, it's pretty embedded in everything we do, and we'll look at why. The current version of ARIA as of right now is 1.2.

And so this link for the way ARIA specification, ta-da. There it is. We've already seen it once or twice. I often have this open in a browser tab or at least an autocomplete click away because it has so much information in it that is relevant and helpful. But it's also a big scary spec document.

So you will be forgiven if you're not totally excited to go and read the ARIA specification. But just know that it's there and it is the basis of a lot of the technical aspects of what we're discussing. But it shouldn't be the first thing you reach for, it is somewhat of an advanced tool.

I have an image from The Simpsons of Homer holding up a big glass of beer going, to ARIA the cause of and solution to all our accessibility problems. And that's because it, for everything that it helps us with, it also can make things very potentially worse. If you slap a bunch of ARIA on stuff without knowing what it does, it can be pretty terrible.

Like the thing we just fixed with inert was to counter an ARIA issue, where ARIA hidden was on something that had focusable elements in it. And when you put the ARIA on your markup, if you don't ever test it, or don't ever, it isn't caught by something like Axe, you'll just never know.

And someone with a screen reader will come in and use your site, and it's terrible. [LAUGH] And you had no idea. So that's kind of why it has this reputation of being the cause of and solution to all of our accessibility problems. And I have to give kudos to WebAIM.

The people who gave us the screen reader survey and another project called the web a million where they scandal the top homepages for accessibility. They have this awesome blog post about how ARIA is basically the cause and solution of our problems. There's just cracks me up. But fortunately, our tooling like as you saw with AX, it's really getting awesome at telling us when we have goofed about something that we don't realize.

So HTML and ARIA work very closely together. We've seen some of this already, like with roles. The built-in roles, like for links, buttons, form elements, landmarks, those roles that come with those element names. They are ARIA roles just like the ones that we bolt on with the role attribute, is just some are built in that are implicit roles and explicit roles are the ones that we bolt on.

So we should try and use the implicit, built in stuff first. Support tends to be a little bit better. Yeah, there's other functionality that comes along with those. Like, if you have a button element, it's gonna give you a lot of behavior for free, whereas a button role is only gonna bolt on the role.

There's other things that you have to add. So yeah, built in versus bolted on. So which docs should you use? The ARIA standard from the W3C is a good source of truth. But again, it's kind of not the most approachable. So MDN or Mozilla Developer Network is awesome.

They have great ARIA docs. ARIA, as I mentioned earlier today, is also developed in the open on GitHub. So you can go and see, how are they even coming up with these standards? Which browsers and screen readers are still causing issues? Or is there an issue with it?

And so that's pretty fascinating to see how that work gets done. And you can definitely learn things about, like I've opened up issues on ARIA or not open them, but looked at them when I use a certain role or certain attribute and it's just not working quite right and I'll go and search it and the issues.

And there will already be a discussion about it. And I'm like, okay, that's expected. That's the way it worked. And I think the example I saw was, they designed ARIA in a certain way because of how people use screen readers. I had a misconception about how screen readers are used and ARIA was designed more for people who are actually using screen readers.

So sometimes our developer biases, lead us down that path and we can go, okay, I just didn't know. So it can be helpful for learning about that. also has a ton of ARIA information from the Google team. And HTML5 Doctor, I think it's a little bit dated at this point, but it historically has had really great info about how elements work in HTML.

And the HTML5 heading algorithm, they wrote about that.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now