What the First Rule of ARIA Really Means

All right, let's talk about what the first rule of ARIA really means. And for those who do not know, the first rule of ARIA is don't use ARIA. Don't use ARIA. Don't do it. That's the first rule. But what is ARIA? The acronym itself stands for Accessible Rich Internet Applications, and this is a suite of web standards for functionality provided to assistive technology, especially when you're building dynamic content and advanced user interface controls.

When I'm talking about assistive technologies, that's anything that is used to help people with disabilities. So if you are wearing glasses to see right now, you are using assistive technology. If you have ever used that ramp from the sidewalk down to the road instead of awkwardly moving your cart from the sidewalk to the road, that's a curb cut. That's assistive technology. This is by no means an exhaustive list, but in the context of this talk, when I'm talking about interacting with websites, I'm talking about software and hardware used to interact with websites, and that is things like screen readers, communication software, switches, and keyboards.

Before we go any further, I do have to give a disclaimer. Accessibility is never black and white. It is often very frustratingly gray. What may make something more accessible for one group of people may make it more inaccessible for another group of people, and I know from experience that this frustrates developers especially, because we want a best practice, something that will work at least 90% of the time, but that doesn't exist. So I got a couple accessibility auditors to fact check all of this information before I wrote the blog that eventually became this talk, but if I say something and your lived experience tells you that this would make a website more inaccessible for you, please do put a question in the QA or come up and talk to me about it, and please, say hi at any time. You'll get a sticker.

But that frustration, that gray area, is part of the reason I started writing this blog, because when I heard the first rule of ARIA is don't use ARIA, I knew what it meant. ARIA is a huge topic with a lot of rules. There are a lot of little rules that contradict each other sometimes. It's very easy to get gotten by ARIA. When I started giving feedback on people's portfolios or side projects, I pop open DevTools, run an accessibility checker, tab through it with a keyboard, use a screen reader, because I know most of the people that are asking for feedback aren't going to give that kind of feedback, and I would go, hey, an ARIA label would be great here. It would make it more accessible. And the developers would look at me and go, I thought I was never supposed to use ARIA.

So about the fifth or sixth time I heard one of my friends say the first rule of ARIA is don't use ARIA, I was like, hey, developers think they're never supposed to use ARIA or use it at all. And he looked me in the eyes and he went, good. Because when you talk to accessibility auditors about ARIA, they'll tell you about the latest mess that was caused by someone who didn't understand ARIA at all just slapping ARIA on the page. So when you hear the first rule of ARIA is don't use ARIA, that means there's probably an HTML element for that, and no ARIA is better than bad ARIA. Let's dig into the first one. You're already using ARIA. By using HTML. And yes, JSX is a templating language, you are using HTML under the hood, so you're all using ARIA. Don't worry about it. Because ARIA rules are the semantics in semantic HTML. They communicate information to computers and to assistive technologies.

So even when you're using an element like a div that has role generic or using role presentation or role none, you're communicating information to computers and assistive technologies. Just like when you look at an outline in a printed document and you see a list or the beginning of a paragraph indented, you don't read that white space out loud and you don't go space, space or tab, tab when you're reading that information, but it's their communicating structure to the page, which is exactly what computers and assistive technologies think a div is there for. And the way that you use semantic HTML communicates even more information. So if you use an address element inside of a footer element, that tells computers and assistive technologies that that's the contact information for that web page. If you use an address outside of a footer element, it's just an address. Before we get to the next part, I have to explain accessible name. You'll hear accessible name or name. And this comes from the accessibility tree. So when you hand a browser a web page, it computes an accessibility tree. And part of that accessibility tree is a name property. The name property comes from a lot of things, depending on what needs a name and what you've used. So the best example is labels because we're all associating labels with our inputs when we use them, so that's how they get their name.

Table captions, image alt text, legend element, an SPG title element, ARIA label, ARIA label by, and text content are also used to compute names. When you use a button element, the name is computed from the text content. Buttons come with built-in functionality like focus handling, activation on click, space, and enter, and triggering a submit event. Role button and name are part of the accessibility tree and announced. Using div with role button requires manual implementation of basic button functionality and styling. The principle of 'No ARIA is better than bad ARIA' emphasizes the importance of avoiding unnecessary ARIA attributes to prevent accessibility errors.

Web accessibility evaluations on top websites reveal issues with excessive ARIA attributes leading to more errors. Implementing ARIA attributes without understanding their requirements can result in invalid elements and poor user experience. Roles like button and checkbox necessitate specific event handlers and attribute management. Incorrect ARIA usage can mislead screen reader users, causing confusion with incorrect announcements. Following ARIA rules ensures the correct presentation and behavior of interactive elements for users relying on assistive technologies.

