Navigated to episode Accessibility Mechanics.

Accessibility Mechanics

by Jared Smith

recorded on January 02, 2019

Transcript

[Intro Music].

>> MICHAEL BECK: Welcome to technica11y, the webinar series devoted to the technical challenges of making the web accessible. This month's presenter is Jared Smith, Associate Director at WebAIM. And now our host and moderator, Karl Groves.

>> KARL GROVES: All right, hello. And welcome to the January 2019 edition of technica11y and Happy New Year to everyone!

We have our guest here, as the introduction said, Jared Smith. Jared is one of my heroes of accessibility. I've known Jared through the WebAIM list since 2003 and the WebAIM website, the WebAIM discussion list and Jared in specific have been huge resources for me personally since that time. And so I'm extremely happy to see him here. Now, Jared's discussion on the technica11y webinar is going to be the interplay between page content including ARIA, the browser parsing, rendering, accessibility APIs and assistive technologies and this is something I feel pretty passionate about. I have a presentation I give that discusses this that I try to do as often as possible because I think this is core knowledge that everybody in web development needs to understand and needs to understand before, frankly, getting too far down the road of getting involved with accessibility tools and trying to do testing with assistive technologies and all the of that sort of stuff is understanding these foundational bits of knowledge that Jared is going to share. I think they are some of the most important things that anybody can know.

So I'm going to turn the control over to Jared and let Jared give us his presentation. Thanks!

>> JARED SMITH: Here we go. I just had to find the right button to unmute. Thank you, Karl, for the introduction. It's good to be here. I really appreciate the invitation to present today. And the opportunity to talk about accessibility a little bit.

I'm going to try to move this thing -- here we go.

All right. Now we're cooking.

All right, but yeah, Happy New Year to everyone! I hope you had Happy Holidays and wish you all the very best in the coming year.

I am going to speak today about what Karl talked about and I've titled this "Accessibility Mechanics." Now, this is a term that I took from Naomi Watson, my good friend, she has presented on this load. And I tried to really think of a better way to describe this. And "Accessibility Mechanics" is really the best that I could come up with.

So the mechanics, the internals of accessibility, that makes all of these things we put together for accessibility to generate a positive end user experience.

So, I'm just going to dive right into this and start by talking about what we generally refer to as being the web stack: where HTML is the foundational layer of this stack, and then we layer on top of that CSS, and then scripting on top of that.

And generally with the web stack, we want to keep these three layers distinct and separate as much as we can. So, if we look at these three layers individually, our foundational layer of HTML, that's where our structure and semantics happen. Also where most of our accessibility magic happens. That's where we define headings and regions and alternative texts and links and lists and buttons and form inputs and tables and so on and so on and so on. We have the vocabulary of HTML, the language of HTML, that has quite a few things that we can define to make things accessible. These are things that generally happen under the hood of our page to support optimal accessibility.

I sometimes tell developers, "full stack developers," I'm doing some air quotes here, "full stack developers" that really if they want to differentiate themselves from their peers to master HTML. And it's interesting that most of the accessibility issues that we encounter happen -- tend to come just from a lack of understanding of foundational HTML. And that's interesting. I don't think that HTML is difficult. But, I think that a lot of developers are not that familiar with it. So, it's a great way I think to really support accessibility and to really differentiate yourself from others is to absolutely master the semantics of HTML. Excuse me.

Bruce Lawson has a great blog post just published a few weeks ago titled the "Practical Value of Semantic HTML". I encourage you to go read that. It talks about just the value of HTML in this web stack for full stack developers.

Also in this layer comes much of ARIA: Accessible Rich Internet Applications, the additional stuff we can add to HTML to expand its vocabulary. With HTML being the language, ARIA allows us to expand that vocabulary when it's necessary. And that's an important point. And it isn't always stressed, I think, when we talk about ARIA and accessibility.

So I'll be talking about ARIA a little bit as we go through this. Because it is an important tool, a very valuable tool.

But we start with good HTML. It's important to understand the ARIA roles as we expand the vocabulary or change the role of things within HTML or what that HTML element does or is defined as being or doing to the end user, that we don't override those native HTML roles. We just have to be -- at least, if we do it, be careful with it. For instance 'input type of check box role of radio' doesn't make a lot of sense because functionally it would be a check box within the page but presented as a radio button to the end user, to a screen reader user, and that's going to be really problematic, especially if it still functions as a check box within the page. The interactions between checkboxes and radio buttons are very different.

