Semantics & ARIA

[00:00:00]
>> I have to say it, if you're building a JavaScript heavy application, you have to use semantic HTML. It's kind of some of the worst offenders I've seen. Just like when everything can be a div, it will be a div. But we can do better. We have spent so much time already talking about semantics that you should already have some ideas.

[00:00:18]
And here's another reason. It's more pragmatic to use HTML because you don't have to recreate everything. It's like saves time and money, and who doesn't love that? The select element can do a lot, probably more features than we even realize. The button element is perfect example of something that's powerful and simple as well.

[00:00:39]
So we want to create structure and use the right element for the job, so just another plug on checking MDN, even when you're writing components. I mean, even more so, so that those components bake in things that are accessible, so we should use headings, landmarks, lists, figures, data tables for tabular data, not for layout [LAUGH] and more to add semantic structure.

[00:01:04]
So this is essential for users of assistive technologies using buttons and links. So here's the call out for buttons. This means toggling UI components and being part of forms. Links are for navigation and they need an href attribute to be accessible or reachable, and there's plenty of other elements.

[00:01:24]
So as tech leads, we wanna encourage our teammates to learn about HTML and use it to its fullest potential. It's kind of like a teaching moment that we can say hey, is there a better element for that? I don't actually know. Let's do some research real quick. Let's go look at MDN and see, is there an attribute that would really help out for this?

[00:01:44]
This is a read-only form control. Let's make it into a native input instead of some custom thing. So that's a good kind of a gentle push in the right direction and when you are a tech lead. And then keep that rendered output in mind. What are all these components rendering when they all come together?

[00:02:02]
Are there a bunch of wrapper elements that are adding non-standard attributes? React does complain about those luckily, but we want to kind of check every so often to make sure our lists are well-formed, and they don't have a bunch of extra stuff that doesn't make standard HTML happy.

[00:02:22]
And we can do that because just by checking our source, running acts, and then flipping over to the dev tool side or the element inspector side and just kinda like do a little health check of your markup. And make sure you understand ARIA before using it, so one more plug for that.

[00:02:40]
Just it's so easy to slap it on there. And if you don't have the workflow to test it, that's how really broken things can ship when we don't even know about it. So, yeah, and there isn't always great support. So we looked at ARIA, or the allysupport.io, A11Y.

[00:02:58]
It is pretty effective at at least sharing if things are not well supported. There are some ARIA attributes that were proposed but never really went anywhere like ARIA grabbed. There were some drag and drop proposals for ARIA that just never went anywhere. But if you didn't ever look it up, you might just go, yeah, I'm just going to add ARIA grab onto stuff, and it's really just kind of pointless because it doesn't do anything.

[00:03:24]
It might not hurt anything, but we don't want to just use it and hope for the best. So if you can use, this is very important, actually. The rules of ARIA, share these with your coworkers. If you're really trying to convince someone off the ledge of those putting ARIA on everything, the rules of ARIA, I did not come up with these myself.

[00:03:48]
They are from the W3C and one of their kind of supporting non-normative documents. But that just means it's not as legally binding as things like the Web Content Accessibility Guidelines. But they say, great advice, if you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property and making it accessible, then do so.

[00:04:17]
Do not change some native semantics unless you really have to. So that's like if we talked over the break about whether to mark up a sidebar with a nav element or a list. I said use both because the nav element will be a landmark, and then the list its purpose is to group lists of items.

[00:04:38]
So they have different purposes, and if we use both elements then they can each keep their respective roles. Another example would be the ARIA live attributes. Those exist so that you can put them on things that already have roles. Because there's role status. That does the same thing, but it would have to replace a role when an element already has one.

[00:04:59]
So the third rule, all interactive ARIA controls must be usable with the keyboard. That's a pretty good one. Number 4, do not use role of presentation or ARIA hidden true on a focusable element. So that creates those ghost controls that we talked about a little bit earlier with ARIA hidden, that pitfall.

[00:05:18]
We tend to use inert to get around that, to make sure we're not missing anything. And then, number five 5, all interactive elements must have an accessible name. Hey, we know that one. [LAUGH] I don't normally just read stuff off the screen, but rules are rules. [LAUGH] So what to look for in a framework?

[00:05:39]
This is a question that you had earlier. When you're choosing a Javascript framework or a library like React, Vue, Svelte, whatever happens to pop up, we have new frameworks all the time. There are some things to look for when it comes to accessibility. Support for semantic HTML and ARIA, does it get in your way?

[00:05:57]
Is it difficult to do the right thing? Most of the libraries have gotten pretty good at this. They don't get in your way too much. But they don't necessarily discourage you from doing anti-patterns like putting click events on div buttons and things, cuz they don't really know. It's hard for them to tell.

[00:06:14]
But just make sure that you can write accessible HTML. The routing libraries, does the routing library give you any hooks for accessibility? Do they have accessibility documentation? Is there a way to do it? We talked a lot about that. Is there documentation and community around the framework for accessibility?

[00:06:36]
If you do a kind of gut check in their issue list on GitHub, or I guess that's mostly were open sources. But, if you go through their issues and search for accessibility, how many issues are open? Have they closed some? Have they been nice about it? What's the culture?

[00:06:54]
You can kind of do a little bit of investigating. Have things languished for a long time? And then are there testing tools? It's really helpful to be able to have all the testing tools at your disposal. In React, we're pretty blessed. We have a lot of great testing tools.

[00:07:11]
There's others, like testing library has flavors for more than just React, so that's cool. But then, kind of regardless, like, think like a user. They're not gonna care how something's built. They're gonna care if it works or not. So the rendered output is what's important.