Adhering to ARIA guidelines prevents unnecessary clutter in code and maintains accessibility standards. Invalid ARIA implementations can lead to maintenance challenges and unpleasant experiences for screen reader users. ARIA rules dictate the essential attributes and structure for interactive elements, ensuring accurate information delivery. Understanding and correctly applying ARIA attributes is crucial for enhancing web accessibility and providing a seamless experience for all users.

When you reach for div role equals button, you are leaving a bunch of things on the table that would be helpful to you, that you are supposed to program back in. And people do not realize that. Web accessibility in mind runs accessibility checks on the top 1 million websites every year. They have a lot of data about the type of accessibility errors that we can see. And they have found that the more ARIA attributes that were present in the page from developers just slapping them in meant that there would be more accessibility errors in that page.

So don't clutter up your code with useless attributes and invalid elements. It is horrible to maintain and, whew, if you run a screen reader on it, it is horrible to hear announced. Because ARIA rules can require specific attributes and children elements. Role equals button requires an on click handler and multiple on key down handlers. I think I've seen one div role equals button with an on key down handler ever. People don't realize that they are creating invalid elements by just slapping ARIA in the page.

Role equals check box requires ARIA checked and keeping the value of ARIA checked up to date. Because the screen reader will announce check box, name, checked or unchecked. So if it announces the wrong state, your screen reader user thinks they have a check box checked that is actually unchecked. ARIA rules can prohibit specific attributes and children elements. You can't use ARIA checked on a button. You can't use ARIA pressed on a check box. If you are passing the value mixed to ARIA checked, it better be on a check box because it can't be on a radio or a switch.

A child of an unordered list element has to be a list element, a script element or a template tag. Anything else is invalid. And this is for the one person or more in this room that I know has created a nested interactive element where a button has a child as a select or a select has a child as a button, a child of a button cannot be interactive. That is invalid. And if you use a screen reader with it, you'll just get gobbledygook. So at the beginning of this talk, I said that I want people to use ARIA. I want them to learn about ARIA. And I've spent almost half the talk talking about when you're not supposed to use it. So let's talk about when you should use ARIA. If you take nothing away from this talk but landmark roles, I will be so happy. Please use landmark roles in your page. There are eight of them.

I'm only asking you to learn eight elements and eight roles. Luckily, some of the tags match the roles. So like search is search and nav is navigation. I don't know why header is banner and footer is content info. But I'm only asking you to learn eight of these. In a typical website, we usually have a header, a main part of the page, and a footer.

This image comes from my design for non-designers talk. I'm like, hey, you don't want to learn frontend. You don't want to learn design. I get it. Here, you already have your page sectioned out with three elements that you should always be using. These elements can't be duplicated and they cannot be children of each other. If you make a footer a child of main, then it just loses its role. You might as well be using a div.

But the other landmark roles can be duplicated. You can have multiple nav elements in your page. But when you do that, you want to give them a name so that a screen reader user hears nav, main, and they know that this is to get them around your pages versus another navigation bar. Because landmark roles are expected by assistive technologies for navigation.

This video is me using VoiceOver to navigate my portfolio site. I access the rotor. I select landmark roles. I've given all the sections in my page names. When a screen reader user is using this, they get basically a skip link and I have programmed nothing. This is all out of the box, VoiceOver and HTML. Really, if you have already read the header of a page, you don't want to read it every time you go to that page. Neither does a screen reader user. They want to be able to jump between all of these landmark regions and find the meat of your page and then things they want within that main body.

Now we're going to talk about aria-label, aria-labelby, and aria-describedby, because I can't remember if I used aria-label or aria-labelby to name all of my different sections so that a screen reader user would know, oh, I want to read about her writing, I want to read about her speaking, whatever. Because aria-label and aria-labelby are very similar. They both compute a name. But aria-label computes the name from the string that you pass to it. Aria-labelby takes an ID and it computes the name from the element that matches that ID.

So if you have, I don't know, an input, and you're like, I know I'm supposed to associate it with a label, but there's a heading right above it that says the exact same information and I don't want to duplicate it, that is a great time to use aria-labelby. aria-describedby also takes an ID but it computes a description from the element that matches that ID. A name is short and sweet. Button next, button go to this, whatever. A description is for when more information is required.

When you are using icons and images that convey information in static images, we use alt text. For SVGs, one of the ways to add descriptive text that a screen reader user would hear announced is role equals image and aria-label. For icons and images that don't convey information, you use alt equals nothing for static images and aria-hidden equals true for SVGs. You don't want all of that announced repeatedly to screen reader users when they don't need to know about it, just like a div. Buttons and links should have text content. That is how their name is computed.

