Accessibility Tree

[00:00:00]
>> The accessibility tree. We've seen this in that dev tools inspector. The accessibility tree is similar to the DOM, the document object model, in that it is a tree representation of objects on a page, but it's only the things that are interesting to accessibility. So, semantic elements, not style tags or script tags or comments.

[00:00:25]
Like a lot of that stuff that you see in the DOM, at least you can, it might not have objects with it, because basically the way that this stuff works in HTML is we write an element or a tag, that tag gets parsed. Turned into an object, the document object model, those objects and when they become rendered as elements have all kinds of information.

[00:00:48]
That's where the properties and the attributes, they do a lot of things. Some of those things are really relevant to accessibility, so there is a kind of separate structure that's created by the browsers and our platform. So I'm on a Mac, there's MacOS accessibility APIs, on my iPhone, I have iOS accessibility APIs, Windows has its own, Android, and so on.

[00:01:13]
So there's slight differences in these accessibility APIs on your actual platform, your computer, but they work with web browsers, and this is why standards are so important is because we're coordinating all of this, right? But the accessibility tree is in all of these platforms, and it's what screen readers use to announce things.

[00:01:34]
So, that all the extra cruft is stripped away. And it's helpful when we debug using tools like the Chrome accessibility tools cuz it'll show us what's in the accessibility tree and we can get pretty far before we actually have to turn on a screen reader. Like that tool was not around when I started and it's awesome.

[00:01:56]
So let's look at the accessibility tree right now. I just inspected the page, I can go over here to Accessibility. And so it shows me there's some generic elements. There's an article tag, a main, a paragraph that has static text and a link in it. So for the link, for example, I can see that its role is link, and when it's an anchor tag, it just gets that role of link by default, like that's implicit, it comes with the element.

[00:02:26]
It's like a main, has a main role, like those roles, this is where ARIA all comes together, is that it's relevant in this accessibility tree. And we can actually, we can look at this now and we can see kind of how it relates to the DOM, but there's way more stuff over here on the DOM side than there is on the accessibility tree side.

[00:02:49]
And I think they limit what you see in Chrome, at least for performance reasons, but you can expand it. Not that you would necessarily want to. See, they're making me reload if I really wanna do that. But this is how screen readers, most of them, some will look at the DOM also, I know JAWS on Windows will.

[00:03:11]
But you can inspect a lot as developers, this should be a regular testing tool. So we wanna know what it is, what it does. And I wrote about the accessibility tree a while back when I was learning about accessibility and performance. So I have this graphic that I made kind of describing the Firefox Gecko engine's rendering flow.

[00:03:36]
And so, the accessibility tree, I kind of estimated, where it would land in the rendering process. And I did an interview with Marco Ziha, he worked at Mozilla in that article on my website, but it's really cool to go back and read. He gave me some really interesting details about how the accessibility tree works, so if you're curious, you can go read that.

[00:04:03]
So we visualize and test it with Chrome DevTools, Firefox has an accessibility tree inspector as well and Safari. So we have a lot of tools at our disposal, we just want to know what is this thing? Well, it's what screen readers use to announce information. The roles, what are things, the states, what state are they in, the properties, like, are there any names, any other characteristics?

[00:04:31]
And so this matters because we want to know, what is HTML doing for us and what is ARIA doing for us? Well, they all come together, so it's all part of the rendered output. And I think a good example of why you wanna understand this, the distinction between HTML and ARIA, it came up for me at work.

[00:04:51]
My coworkers were curious when to use the disabled attribute on a button or a form control versus aria-disabled? They've seen both of those but weren't quite sure, what does that do? Well, disabled is built-in HTML. It's an HTML attribute that will disable an input. It will remove it from the tab order.

[00:05:12]
It will also tell an accessibility tree, or in the accessibility tree it will affect that element there, too. Whereas aria-disabled will not make it anything with the keyboard, it won't change the keyboard. It won't gray it out to make it look disabled, it will only touch the accessibility tree.

[00:05:31]
So it will affect a screen reader user, but not a keyboard user who isn't using assistive tech. So I think we want to know, what are the effects on the accessibility tree? I think we saw some of that stuff with the CSS visibility methods. Things like opacity and visibility, those have effects or not.

[00:05:52]
So we kind of want all of these tools in this whole picture, we wanna be aware of it so that when we are debugging or making recommendations that we kinda know what ARIA does and doesn't do for us. And the accessibility tree is a way that we can visualize it.

[00:06:08]
So I have a couple of links in here, the one from my site on accessibility and performance, there's also a really great article in here on web accessibility with accessibility APIs on Smashing Magazine. I think it might be written by Leonie Watson, and she is blind and amazing.

[00:06:25]
So I love reading stuff from her about how screen readers work. So I'd recommend that.
>> It can happen that a long text has text overflow ellipses. How would we handle that case?
>> Long text with ellipses. Yeah, I guess talking about accessible names. So, yeah, there was an attribute for a while called Long Desk that was meant for longer descriptions of things.

[00:06:54]
I think that might have been deprecated, it was never really a technique that carried through. But I think some of the techniques that you can do with aria-labeledby give you more flexibility over things like aria-label. So aria-label is meant for short things, just like alt text is on images.

[00:07:14]
Aria-labeledby, you can use to point to entire groups of elements, like a marked-up table or a heading and some paragraphs. You can put more content into an element and reference it with aria-labeledby. So that's probably what I would recommend for some of that technique. As for the ellipsis, the content that's cut off, I guess how does a sighted user get to read more or do they?

[00:07:45]
If it's cut off for everyone, then it's kind of, cut off for everyone. [LAUGH] But if mouse users or sighted users have a way to read more, we just want to make sure that mechanism is accessible, that's what comes to mind anyway.
>> About facts sections of a page.

[00:08:03]
The name of the fact might have a H2, but the question under it should be H3 to respect the whole tree of accessibility, correct?
>> That sounds correct. I'm not quite sure if that's reference to the slides or just something else. But yeah, we should try and have an overall heading hierarchy.

[00:08:24]
And you'll see in the accessibility tree it will show heading levels, so yeah, all that stuff kind of carries through to what objects are in the accessibility tree.