Accessible & Semantic HTML

[00:00:00]
>> So we'll start to get a bit more technical now and apply things to actually go and improve accessibility that we see. Our code base, we'll use React, but this stuff applies no matter what type of a front end stack you're using. So you could be working with the hottest new JavaScript framework.

[00:00:19]
I really enjoyed Svelte recently. Speaking of data visualizations with D3, you could be generating things that way. Or you could use Astro or use GraphQL APIs or whatever the framework of the week happens to be. If it generating a front end that users are interacting with, accessibility is a concern.

[00:00:46]
So maybe something you could do, especially if you're newer to a framework, but maybe you're more familiar with HTML, CSS, and JavaScript, an approach you could take would be to do some prototyping upfront before translating it into a framework. That's something I do a lot when I just need to tell kind of quickly in a lightweight manner, is this going to work?

[00:01:11]
Before I go and do all of the work of integrating it into my stack, I might do a lighter weight version of it. Maybe I do use React. I like React, but just saying that if you have constraints that it would benefit you, you can consider doing some prototyping to just feel more free while you're testing out an idea or an experiment.

[00:01:35]
And whether your output is in HTML, CSS, or in JavaScript, or more robust framework, the basic always apply. So it really is about what gets rendered. Is it well structured using as many default HTML elements as possible? Cuz there's a lot, so what do I mean by well structured?

[00:01:58]
So HTML provides structural semantics, they're really helpful in screen readers. We saw earlier there were landmark elements, and buttons, and forms, all of those elements that are not divs have meaning. [LAUGH] As we'll learn about, we did learn about the accessibility tree, and so that you might start to be able to connect how tags become objects.

[00:02:23]
It's a very robust process that, if we use semantic HTML elements, we can help that out by actually creating an accessible structure. So it's non visual, and it really goes beyond the way that something looks. There are so many defaults these days, fortunately, form elements are getting easier to style here in 2023, we have some easier to style form elements.

[00:02:54]
Never thought I'd see it, I'm very happy to see it, though, it's awesome. I think form elements being hard to style are how the legacy of inaccessible stuff came about was because we were trying to meet client, needs customer needs. We couldn't style it and still use the default HTML element.

[00:03:13]
Well, it's really hard to replace some of that functionality because we get a lot for free with things like links and select, trying to create a custom select. There's features in that component that you might not even realize. So you have to recreate those. If you make your own version, it can be done, just to say it can be done accessibly as well, but you don't have to.

[00:03:36]
If you can advocate for using the default HTML element, pose it as, hey, we're gonna save time and money, [LAUGH] you might be able to convince your teammates off of the heavily styled customization ledge and just use the default thing, potentially. So I would recommend checking out a Mozilla developer network, their list of HTML elements.

[00:04:00]
I learned something new every time I look at that. I'll even go and refresh my memory of, how does that element or that attribute work? I've been doing a lot of stuff with forms recently, and so I definitely went and looked at the reference to go and make sure that I was aware of everything available to me with the defaults.

[00:04:22]
So when it comes to HTML, we wanna use semantic HTML whenever we can. We also use generic HTML like divs and spans as wrapper elements. They're great for styling. I do a lot of layout with CSS Grid and Flexbox. And so, I'm definitely adding generic elements to give the right structure to match my layouts and things.

[00:04:45]
But those sort of get ignored, those divs are not going to be put in the accessibility tree, only semantic HTML elements will, so we need a combo of both. So, I have kind of a funny graphic here from South Park that says, a Marklar walks into a Marklar.

[00:05:06]
Marklar ask the Marklar, do you have any Marklar? The Marklar shakes its Marklar and says no, we only have Marklar. That would basically be an analogue to div soup all the way down, just like divs solid. So that's what we wanna avoid. Here's a screenshot of div soup.

[00:05:24]
It's a long tree structure of div div div div div. There's no accessibility information here. I see a div role button buried in there that ARIA disabled. But it's a div, it's not focusable from what I can tell. So it might as well just be a div cuz it doesn't have all the other things that it would need.

[00:05:47]
I think that might, I see a role progress bar. [LAUGH] Otherwise, I think that might be the most divs I've seen in one place in a long time. So I think we can do more than that. I mean, any web page is probably gonna have a need for more semantic HTML, so we should use what we can.

[00:06:07]
So starting with headings, we can use h1 through h6 headings to create an overall page outline. We wanna try and choose the right heading level for the content, not based on the way it looks. So that's kind of pitfall number one of what I see a lot, is you'll get class names or heading styles, they're called h1 through h4, whatever, you have a style guide.

[00:06:35]
And the design just leads you down this path of choosing the heading level based on the way it looks, cuz that's in the design, right? Well, we need to pick the heading level based on what the content is. So if there's an overall page structure that we can slot this into, like h2 comes after h1, h3 comes after h2, and it creates that structure, right?

[00:06:58]
I think of it like in Microsoft Word, how there's an outline that you can make with Roman numerals and Google Docs. Everything's indented and it all falls under everything hierarchically. That's what headings will do, they will create that structure so that if you can't see the screen, you can still digest it and get an idea of the hierarchy of content.

[00:07:24]
There was, at one time, an HTML5 heading algorithm that sort of has been haunting us because it was never really implemented for assistive technology. The idea there was that you could start h1s over again in excerpts, so they were more portable, but it never really worked. So, we wanna scratch that, [LAUGH] unfortunately, and have an overall page outline.

[00:07:51]
So, one h1, we try and go in order, just so that the content does kind of, you can tell from looking at just the heading structure what's on it. So, landmark elements. Question?
>> So it might be related and feel free to find it if it's not. But I guess on a similar note when you're using React components, or any kind of like UI library, how do you figure out what a heading should be when you're trying to make a reusable component.

[00:08:22]
Because it feels, ell, if I placed this heading here, it's an h2 for now, but then if I place it in this other part of the UI that gets great, months from now and like I didn't anticipate any of this, what heading level should it be? It feels like maybe the options like polymorphic components where you just set it when you're using it, but I don't know if you have any other tips?

[00:08:47]
>> Yes, so great question. I'm glad you mentioned it. So, when you have to plug a component in and you can't guarantee where it goes, I think the the option I've used for that is to make the heading level configurable. So, being something you pass in. It would be nice if that was automatic.

[00:09:05]
So I don't know of any tools that are automatic like that. I mean, maybe Facebook has something like that cuz they're huge and super advanced. But you if you can pass in heading level to a component, you can have React kind of combine the tag name you pass in, and you can generate elements based on tag names dynamically that way.

[00:09:28]
So that's one technique. There is an ARIA role of heading with ARIA level. It's not great because then you're putting ARIA on something, rather than using the default, which is the h1 through h6 tag. And you'd still have to figure out what level it had to be. The only thing it would save you is not having to generate an element kind of dynamically.

[00:09:54]
But I think if you're gonna do one, you might as well use the default HTML element first. But yeah, I'd say probably passing in the heading level. It's not that elegant. I guess if you had some way to magically just read the overall page, it would have to be done at compile time or something, and that seems maybe too magical.

[00:10:21]
It might be not the most elegant to put pass in tag names when you're using them, but it's also not too magical. So it's easy to grok, I think that code that's easy to understand has benefits. Okay.