Buttons and links should have text content. That is how their name is computed. That is how they are meant to be used. But I will not die on this hill. I have accepted that the design is that we use the right caret to go to the next page with an SVG. I get it. So when you are using buttons with an SVG, on the image, you want to use aria-hidden equals true, and on the button, you want to put an aria-label, which is what you are trying to communicate with that little right caret, which is probably next. When you are doing links with image content, links have to have content. So you're going to put an aria-label on the image, because an alt text is more like a description than a name. We talked about names are short and sweet. You use aria when HTML isn't enough. This is not as common as developers think it is. The select is ugly, it is not this. It is 2026, styleable selects are now in Safari. Don't use aria for selects. This is coming from someone who has had to build a tree view with screen reader and keyboard functionality. So like a file navigator, but this was for DOM nodes.

Raise your hand if you have ever used treewalker or node iterator. This is the second person I have ever met that has used those things. I'm very excited. Please come talk to me after. The most common use for this is tab, tab list, and tab panel. That is usually when you're reaching for aria instead of HTML. For things like this, there are established patterns that assistive technology users expect. So use those established patterns. Announcing additions to the page, another great time to use aria, make a live region. When a screen reader is focused on something, that's being announced. If something is added to the page somewhere else, they're not going to know about that. So if you put in a live region, something like a chat, notifications, timers, then they will eventually get that notification. It depends on browser use and how they have been implemented.

But they will eventually get a notification for something that they're not currently focused on. Another great example, grouping interactive elements outside of a form. Div rule equals group and an aria label equals something is effectively the same as field set and legend. If you don't like the styling of field set and legend, just overwrite it with CSS. But this is super useful for things like menus, menu bars, and toolbars when you need to tell someone, hey, this whole group of buttons, you don't want to have every one unless you're styling your font. Then go ahead and get into this and start hearing what every button does. So hopefully you now understand that aria is a garnish. It's not a full-blown topping. Use landmark rules, please, please, please, please. When you hear don't use aria, there's probably an HTML element for that and no aria is better than bad aria.

Here's a QR code for these slides and that has ways to contact me as well as the full blog that this talk was based on and more accessibility learning resources if this has piqued your interest. Thank you. Woo! Well, first of all, I wanted to thank you for being so inclusive when you said that you don't read space, space or tab, tab. So we don't have this argument over here. Thanks a lot for being so inclusive. That's right. All right. First question. Ah, I see people are putting their names in. That's very nice. My comment worked. Jens de Wolf is asking, Abby, I have a dialogue that lives in top layer. The trigger for the dialogue lives in main. Can or should I have landmarks inside that dialogue if they are visually present? Is it better with title enclosed or main with primary dialogue content? So landmarks are for the general structure of your page. They're not usually for just one single element. It would be like if that dialogue is in the section about getting more information about your product than it would be like in the about section. It doesn't need to be that granular. If that makes sense. And if it doesn't, come talk to me later and we'll talk about it. Well, I guess now you can use just the generic dialogue element and that would solve a lot.

Right? Yeah. Yeah. Using semantic HTML is best. Unfortunately, I'm in view land. So we use a lot of teleport to solve these kinds of problems, but I'm happy to talk about it in depth afterwards. Investigate together with Jens.

All right. Next up from our dear visitor, Anonymous. Would AI enabled assistive technologies make area obsolete? So AI enabled assistive technologies would be something ideally that would be able to crawl into the HTML and make its own accessibility tree is what I think this question is asking. That's kind of like asking, is the AI going to start rendering things instead of the browser? So when you hand a web page to a browser, it creates that accessibility tree with all of that information. It would be more likely that the AI would be able to create more connections and context from the accessibility tree than replacing the HTML that creates the accessibility tree.

Yes. Or do I not know what an AI enabled assistive technology? What's sprung to mind for me is the latest demo that Apple gave. Okay. A blind person walks around and she just points her phone. She throws two shirts on the bed and says, which one is the red one? Ah, okay. You could also point your phone at a screen. Like where's the menu button? Well, that's kind of hard. Move the mouse two pixels up, two pixels left. Maybe a bit harder than which is the red shirt. It is. It is. And you could point your phone at a website and get basically the same amount of information as an accessibility tree. But the accessibility tree is generated from the HTML and ARIA. So it's a different layer I think. True. And of course, we need to be mindful of the environment. So use AI the least possible.

Ben is asking, what's your opinion on visually hidden text? I don't know what the context of this is. I visually hide text. So it depends. Like if we're talking about something that you don't think an ARIA label or an ARIA described by is useful and you want the visually hidden text there, as long as it's in the correct DOM order, that is totally fine. But it's when you start ignoring DOM order and how a screen reader will go through the page and put it somewhere way else and then it has no context or relation to the thing that it's actually tied to, that that starts running into issues. For things like the button examples that I gave, where they should have text content, that's how they get their name and links always need content, it is totally fine to use that text content visually hidden on the page instead of an ARIA label. And it's not reaching for ARIA first, which is what the whole talk was about. As long as the users can get the text. That's the most important part, right? Yeah.

