Intro to Accessibility

Learning Goals

• Define accessibility and explain why it’s important to us as developers
• Identify different user groups we should be developing for
• Gain some insight into how others might interact with the web that’s different than the way we do
• Be able to use the three different types of ARIA attributes
• Determine when ARIA is and is not needed to make websites more accessible

Vocab

• Accessibility Broadly, creating an experience that is available to anyone and everyone
• VoiceOver A screen reader that is built into apple computers
• ARIA Accessible Rich Internet Applications
• Role The function an element serves on the page. “What is this element?”
• State The state of an element on a page (e.g., expanded, disabled). “What is the status of this element?” (Boolean, changes and must be updated/kept current with JS as application is used)
• Property Additional information about an element or other elements its related to. “What other info is important about this element?”

What is accessibility?

Accessibility on the web is all about creating a user experience that is available to anyone and everyone. We want to enable as many people as possible to use our applications, even when those users may be limited in some way.

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Unfortunately, developers often use the tools we’re given in the wrong ways, unknowingly (or uncaringly) effecting the accessibility of their site in a negative way.

A quick example: not using semantic HTML tags. If you were to use a div instead of an article to wrap text for a news article, that means infinitely less to someone relying on a screen reader.

But for some reason we do it anyway!! So the good few souls out there that are really pushing for accessibility have even added additional attributes and APIs you can use to allow you to write your code the way you want, and still make it accessible.

e.g. if you really wanted to use your div tag instead of an article tag, you could do something like <div role="article"> and this would provide that same accessibility feedback as if you had used an article tag.

So we have all the tools to make our applications very accessible. While we won’t learn about all of them just yet, we will learn about what types of accessibility concerns actually exist, and gain some understanding of how others might be interacting with the web.

Types of Accessibility Concerns

Station One

Station Two

Station Three

Station Four

WAI-ARIA

Web Accessibility Initiative - Accessible Rich Internet Applications.

WAI-ARIA is a set of attributes we can add to our HTML tags to make our code more semantically meaningful for screen readers.

Think about the information provided by a set of <div></div> tags. What do we know about the content within those tags? Really, we know nothing. It’s a semantically void element that controls the APPEARANCE of its content - by default it is a block style element, but beyond that it could theoretically be literally any kind of data - a title, a paragraph, an image, a random red decorative sidebar…etc.

ARIA provides a series of tools and approaches to enhancing the meaning of your code. Today we will look at the three main aspects of ARIA - Roles, States, and Properties.

• Roles
• States
• Properties

An element can only have one role at a time, but can have as many properties and states as necessary

An important point about WAI-ARIA attributes is that they don’t affect the appearance or functionality of a web page, except for the information exposed by the browser’s accessibility APIs (where screen readers get their information from). WAI-ARIA doesn’t affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.

Rules of ARIA Use

The core rules to keep in mind when using ARIA are:

If you can use native HTML elements and attributes to communicate the proper semantics (like <header>, <nav>, <main>, <footer>, <button> etc.) and then do so. Adding ARIA support where it’s not needed is redundant code that isn’t doing anything. For the most part it won’t lead to problems, but it is a waste of time, and will annoy your screen reader users.

Many “accessibility flags” come from developers overusing ARIA. Only use ARIA as a last resort!!

Aria Roles, States, and Properties

Roles

Roles define what an element is - what function it serves on the page. They give screen readers more information about how to interact with the element (What am I?)

These can be either implicit or explicit.

Implicit roles are those that are pre-defined by default in HTML. Ie: <h1></h1>, <button></button>, <ul></ul>. The semantic meanings of these elements are already clear by the element themselves and assistive technologies have this information too.

If you are writing good semantic HTML, the role will likely be implicit. Remember you can always check the role here

Implicit Role Example:

<h1>Hello World</h1>
<!-- The above markup has an implicit role of "heading level 1" -->

<nav></nav>
<!-- The above markup has an implicit role of "navigation" -->

Explicit Role Example:

<form role='search'></form>
A form element has a role of 'form' by default. We can override that role using the `role` attribute and providing it another value. Like in the case above where we are using the role of search.

States

States describe how you are interacting with an element (What am I doing right now?) and rely on boolean logic.

For example, think about websites that have a sidebar menu that can be toggled open or closed. You might see something like this:

<button>
  Toggle Menu
</button>

Here we have a button with text that says “Toggle Menu”, probably indicating that when you click on said button it will toggle the menu open or closed.

What this doesn’t tell you is if the menu is already open or closed, which is fine if you are a sighted user, but probably not great if you use assistive technology.

Luckily ARIA provides state information that we can add to our markup.

<button
  id="menu-button"
  aria-expanded="true"
>
  Toggle Menu
</button>

let button = document.getElementById("menu-button");

button.addEventListener("click", function() {
  let attr = button.getAttribute("aria-expanded");

  if (attr === 'true') {
     button.setAttribute("aria-expanded", false);
  } else {
     button.setAttribute("aria-expanded", true);
  }
});

This also allows you to target these elements using the aria-expanded attribute when interacting with them in your JavaScript or CSS.

States can also be implicit, imagine a checkbox element in html. If you toggle the checked property that state will change as well.