And another example would be having a navigation -- a list of navigation links on your page. We can give a container for that list role of navigation that would now be defined as a navigation region that would facilitate navigation to that list of navigation items. However, if we added role of navigation to the list itself, say an unordered list, now the semantics of that list are gone. We have overridden that list. And now defined it as being a navigation region. So the benefits of having a list of items, a list of links, for instance, would then be lost. So we need to think about how we're implemented ARIA and understand that it overrides those native roles and sometimes those native roles might be useful or even necessary for accessibility.

Also we need to be cautious that the role names in the ARIA specification sometimes are not intuitive. So, we need to be really careful. For instance, menu, `role=menu`. Very often I see people say, "Well, oh, I've got a navigation menu a list of links here. That's a menu. We'll give that in `role=menu`. Yay, accessibility, we have improved accessibility!" And that typically is not the case. Because an ARIA menu or an application menu is not a navigation menu. It's not a list of links. The interaction is very different. It's more like software menus like file, edit and so forth, so we would interact with that type of menu very differently than we would a list of links. Tab panels are another one where sometimes you see a group of links that are visually presented within tabs. But each of those are distinct links that take you to a different page.

Very often, we will see ARIA tab panel markup defined for that list of links. And that actually is not a tab panel. And ARIA or application tab panel is very dynamic where clicking on an item would dynamically change the content within that tab panel as opposed to taking you to a separate page. Again, the interaction between links that look like tabs and the actual application tab panel are very different.

A third example is a data table. Giving a data table `role=grid` sometimes you might say, well, yeah, table is a grid of information we'll give it role of grid to improve accessibility. Well, an application grid or ARIA grid is more like a spreadsheet, interactive via the arrow keys, usually editable. And so giving just a data table with text content `role=grid` is probably going to destroy the accessibility of that data table.

So we need to be cautious with these. How do we know that we're implementing our ARIA correctly? Well, use the specification. Use the ARIA Authoring Practices.

As W3C specifications go, ARIA is pretty friendly. It's kind of human consumable, especially the Authoring Practices document, which is wonderful. It defines design patterns, has code examples, it outlines the keyboard interactions that are necessary, the proper ARIA to implement for different types of widgets and controls and things that we might want to build and enhance with ARIA.

So, following this Bible of ARIA implementation is so, so vital, especially the keyboard interactions. And that's important because ARIA does not change browser functionality. Because we're simply enhancing that vocabulary of HTML and the things that are presented to screen reader users, it doesn't actually change anything in the browser itself.

So if you implement ARIA, generally, you're going to need to test in a screen reader to ensure that it's been implemented correctly and especially those keyboard interactions. For non-standard widgets now this is all amazing, it's cool what you can build with ARIA, but it's so important that we build it all correctly and I'll come back to that point a little bit later.