Next question from Tobias Brenner. Do you have best practices for accessibility for chart or diagram-heavy pages? Yeah. It's tough. It's tough out here with the charts and the diagrams. There are several resources. I think I have a couple in that last link in my slides. And if I don't, please let me know. But it is very difficult to the point that there is an entire sponsor here, I think. High charts. High charts, yeah. That has solved this problem with a component library. It's like asking if I have best practices for an entire component library. Obviously you are trying to give all of the information that a visual user would get from the chart, but that means that you have to describe relations of things and lines and all of that kind of stuff. So it gets nitty gritty. I should have some resources for it, because I honestly don't have enough time to cover it in this Q&A session.

I should have some resources for it, because I honestly don't have enough time to cover it in this Q&A session. No, but I think, Tobias, you should check out high charts. I remember from their video, their demo video, the first USP they mentioned is 100% accessible. So that's a good first USP. I was very surprised that that's in their demo video. I have no stocks in high charts.

Abby, toasts and live regions. Opinion? Opinion is don't annoy the user, but tell them when things are happening. If you are a visual user and you see that there's an error, a screen reader user should also have that information. So when something is added to the page, a live region is good, but you don't want, like, if you have a timer you don't need to announce every single second, really? That would just be like, I get to read half a sentence. Timer, timer, timer, timer, timer. I get to read half a sentence. Timer, timer, timer, timer.

So I recommend using a screen reader yourself and discovering what your page experience would be like if you were a screen reader user. My video had me with the voice turned off and I was showing the text, because unlike people who typically use screen readers, I have more trouble hearing and processing sound than I do reading. So don't do that. Don't do what I did. But turn off, if you can, just block your screen entirely and use a screen reader to navigate the page and find out what your own website experience would be like if you were visually impaired. And if you've never done that before, I trust you, it's more painful than you think.

Yes. And it will incentivize you to optimize. There's a challenge that a lot of people give where you don't use your mouse for a day. Just use the keyboard and you will discover how annoying the internet is when you don't have a mouse. Ouch.

Abbey, what tools would you recommend to improve ARIA use? I think this is like what Mark Erickson was saying, where we've kind of gone in the opposite direction with telling people not to use ARIA to the point that they're afraid of it. I would recommend studying ARIA, learning about it, using it and using it with a screen reader to understand what you're creating when you use these attributes and roles.

And if your company has the budget, observing disabled users navigating your app will incentivize you to optimize for them. The only way to know if something is accessible is to test with users with disabilities; you'll be amazed at the speed at which they use a screen reader. New accessibility requirements for web pages, like WCAG 3 and the European Accessibility Act, are on the horizon, impacting contrast math and standards. Stay informed and prepared for these upcoming changes.

And if you see the problems that they're facing or the speed that they can only get through, then it will really, like I said, incentivise you to optimise for them. Yep. The only way to know if something is accessible is to test with users with disabilities and you will be shocked at the speed at which they use a screen reader. It is, I can't even hear it. They'll have like the speech at like x 40 and you'll just hear, and they'll be like, okay.

Yeah. Three is supposed to come out, which I know involves recalculating contrast math entirely. And I know we're in Europe. So the European Accessibility Act is something that you need to know and learn. I am not prepared to speak on the difference between WCAG 2 versus WCAG 3, but I should be able to find you some resources if they don't exist in my learning resources thing. Just let me know. Cool. Doug is coming for you. I know. I always are.

A nice question. Very time relevant. I clicked the wrong button. How do I make AI more accessible? So you've got to think about user experience, right? We've talked about when things are added to the page using live regions in a chat, we also need to make sure that the interfaces that we're building are accessible for people that aren't sighted and using a mouse. Other than that, I don't really know. Could be a long discussion. Could be a whole talk. If you want to give a talk about that, that would be great. I'm thinking now how it will be to use like Claude in the terminal with the screen reader and the text... We were both. Ouch. All right.

We were both. Ouch. All right.

Next question from our friend Anonymous. Abby, great demo. I'm the developer with the dressing. Do you know some good way to automate testing of screen readers, for example? So automated testing for accessibility catches... There are a bunch of different numbers floating around, but like 30 to 40% of errors. The best way to know if a website is accessible is to test with users with disabilities. There are resources from IBM that will take you through the entire manual testing plan that an accessibility auditor would do. So you could automate with... I know there are even dev tools for user flows through your page. You could automate tabbing through your page or something like that and watch it yourself or get something to tell you if there isn't a focus outline or anything like that. But 100% of the time, the best way to find out if your website is accessible is to test with users with disabilities. Word. All right. That's all the time we have for Q&A. Actually we've gone over and I've gone into people's lunchtime, so I see some mad faces. So Abby, I want to thank you for being here with us. Thank you. Thank you.