There are amultiple layers of accessibility technology. This video gives a super broad overview on what they are and how they interact.

Transcript

Hello! Making the web accessible is not dependent on one single technology or approach. It depends on layers of different technologies that all need to work together to make a website accessible.

Today, I’ll show what the most important technologies are, and how they work together.

I’m Eric Eggert, a Web Accessibility Expert. You can follow me as @yatil — Y-A-T-I-L — on social media. If you have questions about this or other videos, or want to propose a topic use the hashtag #askYatil on Twitter or ask in the comments.

Just a quick note: Transcripts for all videos are now available on my website at yatil.net/videos.

OK,let’s talk about the layers of technology that enables users to read websites:

1. The Web Browser

   Web Browsers take content that is on the web and convey it to the operating system and the user. It combines information from different web technologies and forms a current state of the page that then gets handled to the operating system in different representations. One of those representations might be the image that is displayed on the screen, another representation is the website as abstract metadata.

2. The Operating System

   Different operating systems have different ways to reveal accessibility information. They have different ways for the UI to be controlled by a mouse but also using the keyboard. That’s why screen readers on different operating systems work differently.

   The operating system takes the image and displays it on the screen but also makes sure that the metadata that the browser gives to the operating system is usable for assistive technologies.

3. Assistive Technology (AT)

   Screen readers and other assistive technologies like voice input, take the metadata that the operating system gives them and convey it to their users in a way that makes sense for those users.

   Note that the assistive technologies can decide to use or not use some of that metadata, or use it only in specific situations. This allows every screen reader to just display a list of links on a page. All other metadata is not relevant to that task.

   In a similar vein, when reading a text on a page, the screen reader will not inform the user when individual words are emphasized, however certain modes are available to users that are more verbose and can announce that information as well.

So, that is how Web Browser, Operating System and Assistive Technologies (AT) work together. It is important to keep that fairly clear separation of concerns in mind when we think about web accessibility technologies.

There are the three basic web technologies: HTML, CSS and JavaScript – you heard it all.

• HTML, the Hypertext Markup Language, foundation of all content on the web. Its purpose is to structure data and content and enrich it with information. This is one of the primary sources for the metadata that browsers convey to the operating systems.

• CSS, Cascading Style Sheets, is mostly responsible for the visual appearance of the web page. But it can also have an impact on the metadata that is conveyed to the operating system: If content that is available in HTML is hidden, for example by using display: none, the browser will convey that in its metadata and assistive technology will not use that content.

• JavaScript can dynamically change content on the website and thus alter the metadata that needs to be conveyed. The script can also alter where the user is on the page, which also needs to be reflected.

But those three technologies are not the only ones that play a role in the transition from source code to output. And while I won’t go into detail in this video (And you know what’s coming now!) Please subscribe to my channel and click the notification bell to get alerted when I do.

“Accessible Rich Internet Applications”, short WAI-ARIA or just simply ARIA started to play a much more important role in the last couple of years as the web got more complex. To understand its name, it is necessary to look back a couple of years, towards the beginning of HTML5¹ . When the Web became more interactive, HTML lacked the ability to describe properly what was coded.

On the other hand, Operating Systems, specifically Windows, had a way for its applications to define more clearly what was going on so that those user interfaces could be translated properly to assistive technologies.

WAI-ARIA 1.1 defines the vocabulary that can be used by assistive technologies. It defines roles, states and properties and how they are used by assistive technologies.

To make it easy to use, ARIA has been mapped to HTML, which means that HTML elements have specific roles that are used in the metadata for that element when conveyed to the operating system.

In addition to using “native”, built-in, HTML elements and the vocabulary defined for them, ARIA can be used to change roles, states and properties directly in HTML.

There are more roles, states and properties defined in ARIA than there are available in HTML, especially for more complex operating system-like functionality. Meanwhile, some HTML elements have no equivalent ARIA role.

It’s all kind of messy, especially if you consider that the pure existence in ARIA doesn’t mean that the feature is available in operating systems or fully supported by assistive technologies. In particular, ARIA is often only understood by screen readers, but other technology, for example high contrast mode, might ignore it.

The ability to use ARIA in the HTML directly means that we have a good way to be very specific in the metadata that we offer to assistive technologies. But it also means that errors have a direct impact on users.

There are many problems when using ARIA, especially when using it in unintended ways, or when developers misunderstand how different features are used. I hope to do a video about common ARIA errors soon.

For the big picture, an <h1> element with the content “Hello World” is translated (through the HTML Accessibility API Mappings) as having the role heading and the aria-level 1. In this case, the HTML can act as a shortcut for the ARIA vocabulary.

But there are also ARIA features that are not available in HTML. For example live regions are special containers that allow developers to output specific messages right to assistive technologies.

While there is this close relationship between HTML, ARIA and assistive technologies, the use of ARIA is often only needed in limited ways and many of its fundamental features are already reflected in HTML.

I hope that we get more features that are ARIA-exclusive in HTML soon. If you had to resort to ARIA recently, comment with the feature you’d like to see adopted in HTML.

One category of ARIA functionality that I have not mentioned yet are the widgets which are defined in the WAI-ARIA Authoring Practices specification. These are design patterns on how to implement a widget when you want or must do it with ARIA.

They usually describe interaction that you would see in native application. Some of them are complex and have no specific HTML equivalent, for example modal dialogs or carousels.

Others are simple and you can easily replace them with standard HTML elements. For example, ARIA Authoring Practices shows how to make a button with ARIA, including the necessary JavaScript to make it accessible.

Just remember that the HTML <button> element brings with it all the functionality, no JavaScript required to make it accessible in the first place. It just is accessible.

ARIA should always be used as a precise way to make changes in limited circumstances. The aim should always be to use as much HTML and as little ARIA as possible.

To summarize: The browser loads the website from the server, extracts the metadata from HTML and sees how CSS and JavaScript alter it. It then sends that metadata to the assistive technology, which then decides what pieces of information are relevant to the user at this moment. When JavaScript changes the website, the browser updates the metadata and assistive technology picks these changes up accordingly.

Stay tuned to learn more about web accessibility on my channel. Make sure to click subscribe and hit the notification bell icon to not miss anything. And of course you can support me on Patreon at patreon.com/yatil or follow me at twitter.com/yatil — that's Y-A-T-I-L — where you can send me questions using the #askYatil hashtag.

Thanks for watching and see you in the next video.