Next in our web stack we have CSS, our Cascading Style Sheets, and this is where a lot of accessibility happens, too. The visual stuff all occurs in this layer: sufficient contrast and good visual design and light space and typography and all of these things that can really improve and enhance accessibility. Now, screen readers typically ignore CSS, but with some exceptions (there are a few others), but the big ones are `display=none`, `visibility=hidden', hide content from all users including screen reader users, after and before pseudo selectors those are things that can allow us to define content in our CSS that's visually within the page some browsers and screen readers will read that content and sometimes we just need to be careful with that and test it.

So, this is also sometimes a little bit of a pain point in accessibility mechanics because authors maybe don't know how to style or maybe they feel like they are limited the browsers and CSS spec and they don't really understand CSS. So, they try to do things in other ways and CSS is a very -- really, really powerful tool, but, it's also important that we understand the C in CSS: the cascading component of CSS. So, I have lots of layers in this presentation. This is another set of layers we would want to consider. At the very bottom, we have our browser default styles that define how things are going to look by default: paragraphs are going to be, whatever, twelve-pixel Times New Roman black on white. The user can define their own default styles that override those browser defaults. As an author you can define external or embedded styles to change what that paragraph looks like in your page. You can add inline styles that would override the external or embedded styles, to say, change this particular paragraph to make it look a little different.

And then about that, the author can define important styles and those are going to override the hierarchy of any other styles that are defined below in the lower layers. Say, this is most important and ensure that this style is applied.

And, at the very top, are user important styles, meaning they can override any other styles that are defined and that's really important for us to understand is that the user has two places in which their styles can be implemented. One is just above the browser defaults. And then at the very, very top of this stack, meaning that the user always wins. They have the power to override all of your CSS. And that's great for accessibility because they can define colors that are most optimal for them. They can enlarge page content and change font faces to maybe font faces that are best for them maybe because of dyslexia or a reading disability. Lots of things that they can override within the page.

We just need to understand this cascade and the user is always at the top of that stack. And interestingly, very near the bottom of that stack, as well. So they win. They can override most anything. We need to understand that. And really focus on maybe less on designing an end user experience. We need to give up the notion that we control what the user sees or experiences and focus more on enabling a good user experience. In other words, we provide a great default but if the user overrides or changes things within the page it's still going to work and be highly accessible.

And then our top layer within this web stack is scripting or behavior where we progressively enhance things, make things better, add functionality that's not possible via HTML. This is also very, very powerful for accessibility. We need to consider that we don't disrupt the keyboard navigation. Very often overlooked when it comes to dynamic content, single page applications and so forth, the keyboard interactions very often aren't really considered and tested. So do keyboard testing which is easy. Put your mouse away! Start to interact with the keyboard! We can use scripting to enhance that interactivity by setting focus so it programmatically follows visual focus for things like dialog boxes, error messages, and menus when they open, reset focus and when they go away or are dismissed, they set focus back to something else that's most logical within the page. Those types of things are excellent accessibility enhancements that can occur via behavior and scripting.

But we want to start with our HTML, add CSS to enhance that and make it look sexy, and scripting to make it smarter and more performance and enhance that behavior and make it even more accessible. Here is a pretty basic example of how some of this can be used at the bottom layer of HTML. We can define a button element, give it ARIA `pressed=false` so this is a toggle button to turn on or turn off filters. So, just standard HTML, We have this button and get ARIA `pressed=false`. ARIA pressed can be either true or false to indicate whether the button is pressed or activated at that point in time. We can define our default styles for that filter when the ARIA pressed attribute is set to false, in the square brackets there in our CSS allow us to define those styles in that particular state based on that ARIA attribute, as defined in our markup or as manipulated via scripting. We can also define our `pressed=true` styles. In this case, we change the border color and increase the width of that border style and then in our scripting, here is some basic JQuery where, when the button is clicked, we determine what it's current state is: is it pressed or not and then we toggle that state so it changes to the opposite value, true to false and false to true, so forth.

So, this is a great basic example of isolating and keeping these three layers very distinct and the power that we can use that we can take advantage of by defining our standard HTML, controlling states via scripting, and then letting CSS do what it does best, changing the visual appearance. Very often we change visual styles in our scripting and that kind of moves, that kind of morphs the scripting and CSS layers to the other. Sometimes we put our CSS in our HTML. Sometimes we define content in scripting or write content to the page. This just allows us to really isolate these. This is powerful for accessibility, for progressive enhancement, and ultimately for accessibility by trying to keep these isolated.

I saw something that was very, very similar to this example in a popular framework, just a little while ago. And to do this basic functionality of defining a button, clicking on it to change the visual styling and toggling the state, was over 100 lines of code. And there wasn't even ARIA in the line. It wasn't defining the ARIA pressed state, it was just defining the visual stuff, which is they didn't start with the button, they started with <div> elements and added stuff to it and just the concept of keeping the layers isolated is really powerful for development, optimized clean code and for accessibility.

So, I now want to introduce another stack. This is what I call the accessibility stack. At the bottom, we have the webpage itself, and that's really where those other three layers of that web stack come into play. They are all part of that webpage: our HTML, our CSS scripting are all put together to generate this webpage. Above that we have the browser that interprets that webpage content and above it we have assistive technology, screen readers, voice control things -- software in JAWS, NVDA, VoiceOver, Dragon, and so forth.

So I wanted to talk a little bit about this stack. But before I get into more detail. I want to talk a little bit about WCAG and some of the terminology that's used within web content accessibility guidelines particularly the term "label" and the term "name."

Now, in the guidelines we are required to provide an accessible name for elements within the page. The name defines what to call this thing, how it's essentially titled or labeled. And then we also have to have an accessible label. Now these terms sometimes get jumbled up. It can be a little confusing because of the way in which they are used within the guidelines.

So the "label", as defined by WCAG, is something that's presented visually, that visually defines or explains what something is. The "name" is what is presented to assistive technology. It's sometimes called an accessible name and it can be visually hidden. So I'm going to go through a few examples of this.

So, here's a text box that has an adjacent label text of First Name. Okay, we can use the <label> element to associate that text to First Name to the input itself so a screen reader, if they were to navigate to that text box, it would be defined as the First Name text box.

So we look at name and label. According to WCAG, the "label" is the visible text of first name. The name is also the text of first name. But that has been defined as being the accessible name because of the <label> element. So this is where it gets a little confusing, and the <label> element should not be confused for the WCAG label.

Now, in this case they happen to be the same thing, the same text. First name. But label is the visual text, the name or accessible name is the thing that's been defined to be read by the screen reader. In this case, it happens to be via the <label> element.

So you can see where the terminology can sometimes get a little confusing. Now, we can have name and label be different. An example would be a linked image where text on that image is "Next," but the alternative text for the image is "Continue." We now have a mismatch between the visible label. which in this case is "Next," and the accessible name, which in this case is defined to be the <alt> attribute of "Continue."

Now, the easiest way to probably avoid this would be to not use an image. If we were to just use a text button and style, it then we would ensure that the label, the visible text, and the accessible name are the same. Then in this case, we have a mismatch. In this could cause some issues for a screen reader user. For instance, the screen reader would read "Continue," but that user may see the word "Next" or maybe be told to find the word -- the "Next" button within the page.

For a voice control user, they would probably use the word "Next" to try to activate this button via their voice, but because the word "Next" is not actually programmatically within the page, that's not going to work. Only the word "Continue" is defined as the accessible name within this page so we want to avoid this. And WCAG 2.1 addresses this via a new success criterion titled, Label in Name" and that reads, "For user interface components with labels that include text or images of text, the name contains the text that is presented visually."

Okay, so really what this is saying is that the label, the visual text, needs to be part of what's read by a screen reader, part of that accessible name. And I think this is really useful for accessibility. I can think of some exceptions where this maybe doesn't make sense, but, for the most part, if you can see something visually on the page that should be part of what's read by a screen reader. This is especially important because we do need to consider that most screen reader users have some vision. Very often we think of screen reader users as only just being blind, they are only experiencing content audibly, but the majority of the time there actually is some vision. Some users with cognitive or learning disabilities may actually use -- may use a screen reader. Maybe because of a reading issue or even a language barrier, they may prefer to hear that content as opposed to read it visually. So this is a great success criterion it helps support better accessibility.

So that previous example of the "Next" and "Continue" buttons that would be a failure of this because the label, the visual text, was not included as part of the accessible name, in that case, the alternative text.

So there are ways in which browsers should determine how to name particular elements. So consider this markup here. Here we have this search text box. Adjacent to it, we have a search visible text of search. That text of search has been associated to the text box with the <label> element. Our input also has `aria-label="Search Terms"`, a `<placeholder>="Search WebAIM"` and a `<title>="Search articles and blog "`. So, here we actually have four pieces of text that are all associated to this particular text box. We have the label text, we have an ARIA label, we have placeholder, and we have title.

Well, what's the screen reader to do with this? Oops! I jumped ahead and gave away the answer a little bit. There's a way in which the browser is supposed to interpret these different types of associations to determine what it should be. In this case, the name for this is defined by -- via the ARIA label it would define this text box as being search terms. The ARIA label text because ARIA wins most of the time. Usually ARIA is at the top of that accessible name calculation. In other words, if we define an ARIA label or ARIA labeled by that typically will override any other thing that's been defined as being a label for that particular element.

So, there is a W3C specification. It's called the Accessible Name and Description Computation spec. This is something that's implemented within the browsers to determine, "What do you call this thing? What is its name?" And it helps define what types of things we can define and which wins if multiple labels or names have been defined. It's a little confusing. We don't need to worry too much about the actual specification. We just have to know that the browser is going to figure out what to call this thing, what its name is, and how it does that is defined. It's defined in the specification and there's a hierarchy and logic to that.

So, we do need to consider, however, that when we tried to define labels or descriptions for things, that we need to understand the rules and how that's going to work, so we can ensure that what is read by a screen reader is appropriate.

So, first of all to define a label or description for something, it has to be labelable. That element has to be able to have a label. So links and form controls, tables and so forth, those are labelable elements. We can associate text to them and have it be read as that accessible name.

Things like divs, spans, paragraphs, are not labelable. So, for instance, if we gave ARIA label or ARIA labeled by to a <div> or <span> or <p> (paragraph), it should be ignored, it shouldn't be read at all because that element is not labelable. We can however make that thing labelable by giving it an appropriate ARIA role. For instance, a <div> we can give it `role=region` because that <div> is defined as a region or landmark within the page, it's now labelable, we can give it `<aria-label=filters>` to define a filters region within a single page application.

Those associated labels and descriptions are also strings when they are read as that accessible name or description. So, that's supposed to say, "read as a stream of text," that's what happens when I edit slides at the last minute, so the read as a stream of text when it comes as a text box as ARIA labeled by the content within that ARIA labeled by element is simply read as a stream of text. That means it's difficult to explore and navigate. If you hear a word in that label or description that's unfamiliar, it's hard to pause your screen reader and really explore that. Because it's really a separate element that's just being injected as a string into that accessible name field that's read by the screen reader. It's also devoid of semantics so for instance we have headings or links or lists within that separate element that's a label or description, that's going to be removed. It's going to be stripped out when it's read as that associated label or description.

So we need to keep those things in mind. A lot of what this means is that labels and descriptions should be short, succinct, really to the point, and appropriately labeled or describe that element.

We also have to consider that ARIA labels and descriptions will be read even if they are styled with `display:none` or `aria-hidden`. Now, I mentioned before screen readers generally will recognize `display:none` and `aria-hidden`, but if something is a label or description, and it's hidden with `display:none` or `aria-hidden` or other CSS, it will still be read. A common example of this might be form error messages where we may have a piece of text below a form field that indicates that there's an error for that particular field and we associate that error message with `aria-describedby' to the field itself.

