Learning Goals

  • Review ways we already make websites accessible
  • Be able to use the three different types of ARIA attributes
  • Determine when ARIA is and is not needed to make websites more accessible


  • Accessibility Broadly, creating an experience that is available to anyone and everyone
  • ARIA Accessible Rich Internet Applications
  • Role The function an element serves on the page
  • State The state of an element on a page (e.g., expanded, disabled)
  • Property Additional information about an element or other elements its related to

Warm Up

Let’s review from last week’s Intro to Accessibility Lesson

In groups, add some stickies to this Jamboard

  • What have you already been implementing (or would like to implement) to make your applications accessible?
  • What are some ways we can test how accessible an application is?

Accessible Defaults

Semantic HTML

There are two different elements that are semantically neutral: Those are span and div elements. Avoid using them except in instances that are purely for styling.

Semantic html is very important for 3 reasons:

  1. developer empathy - It makes code much easier to read and debug
  2. accessibility - It allows screen readers to move through the web page seamlessly
  3. SEO (search engine optimization) - it will make your webpage more discoverable via Google

Side Note: Documentation is your friend when developing a website. Here are some super useful docs for better knowing what element to use for a given scenario.


Browser Focus Rings

DO NOT REMOVE THE FOCUS RING that appears on interactive elements without providing alternative styling or accounting for users who depend on the keyboard as their primary way of navigation.

This blog post on writing accessible css has a section that digs into why you shouldn’t remove it (as well as some alternatives to take).This website offers a list of alternative styling options. And this article also has some alternatives to use to get rid of the focus ring while still keeping things accessible.

A design-friendly example of some alternative outline styles.


WAI-ARIA is a shorthand for (Web Accessibility Initiative – Accessible Rich Internet Applications). WAI-ARIA is a specification written by the W3C, defining a set of additional HTML attributes that can be applied to elements to provide additional semantics and improve accessibility wherever it is lacking. ARIA breaks down into 3 categories:

  • 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 screenreaders 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.

These are attributes that are “hidden” in your HTML for screen readers to see. Think of other attributes you might put on an HTML element that don’t show up on the page:

  • disabled
  • alt
  • lang

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 behavior 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.

Aria Roles, States, and Properties


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" -->

<!-- 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.

Table of elements and their implicit roles

In Groups

  • Use the table of elements and look up the following elements and their implicit roles
    • div
    • footer
    • input
  • Check out some of the other elements. Is there anything suprising?
  • Take turns explaining what a role is.
  • What is the difference between implicit and explicit roles?


States describe how you are interacting with an element (What am I doing right now?)

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

  Toggle Menu

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 have fully functional eyesight, but probably not great if you use assistive technology.

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

  Toggle Menu
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.

In Groups

  • Checkout this Menu-Example with VoiceOver to see how screen readers interact with aria-expanded
  • Take turns explaining what states are.
  • What would be another example of state that your app might need?


Properties give an element special characteristics that you can relate to other documents or elements.

For example, take the button we mentioned when discussing states. That button specifically controlled the sidebar-menu, but what if there are multiple menus that have similar buttons? ARIA lets us add additional properties that link elements together.

    Toggle Menu

<nav id="sidebar-menu">
  <!-- ...nav code here... -->

The aria-controls property has a value of the ID of the element it is attached to. So in this case, we would assume that there is another element with an id of sidebar-menu that is contolled by this button.

You can also use something called an aria-label property. Think of this like an alt tag for accessibility - this property allows you to enter additional text that provides more information to the user. This information won’t show up on the page but will be read by the screen reader.

  aria-label="Close sidebar navigation menu"
    Toggle Menu

You can then use JavaScript to keep this information up to date - for example, once aria-expanded="false", you’d set your aria-label to "Open sidebar navigation menu".

NOTE: Use aria-label with caution. The screen reader will now REPLACE whatever exists as the default button text and instead read the aria-label content.

Other Properties

  • aria-label - Described above. Provides additional information about an element.
  • aria-required - Tells a user if they need to provide input on an element before a form is submitted.
  • aria-controls - Seen above. References an element that is controlled by the current element.
  • aria-labelledby - Sister to aria-label, references the ID of another element, which is a short title for the element.
  • aria-describedby - is just like aria-labelledby – but is meant for longer descriptions instead of short titles. This is read after the field-type is stated

In Groups

  • While using VoiceOver, compare this Codepen and compare it with this Codepen. What changes to do you notice?
  • Take turns explaining what a property is
  • Come up with a good analogy for property
  • How are properties different from state?

Accessibility in Practice Moving forward

  • Most of the above mentioned aria attributes should be used sparingly.
  • The time to use them is if the answer to the following question is yes:
    • Will sighted users see content that people with visual disabilities cannot?

Below are some things that you should ALWAYS incorporate in your web applications

Alt Attributes for Your Images!

  • Hugely important (for both accessibility and SEO!)
  • Low hanging fruit, easy to use on images.
  • Be verbose.
  • Just do it.
<img src="mountain.jpg" alt="mountain">

<img src="mountain.jpg" alt="The cascade mountains at sunset in January">
  • Wait, what if there is already descriptive text below my image??
    • This is one of the only times were you DONT need to supply alt text. Having both would be repetive and redundant for screen reader users. To still be “valid”, include an empty alt tag like this <h3>A round, sleepy cat napping on a bed.</h3><img src="src/cat-pic.jpg" alt="">
  • What about background images??
    • Background images are purely for design, and should not be used to display important web content. Because of this, background images do not need alt text.

Great example of alt tag

  • Not necessary for all links, but make sure to use them for your icon anchors – you know, things like your facebook, twitter, etc icons:
<a class="facebook-icon" aria-label="Link to Facebook"><a/>

Lang attribute on Your HTML!

  • Is often populated by default if using Emment or other HTML boilerplates!
  • As far as non-english speaking screen readers are concerned, when they land on an english-speaking web page without the lang attribute, it will be spoken with the screen reader language - making it impossible to understand - unless the screen reader user disables language switching in the screen reader.
<html lang="en">
  • Fun Fact - You can change this if you have a snippet of text in another language!
<h1 lang="es">¿Donde está la biblioteca?</h1>

Label Input Elements

Note: you should really be providing labels with all of your input fields, like this!

<label for="firstName">First name</label>
<input id="firstName" type="text" placeholder="Clementine">

You can use the aria-label below to define a label, but remember to use semantic, native elements whenever possible.

<input type="text" aria-label="First name" placeholder="Clementine">

Additional Resources



Lesson Search Results

Showing top 10 results