- Accessibility - Making an experience that’s usable by anyone
- ARIA - Accessibile rich interneet applications
- Role - The function an element serves on the page
- State - Information about how an element is currently represented
- Property - Additional information about an element
- Understand how semantics are interpretted
- Learn about ARIA
- Understand how to test applications for accessibility
We talk a lot about writing semantic HTML, but what does that mean besides using
articles? Let’s take a deeper dive into how semantics are interpretted by assistive technology, and how to make the most informed decisions when developing accessible applications.
The Accessibilty Tree
When the browser loads content, it creates the DOM tree. We can use scripting to interact with what’s being displayed through the tree. By leveraging Accessibility APIs, the browser also creates what’s know as the Accessibilty Tree. This loads information that’s available to assistive technologies, such as screen readers and screen magnifiers.
Writing clean, semantic HTML communicates information about the web page to the assistive technologies, but things can get tricky when creating custom widgets or more complex applications. Using a
div to create a dropdown menu widget doesn’t explain how a sightless user is meant to interact with it. This is where ARIA comes in.
Accessibile Rich Internet Applications
ARIA is a set of rules and standards developed by W3C to make web applications more accessible. By utilitizing various ARIA attributes in your markup, you can send more meaningful information to the Accessibility Tree, allowing assisted users a more complete experience with your applications. It also allows the accessibilty tree to be updated without reloading the whole page. Outside of accessiblity, ARIA allows you to make your code more semantically menaingful. This helps clarify why you wrote what you wrote to other developers, and your future self.
ARIA provides a ton of tools to enhance the meaning of your markup. Today we’ll look at three main aspects of ARIA: roles, state and properties.
A role tells the browser what an element’s intended purpose is. Every html element has an implicit role that is communicated to assistive technologies through the accessibility tree.
<!-- The following markup has an implicit role of "heading" --> <h4>Hello World</h4> <!-- The following markup has an implicit role of "checkbox" --> <input type="checkbox">Check me</input>
Using ARIA, we can give an element an explicit role as well.
<!-- The following markup has been given an explicit role of button--> <div role="button">Click Me</div> <!-- The following markup has been explicitly defined as a banner for the page. It could contain an image, slogan or other informative general content --> <div role="banner">...</div>
A list of all ARIA roles can be found here.
Avoid Redudancy Like we said earlier, all elements have an implicit role. If there is native HTML that will express the role you need, use that and don’t add another role.
<h1 role="heading">This has a pointless role</h1> <!-- The above markup already has a clear implicit role. Defining its role explicitly only complicates what the browser has to do -->
Information about the current status of an element that is expected to change frequently. Very similar to properties.
<input type="checkbox" checked>I've been checked</input> <!-- The "checked" attribute provides information about the input's current state -->
Let’s say we have a button that toggles more information about something.
A sighted user will be able to see what state the button is in based on how it’s styled. Someone using a screen reader will know they can interact with the button, but won’t be able to tell what state it’s in.
<button aria-expanded="true">See More</button>
aria-expanded attribute lets us specify the state of our button for a screen reader.
Extra information about an element that is not generally expected to change. Some properties may change during the lifetime of an application, but it is less common. Becuase of their similarities, many specs list states and properties together.
What if we had multiple toggle buttons with the same role for displaying extra content in various places? We could use the
aria-controls attribute to link together elements semantically.
<button aria-controls="bonus-info-1">Learn More</button> <article id="bonus-info-1"> <!-- Extra information --> </article>
Properties allow us to define relationships between elements, as well as define aspects about how the element should function.
aria-label element works like an alt-tag for accessibilty. The screen reader will replace the default text of the element with the
<button aria-controls="bonus-info-1" aria-label="See more information">Learn More</button> <article id="bonus-info-1"> <!-- Extra information --> </article>
aria-label to “See less information”.
There are many more properties within ARIA that can help clarify your markup. A few useful ones are listed below:
“What Am I”
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.
“Who am I Related To?”
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
Links to more comprehensive lists of properties are in the Resources at the end of this lesson.
Testing for Accessibility
There are a variety of resources available to developers for accessibilty testing.
- This plugin will test your webpage for any accessibility defects. It can be good for finding big issues you want to address
- This plugin is a screenreader you can install in Chrome. It makes manual testing easy, and is used by Google’s own devlopers.
- This is the native screen reader for OSX. It can be strange with Chrome, but is good for testing accessibility in Safari, or any desktop applications you may develop down the line