In the default state of that form, those error messages will be hidden but it's not in an error state. If they are hidden with `display:none` even though they are hidden with `display:none` they would still likley be read by a screen reader because their description is defined as being a description of that field. So, it's another one of those rules that often results in a screen reader experience being rather different from the visual experience.

Okay, so let's take a lot of this and start to pull it together and find out ways we can start to test and analyze and take advantage of a lot of these different layers or stacks. So, again putting this together a webpage stack from everything that we put together to build our page with our browser on top of that and assistive technology on top of that, we have what's called the Accessibility Tree. The Accessibility Tree is something that is generated by the browser based on the page content or more specifically, the DOM, the Document Object Model, of the rendered webpage. This is really powerful. In the old days, a long time ago, we didn't have this accessibility tree. Essentially what happened, is the browser just kind of read your code and would generate stuff that it would send to the assistive technology. That meant if we were to manipulate the page with scripting, the browser usually wouldn't get those updates. And thus -- I mean at least it wouldn't send those updates to the assistive technology unless we forced it to or told it to, and it was really quirky. But now if we update the webpage dynamically with scripting, that will update the Accessibility Tree which is then used to convey information to the assistive technology.

We can analyze that Accessibility Tree using just tools within our standard browser. So I'm going to show this real quick. I'm going to do this with Chrome but Chrome has something called the Accessibility Internals so Chrome:\\accessibility. Now, the very term there of internals suggests that this is kind of icky, maybe something that you don't want to dive into that much. But it is kind of interesting that you can access this kind of internals page you can enable some of the -- the options or modes I've turned on Web site accessibility, and screen reader support and accessibility and that's probably -- I need to make it bigger it's small we have a page opened here the WebAIM page and I'll go to Show Accessibility Tree.

