Landmark Elements, Forms, & Buttons

[00:00:00]
>> So landmark elements, kind of similar to headings. Headings are used more. In all of the feedback I've heard from people who use screen readers, headings are used a lot of the time. Everyone's different, of course, but landmark elements are technically a best practice. One of the things in the X Extension that if you turn best practices off, any rules related to landmark elements will be excluded.

[00:00:26]
They're nice to have and you absolutely should include landmarks because why not? Just know that if you only have time to prioritize one over the other, put headings at the top of your list, but landmarks are great. There are things you create in your templates that you kinda just set it and forget it mostly.

[00:00:50]
If you aren't editing templates or views that are for bigger sections of your pages all the time, you might not even see these elements, components might get flooded into these landmarks. When I opened up the Accessibility Insights extension earlier, we had things for headings and landmarks, so just to refresh there.

[00:01:12]
So we have nav, main, section, header, footer, aside, and there are some rules with these. So certain landmark elements need to be what's called top level. Main is one, I think a side is another one. So you can't nest main inside of nav or a side, that one's a little bit surprising.

[00:01:35]
That one has to be top level, kind of like as a sibling to your main element.
>> When to check if results of aXe are a false positive? I'm always confused about landmarks, and specifically about role equal groups that sometimes are used on list items results that display as a result.

[00:01:58]
>> Okay, so the question is about aXe results, so a lot of these things will come up in aXe results. I'm gonna turn this Landmarks thing off. So the question was about when to know about Landmark element results. So if you're not working on best practices, if you have to prioritize, you have a lot of feedback, turn those off, fix them later, maybe come back to them.

[00:02:25]
If you are trying to fix them because you have bandwidth, it's the appropriate time what have you, read through what it's telling you. So sometimes it will be reporting that there are roles and elements that there shouldn't be, like for lists, those have default roles. So we have lists here, UL, and OL and LI for the list items.

[00:02:46]
Those have roles built in, a lot of these do. That's kind of the overlap that we haven't totally discussed yet of ARIA and HTML, is that what makes them semantic is that they have meaning, whereas divs don't. And so lists have roles, so, if you are putting a role of region on one, I think what aXe might be telling you is that, you could put the region role on a div that wraps the list.

[00:03:14]
So that the list keeps its semantic roles without us overwriting them. So that could be one thing, if I'm following the question. So one other note about section and nav, anything that you've repeated. And we've actually seen this already, just kind of in the rendered result of what we have in these slides, is that I have two navs, and I put an ARIA label on those so that you could tell which one's which.

[00:03:43]
Cuz especially when you open up a voiceover in the rotor, I think it won't even show section elements if they don't have labels on them. But if it was just section, section, section, section, that's like the new div. [LAUGH] So they've learned kind of through, practice of evaluating a lot of web pages that sections that aren't labeled are kind of treated as divs.

[00:04:08]
So if you want them to actually be sectioning elements that come up in the screen reader as major sectioning sign posts, you can label them. And if you are worried about ARIA label getting out of date, cuz sometimes those strings just get set and forgotten, you could use aria-labelledby, it's really similar.

[00:04:28]
But instead of taking a string value for a label, you can point it at another element, like a heading. So if you have a piece of content inside of the landmark, aria-labelledby is pretty great for labeling, cuz you can just sort of double up on content that is visible, that won't get out of date.

[00:04:45]
So that's one technique I would recommend for landmarks. So lists, they're awesome, don't sleep on using those because if you have groups of items, like lists of links. You can nest lists, they're great because they automatically count in a screen reader, it'll say, list, five items. There is one gotcha in Safari and VoiceOver that I have to tell you about.

[00:05:13]
Safari, again in there, heuristics of how web pages are actually written out in the wild. They've made a counteraction of, if lists have their lists style removed with CSS, there's no dot, or what do they they call that, a marker, they will actually not call it out as a list in a lot of cases.

[00:05:37]
So if you see lists with role list bolted on, that might be why, is because you can get Safari to treat it as a list, no matter what, if you bolt that list back, or the roll back on. So I have an article if you're like, what, what is she talking about?

[00:05:53]
[LAUGH] There's a link here, where Safari might need a little help. Scott O'Hara did us a solid and wrote a really great article on this problem. So if you do use Safari and VoiceOver, a lot and you're like, why are my lists not announcing as lists, that might be why.

[00:06:13]
And speaking of aXe results, something that might come up is that lists have rules, that they can only have list items as direct descendants. So if you have divs mixed in with your list items as siblings, you might get some failures in aXe, cuz it I think it messes up the counting of the lists.

[00:06:35]
So, that's something I've seen where the markup, maybe we don't check it often enough, like what is our framework rendering? Sometimes the frameworks will complain, too, which really helps us out so we can catch the stuff earlier. But I think with all of this, especially if you're using a framework to build your UIs, look at what it's spinning out, [LAUGH] what actually gets rendered, cuz that can be very eye-opening.

