So, for instance, I’ve got this input here, wrapped in a label and that’s going to produce a visual UI like the one that you’re seeing here this radio button.
But that’s also going to create a spoken UI based on the built in semantics of those native HTML tags. Now, if you’re not quite sure how all of that happened, or why those semantics matter be sure to check out our previous episode on semantic. So I’ll include a link down in the show notes and we can also maybe drop in an annotation up here for you to click on. I just I have some background on how semantics work and why those are important in the first place now.
This is all good and everything, but there are instances where a simple layout in native HTML just aren’t going to cut it and so to handle these situations. We have the web accessibility initiative accessible, rich internet applications, spec, which is a bit of a mouthful. So you oftentimes see this referred to as wai-aria or maybe just Aria, so audio works by allowing you to specify attributes on elements which then modify the way.
Those elements are translated into the accessibility tree. So let’s take a look at a really basic example. Just to show how this works, so, if you create a a plain checkbox a screen reader is going to announce it. As you know, a checkbox it’ll tell you what its label, if it has one like we do in this case, where it says, receive promotional offers and it’ll also tell you the the state of the checkbox right, whether it’s checked or not, but let’s say you’re in A situation where, for whatever reason, you need to implement your own check box using something like like a div right, maybe you need to style it in a really special way.
So, in this case, we’ve got a div checkbox we’ve created here, and the screen reader is going to give the user really like no indication that this element is meant to be a checkbox. It might announce the the text inside of the div there, but it’s not going to tell you the role of the element. I can say it’s a checkbox. It’s also not going to tell you the state so excited you sure is going to be able to see these visual cues and they’ll be able to figure out that this is a checkbox.
But nothing is going to be announced to our screen reader users and that’s a really big problem. So using Aria, we can actually tell the screen reader about this extra information here up at the top, I’ve got some custom checkboxes just created using gives down at the bottom. I’ve got some checkboxes using the native input element so using voiceover. Let’s see how these are announced differently: voiceover, I’m chrome, custom checkboxes in custom check intense group with three items there and then slices group with two items: heading ten times check, check box and then slices uncheck, checkbox voiceover off.
So you see there that the the div elements just are announced as groups. It doesn’t indicate to the user in any way that these are checkboxes where it’s the native element. It indicates it’s a checkbox and it tells you the state whether it’s checked or not. So, let’s see if we can add some Aria to improve upon this so over in my dev tools, I will select these the checkbox elements and I’m going to start off by just giving them a role of checkbox and I’m also going to give them a state Of Aria, checked of either true or false, depending on you know the actual state of the element there.
So if a role checkboxes to the one Aria checked equals false and let’s try it again using the screen reader voiceover, I’m dropping custom. Checkboxes 10 pens check the checkbox and then slices contract checkbox always go over all. So adding that role and Aria checked attribute causes the middle Union accessibility tree to actually have the desired role and state without changing. You know anything else about the nodes, appearance or its behavior, which is pretty awesome right, we’re just adding in additional semantics using Aria.
So in terms of the accessibility tree, what ru does is it really allows you to subdue like tree surgery? So you take the accessibility tree as generated by plain HTML. You add Aria to that, and now you get a different accessibility tree and it may be subtly different or it could be radically different, depending on what attributes you use, however, keep in mind that this is really the only thing that ru changes.
It doesn’t change anything about how the element behaves on the page. For instance, it’s not going to suddenly make your element focusable, it’s not going to add keyboard event, listeners for you or anything like that, or you does not change behavior in any way. It really only is for adding in additional semantics. So if you, you know, if you’re making a custom control, it’s really on you to make sure you go back, and you also add in that keyboard support so you’re kind of like maintaining that that consistent experience for your users.
So now that you understand more about what ru is and kind of some of the basics of how it works, I want to cover some of the things that Aria will. Let us do in our application, as we saw in that check box example. Aria can add semantics to an element where no native semantics already exists. So, for instance, you take a div element, it has no built-in semantics, but we can use Aria to be able to role.
We can use already to give it a check State, for instance, build a custom check, box or radio button, or something like that, or you can also be used to modify existing element semantics. So, for instance, let’s say I’ve got a button element that I want to. Actually turn into more like a toggle button, so I can on/off switch type of control. I can give it a roll of switch. I’m give it an already check state of true or false, and now I’ve sort of modified the semantics of this control, and now it’s more of a even more specific kind of thing.
It’s like a toggle button right to switch button. It’s important to note here, though, that the switch rule is part of the newer aria 1.1 spec. So, as I’m recording this, you know there’s probably a number of assistive technologies which do not support this role. Just yet, just like all web standards. Aria is you know, constantly evolving and advancing to try and keep pace with new UI patterns, so that’s something important to realise as well right, if you, if you come across an aria rule, you also want to check for the support of that role in assistive technology To make sure it’s widely supported, and then you can use it another thing or you can do is it can express semantics and UI patterns which really like don’t already exist in HTML, and I think this is where Aria kind of comes into its own Aria.
Basically, will let you create accessible widgets, which are not possible using plain HTML. To give you an example. Here is like a tree: widget component, okay, we can take an unordered list and add all your rules of we tree item and group and add an already expanded attribute to a few those children and now we’re expressing the more rich semantics of this tree element and Again, there’s no tree tag in native HTML, so it’s something that you know we wouldn’t be able to build otherwise without aria, which is really important.
Another thing we can do and as we saw this in our previous episode on labeling or you can add extra labeling and descriptive text to an element right to give that element an accessible name. So, for example, if you have like an image only button which doesn’t use an actual image element, so you don’t have access to an alt attribute or anything like that to put alternative text on it. You can still use Aria.
You can use Aria label to give that element its own accessible name, and that way you can have it be announced properly by a screen reader to those users, or you can also express semantic relationships between elements which go beyond just like standard, dom parent-child sibling relationships. So, for example, a more complex relationship is something like this element controls that element over there.
Even if they’re not like you know, direct parent-child or anything. So in this case right here, I’ve got a button which controls whether a particular part of the page is visible or hidden, and it does this in the form of kind of a disclosure widget. You can see here where it shows advanced settings. We’ve specified using Aria controls – that’s actually controlling this group of elements down here for these Advanced Settings checkboxes.
So even though they’re not parent-child, they’re, actually sort of like siblings. We can create this new relationship indicating this element over here controls that elements over there, which is really cool and finally, Aria, can make parts of the page live, so they can inform assistive technology right away when something changes – and we saw this in our previous episode On building alerts, so we add role equals alert to some element.
We drop some new content into it and then it’s going to announce that immediately through assistive technology to the user. So are you giving you a lot of tools to make sure the experiences you build? Are semantically rich and can be easily understood by assistive technology? Now we’re definitely going to be diving into the subject more in the future, but that about covers it for today. So if you have any questions, you can always leave them for me down below in comments, or you can hit me up on a social network of your choosing.
As always thanks. So much for reading I’ll see you next time, hey. If you enjoyed this episode of Ally cash, you can always catch more over in our playlist or click. The little subscribe button and you’ll get an email notification whenever we launch new stuff on the blog. As always, thanks for reading
Jimmy's Internet Marketing Business Blog 