This is what you get. This is the internal accessibility tree for the WebAIM.org homepage. Yikes. Yeah, it's -- this is the internal stuff. This is not very good. But you can maybe see here that there is a hierarchy or structure to this. We can start to explore this and find individual elements within our page. For instance, here is a heading and it has a title of WebAIM web accessibility in minder. And within that heading is a link and within it is an image and we can find the alternative text for that image. There's a lot of these attributes. This is not a very good or friendly way to explore the Accessibility Tree. But it is a possibility to really dive right into exactly what is being generated and defined in that Accessibility Tree via the browser.

A better way to do this is probably via the developer tools. So I'm just going to inspect an element here. And pull over the developer tools window. And we have an option here for accessibility. And then within this accessibility panel, it's going to show us the Accessibility Tree.

So, here we can start to explore the structure not just of the DOM or code of the page but what's being generated into the Accessibility Tree, the things that are going to be presented to a screen reader for accessibility.

So I inspected this link. This link is within a heading. We can see in the ARIA attributes that may be defined for that, and then the computed properties these are the things that are defined by that accessible name and description calculation.

In this case, the name is accessibility training. That's what this link will be read as: the accessibility training link. And it has a `role` of link. That ensures that this is going to probably be accessible. It's a link. It has the name of accessibility training and we can see how that accessible name is being calculated is it being defined by ARIA labeled by ARIA label in this case it's being defined by the contents or text within that link. If it had a title attribute that would also be here but it would be overridden by the content of that particular link.