[00:07:04]
So forms are a huge part of this. There's some really powerful elements for accessibility, starting with the form tag. Within a form tag if you've built anything for the web, you've probably worked with a lot of these elements. Field sets and legends are awesome. You can group form controls together and give them a group name with a legend, and you can style those.

[00:07:30]
I think legend you might be able to make screen reader only, I'd have to go and double-check. But the big thing, the big story with form controls is that they have to be labeled, or else, where do you even filling in if you can't see it? What does this checkbox do?

[00:07:47]
Can I opt out of your newsletter? Everyone should be like, no, we have to label that, nobody wants extra newsletters, right? So we need to label every control. Extensions like aXe and WAVE and Accessibility Insights are really great at pointing that out. If something went wrong or you missed it somehow, there's two ways to label them.

[00:08:11]
So for a form input, you can use the for attribute on the label. In React it's HTML4, because JSX and HTML and JavaScript are all mixed up. So to make sure that the compiler knows we're talking about the label for in React, it is the HTML for, and then the ID.

[00:08:33]
It will match that label and the input or select, whatever form control it is. It will say these two are joined, and it will then expose that label as the name for that form control. Implicit is just when you have a label element that wraps an input. The label text will apply to that input as well, it's pretty easy.

[00:08:55]
And they're getting easier to style, thank goodness, [LAUGH] we really needed that. And then one note about labeling and naming, only certain elements can be labeled with things like ARIA label. So that question about the role region, I think even on the SoundCloud site that we tested earlier, there might have been an aXe result for ARIA label not being like you can't use it on certain elements.

[00:09:23]
I think it's limited to role of image. What I tend to do for that type of thing if I'm like, can I label that element, I'll go and pull up that ARIA specification. Let's go do that real quick as a practice. So ARIA 1.2, let's say I wanted to look up ARIA label, I'm just gonna search for it real quickly and then the first mention of it I can click on.

[00:09:51]
So it will tell me what it is, and then what elements I can use it on. And so this process of checking, where can I use it usually can be helpful. I'm actually not really seeing what I was looking for here, but whenever you're going to use something, it would be worth going and doing a search to make sure.

[00:10:15]
Your tooling will probably also complain at you, which is helpful like, hey, you put an ARIA label on a div, you can't do that. Okay, thank you, tool, thank you for telling me. So those are some of the practices that I use. I'll look at MDN, Mozilla Developer Network, I'll look at ARIA if I'm wanting to go check up on something.

[00:10:36]
Buttons and links are a huge one, somehow these are the most basic elements that we managed to screw up. I didn't know about them either, I mean I put click events on divs just like everyone else in the beginning, then I learned how awesome the HTML button is.

[00:10:53]
So it's focusable for free, it has a built-in role, and you can put a click event on it and it will work from the keyboard, a div will not. Links are also awesome, they have built-in behavior like history. They need an href attribute to be reachable with the keyboard.

[00:11:10]
So sometimes things that are, have an onClick but not an href, those links will not be accessible, so just so you know that little detail. And this is kind of the big thing with buttons and links. Buttons toggle things, interactive things in your interface, launching modals that are not deep-linked, maybe they toggle a setting or something.

[00:11:33]
Links navigate, so if there's anything that needs to take you to a location, if you can use an anchor link, that's gonna be the best choice. And what I hear about the most for this is sort of an anecdote to think about is when, blind people call support, or anyone who's using navigating by voice.

[00:11:52]
When they call customer support to get help with an online product or service, and they have someone talk them through how to use it. If the links don't look like links and the buttons don't look like buttons, or they're not coded that way, it can get pretty confusing.

[00:12:08]
So, we try to make links look like links and buttons look like buttons. That can get pretty tricky, cuz CTAs as we call them, calls to action, they all look like buttons. Or the buttons look like links, and it's kind of just we do the best we can.

[00:12:25]
Just know that those work and they're accessible if we use them the right way. So then lastly, the last one I wanna mention here is details and summary. So this is like a built-in accordion widget, they're keyboard accessible. They work pretty well and you get default elements, be sure to test your implementation to make sure.

[00:12:48]
But they're awesome. If you don't already know about details in summary, they're pretty great. So sort of an overview of the elements that you should definitely try to use if you can. Sure, question?
>> Have you used the HTML5 dialogue element?
>> Yes.
>> For doing modals? Would you recommend that or would you recommend not using that?

[00:13:10]
>> I would recommend it, yeah, so the dialogue element, and really it should be on this list, maybe I'll add it, but it has a dialogue role built in. It has the open and close APIs, like that is definitely an example of something that's built in. I think with some of these implementations, we have to go and check, are they really accessible?

[00:13:30]
Another one that comes to mind is the default date picker. I actually haven't had an example of that earlier and we didn't dig into it very much, but sometimes we are like, great, there is a default thing. Some of these newer components that haven't quite caught on, they're part of the reason might be that they're not totally cross-platform stable.

[00:13:54]
So we wanna go and check, for the dialogue I think it works reasonably well. I think there might have been some consensus building on, what focus should be sent into automatically when it opens. I think that was a sticking point, if I remember correctly, but I think it should work reasonably well, would be a good thing to test.