So if you're not quite sure what would be maybe presented by a screen reader, especially if you have text and ARIA labels and titles and maybe placeholder and things like that, you can use the accessibility panel to go in and expect that and determine what the actual accessible name is and ensure that the accessibility role is correct.

So this can be helpful. This can be really useful tool in kind of debugging and testing accessibility. Generally, it's only necessary if you're doing things like ARIA or dynamic content updates.

So a little bit more about the Accessibility Tree or how your browser interprets your webpage for accessibility. If we just have a standard button, it will be defined with a role of <button> and in this case a name of subscribe. That's the text contents within that button. Pretty straightforward.

This is also why we don't need to or would want to add `role=button` to this element. It already has a role of button. Gving it `role=button` with ARIA doesn't do anything useful, it just introduces a potential point for breakage for something to be broken up the road. Maybe we change this button to some other element but don't change role of button, now we can have an accessibility issue.

If we have a link in this case it's -- this has a role of link and a name of "Register now," with "Register now" being the text within that.

However, if we were to give this link role equals button, it now has a `role=button" and a name of register now. So for a screen reader user this would be defined as the "Register now" button.

But we have a potential issue here. Because we maybe haven't considered the keyboard interaction for this element. Because it is defined as being a button to the screen reader user, the keyboard interactions for buttons can be a little bit different than the keyboard interactions for links. Links are activated via the enter key, buttons are activated via the enter key or the space bar and, in screen readers the screen reader generally indicates to the user that they should use the space bar to activate. The screen reader in this case might read, "Register now button, press space to activate." If the user presses the space bar when this link has focused, it actually will not activate by default because it is a link, it's not a button. It's only defined as a button to the screen reader because we added the ARIA role.

So we could address this by then doing key event detection, meaning has the user hit the space bar. We have to use scripting to do that. And then activate this thing.

Don't do this. Just use the proper element. If it's a link, use the <a> element make it a link, if it's a button use the actual <button> element without trying to manipulate this via ARIA. We can do all of this via HTML therefore we -- well, we should. The spec would probably say must but usually we -- you know, we can do all of this, rules of HTML are meant to be broken in some ways, use the proper elements.

By the way I do see the comments coming in, I can't really jump to the comments. I'll get to those at the end. I promise I'll answer your questions.

So this is just where -- I don't know. This is just a pain point in ARIA implementation if we add roles or add ARIA without ensuring proper keyboard interactions.

This is something else we see quite often. Here we have a link, the same link, our "Register now" link, but it's been given an `aria-label="Opens in new window". In this case the `role` is link but the accessible name is "Opens in new window." Because the `aria-label` overrides the default name or text of this link, which is "Register now," this would be read by a screen reader as "Opens in new window link." The text of "Register now," which is really the important stuff, is lost. In fact, it's gone. It's inaccessible to a screen reader.

Why? Because you told it to. The code, by adding `aria-label, we have told it that the name for this link is not "Register now" but it is "Opens in new window". So this would also be one of those new WCAG 2.1 name failures because what's visibly shown, the text "Register now", the label is not shown as accessible or not included within the accessible link.

Okay. Another thing that's really kind of interesting is something called the Accessibility Object Model or AOM. This is something new that's been introduced. It's starting to be implemented into browsers. But it allows us to script or manipulate or change things at the Accessibility Rree level as opposed to only within the DOM itself. So, typically, if we want to use scripting to set an attribute for an element, we could define what that button is by its ID. Use `setAttribute` to change `aria-pressed` to true, for instance.

Using the Accessibility Object Model, we can instead set the ARIA attribute directly within the Accessibility Tree as opposed to in the DOM. Now, this is under construction. It's new, it's not supported by older browsers, but it is kind of interesting, because typically what happens is if we make changes in the DOM, that needs to be kind of reprocessed by the browser to generate an updated Accessibility Tree with those accessibility changes. With the Accessibility Object Model, we can make those changes directly at the Tree level.

Now, why would we want to do this? There are a few cases. For instance, things like web components, things with a shadow DOM where we aren't really -- we don't really want to make those changes directly in the DOM but it might make sense to enhance accessibility via scripting for that particular element directly within the Accessibility Tree. This can also be useful for inspecting accessibility or testing it. For instance, checking whether a particular role or attribute is valid for an element or supported. Does the browser actually add this particular role or attribute correctly in the Accessibility Tree? We can also, again, just directly manipulate that Accessibility Tree.

So there's I think a lot of potential for this up the road from the future when this is better supported. Also a little bit scary to me. Because we can change things, we can really break accessibility and make it kind of difficult to detect that, because it's not directly within the DOM of the page. It's more in those icky internals within the browser that can be a little bit more difficult for us to test and analyze.

A lot of what this is going to require is better screen reader testing, better assistive technology testing to make sure that things are actually working the way that they are supposed to.

Okay. There's another little interaction I want to talk about briefly and that's accessibility APIs. The accessibility APIs are how the browser communicates all of this accessibility information to the assistive technology itself such as screen readers so every operating system has its own API or multiple APIs, in some cases, which are just the specification that's defined as to how these things are going to be communicated between the software and the assistive technology via that operating system.

So those APIs are going to define channels, things like role, what is this thing, what does it do, name, how do we title or tell you what this thing is, description, properties, whether a check box is checked or unchecked or required and so forth. Those can all be defined via these API channels. And those values are going to be determined from the Accessibility Tree that's generated in the browser from the content and DOM of our page.

You can also use tools to inspect the accessibility API channels. Meaning we can actually see what is being communicated from the browser directly to the assistive technology.

So on a Mac, you can do that with Accessibility Inspector and in Xcode on Windows, there's the accessibility viewer from my friends at TPG, a great tool to kind of tap right into those communication channels to see if -- what's being communicated. So this can be really useful especially for debugging where things have broke.

So, sometimes as a developer, you build something, you build say an ARIA widget and it doesn't work correctly in the screen reader. And you have to figure out, "Did I do something wrong. Is the browser not supporting this or is it the screen reader?"

So you can look at these different layers, these different points of where accessibility happens to try to determine where that's at and we can look at the ARIA specification and determine whether we have used incorrect code or ARIA. If that's the case, we need to fix it. We can inspect the Accessibility Tree. If those things are not being defined correctly, maybe the browser is not properly implementing the accessible name computation, then we would need to file a browser bug so it's interpreting our code or DOM correctly into the Accessibility Tree.

We can also inspect the API channel. Is the browser communicating the proper stuff to the screen reader? If it's not, file a browser bug. And if it is, and it's still being read incorrectly by the screen reader, then file the screen reader bug, that's probably where the issue is occurring.

Now, most of the time it's the browser's fault, at least, if you have implemented your code correctly and it's not being read properly by the screen reader, usually that's because the browser is doing something quirky. So, just remember that. Screen readers usually read what the browser presents. So very often, we curse at the screen reader saying, "Oh, it doesn't support this!" But usually it's the browser's fault. We now have tools to determine that. We can analyze all of these layers to determine where the breakdown has occurred.

Okay, so that's a lot that all comes together. Now, this is important I think for modern accessibility. It didn't used to be. We didn't used to have to think about all of these things, we just had to write proper code and it would work. The more and more especially with ARIA, especially with complex applications, we need to think about these layers and interactions more and do more and more debugging.

Now there is one last critical layer most important of all at the very top of that and that's the user. That's what this is all about, is ensuring a proper end user experience. Good accessibility for our users. But we need to understand these layers to ensure that proper accessibility.

Okay. With that, I will say thank you and I'm going to pull up a quick slide here just with some credits and I will go to answering your questions.

There was a comment here that it says it doesn't help that Google's design calls their style of menu links, tabs. Designers can't see the difference when frameworks name things like that. Yeah I think the comment is, you know, we get these weird interaction -- weird interplay between what we see, tabs, and they are called tabs but -- tabs and they are called tabs but they are not actual application tabs or we call things a menu, maybe a mega menu, it's not the same as an application menu. Yeah, that's a lot of where we run into these difficulties in implementing ARIA because it looks like one thing but what it looks like may not actually align with the ARIA specification, with the actual design pattern.

Okay. The next question was wonder if inline JS injected important styles to an override user via user style sheet important styles.

Okay. So I think the question there was whether -- yeah, if you define styles via scripting, whether those would override the user -- end user style sheet. No. They shouldn't. They shouldn't at all. The end user should ultimately have control over those styles.

There's comment that those injected style sheets may -- can be interpreted as user important styles so maybe that isn't the case. There may be -- there may be places where those injected styles may cause issues. Good. I don't know the answer to that. That's a good point, good question. I'll have to do some testing.

Okay. Steve in the chat pointed the -- pointed out the link to Accessible Name and Description Computation. Great. It's not terrible lengthy specification. It is really helpful to maybe look through that. If you're not sure what is going to take priority as you define things with ARIA like ARIA label, ARIA labeled by ARIA description can be useful to help define that. Good.

Okay. Sarah asks are hardware accessibility issues such as having to use mouse and can't use keyboard in the accessibility API?

You might provide a little clarification, if I'm answering the wrong question here. Not -- not really. I mean, the accessibility API what's communicated from the browser to assistive technology is going to be pretty agnostic of the technology itself.

So, for instance, if you're using a screen reader, the browser doesn't know if you're using that screen reader with a mouse or only with a keyboard. It's just presenting the accessibility information. It would be up to that assistive technology itself to know how to -- to create that interaction for you. For that particular element. And it's interesting when it comes to screen readers because some interactions that happen with a webpage occur at the screen reader level and some occur at the browser level. Typing into a text box is you manipulating or typing directly into the browser. You hitting the H key or command-option-H on a Mac to navigate by headings is going to be handled by the assistive technology, which changes the interaction within the page.

So most of that -- yeah, most of that interaction stuff, the hardware level, you know, mouse, keyboard, is going to be independent of those accessibility APIs. Hopefully that's answering the right question there.

>> KARL GROVES: And Jared that's kind of something I see a lot people misunderstanding when I do training and stuff which is that once the assistive technology is enabled, the assistive technology then sort of takes over that decision of whether -- what it's going to do with those keys when you hit them based on the interaction mode that has been enabled at that time.

So you know, if you're in browse mode versus interaction or forms mode, stuff like that, is the assistive technology sort of trips you up there. And as a matter of fact sometimes when people are doing testing, especially with JAWS, I've seen JAWS do things like fire a click event on something that didn't have a click event on it because it's like, okay, we know what they are trying to do here and so we're going to just take over.

>> JARED SMITH: Yeah. If we go back to that accessibility stack, that assistive technology was above the browser.

>> KARL GROVES: Yeah.

>> JARED SMITH: And that's again where that user interaction flows through that assistive technology. And yeah that can be a barrier. And I would point out especially on Windows. On a Mac, there's a different keyboard interaction between the user and the browser itself. The screen reader keys always -- almost always I should say occur via a key combination. Control option and some key to cause the screen reader to trigger, say, heading navigation or region navigation. On Windows, it can toggle between these different modes meaning is the screen reader handling the keys or is the browser handling the keyboard key interactions and it can toggle between those modes.

So, it gets a little complex. I think the biggest takeaway there is if you are a developer on a Mac testing only on a Mac and are implementing certain ARIA roles, be cautious. Follow the ARIA design patterns and you're probably going to need to test on Windows with a Windows screen reader to ensure that the keyboard interactions are happening correctly.

>> KARL GROVES: Yeah. Well, all right, if there's no other questions, and I'll babble a little bit so people can plop in some questions, if they want, I just want to say thank you for this. I think this is going to be the kind of thing that we're going to highlight a lot when people come to us to ask us questions about stuff is just hey look at this awesome webinar that we had with Jared Smith.

Now, next month our guest is going to be Adam Spencer. Adam Spencer is my personal PDF guru. If I have PDF questions, that's who I send them to. And he's going to be talking to us about PDF accessibility.

And so that will be -- Michael, what day is that?

>> MICHAEL BECK: That would be on Wednesday, February 6th at 11 a.m.

>> KARL GROVES: All right. Wednesday, February 6th. Adam Spencer. That one is also going to get streamed onto Facebook. We have found a way to shoot Zoom over to Facebook to stream your videos to that, as well.

And as Michael said in the comments section or in the chat section, once we get this thing downloaded and archived and edited and transcribed and all of that good stuff, we will be posting this on YouTube and on the Technica11y.org Web site. And thank you, all, very much for attending and I hope to see you next month.

Back to the main page