ARIA

Native HTML elements have built-in keyboard accessibility, roles, and states.

If you choose to use ARIA instead or in addition, you are responsible for mimicking the equivalent browser behavior in script. If you are not a developer, you will need one to implement ARIA.


Impact

ARIA tags can greatly enhance accessibility, usability, and navigability for screen reader and screen magnification users. Developers can use it to incorporate accessibility into both new and legacy pages.

ARIA supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is no other mechanism.

 

Dos and Don'ts

Dos and Don'ts

Expand all

Dos and Don'ts

Use Native HTML When Possible

HTML, when implemented correctly, conveys the semantic meaning of the content to people using assistive technology (such as screen readers) without any additional effort because it is already mapped to the accessibility APIs.

Do

Use HTML elements.

Don't

Don't use ARIA when an HTML element is available.

Don't change native semantics unless it is essential.

Make ARIA Controls Usable With a Keyboard

ARIA overrides certain HTML attributes and functions. It also provides custom control semantics, but the control won't work as expected with a keyboard.

Do

Use ARIA and JavaScript to make custom controls accessible with a keyboard.

Don't

Don't use role="presentation" or aria-hidden="true" on a focusable element.

The ARIA-hidden attribute is intended to hide the content or element from the accessibility APIs and the element that has ARIA-hidden set to true is not supposed to be interactive in any way. Defining either of these attributes on the visible focusable elements results in some users focusing on nothing.

Include Accessible Names With Interactive Elements

Interactive elements such as but not limited to the following must have accessible names:

  • Links
  • Buttons
  • Text fields
  • Combo boxes
  • Radio buttons
  • Checkboxes

Without an accessible name, assistive technologies do not understand what the control does.

Do

Do use varying techniques to provide accessible names, which vary from control to control.

Some Techniques for Providing Accessible Names
Control Technique
HTML links and buttons The link text or button value becomes the accessible name.
Input text fields Associate a form control with its visible label either implicitly or explicitly.
Custom widgets Use ARIA-label or ARIA-labelledby.

 

Don't

Don't include an interactive element with a visible label but no accessible name.

Data Visualization

How to present data in an inclusive and accessible manner has been a session request for a while. Unfortunately, it has proven difficult to find speakers with experience in this area. Thankfully, this month we are joined by Neha Bansal, senior director of application development in the Office of Information Technology, to discuss accessibility in data visualization.

Mental Health & Accessibility

Join the Accessibility Ambassadors for a presentation and discussion about mental health issues and digital accessibility by Kim Doberstein from OIT Application Development.

A substantial portion of our users experience mental health issues, yet the subject rarely comes up in digital accessibility discussions. Kim will cover common mental health diagnoses, as well as design principles and WCAG success criteria that assist users with mental health issues.

All About Screen Readers

Join the Accessibility Ambassadors for a demonstration and discussion of screen readers by Accessibility Ambassador Khaled Musa from Academic Technology Support Services.

Please join us for a demonstration and discussion of this important technology with a screen reader power user!

Web Accessibility Checkers

Join the Accessibility Ambassadors for a joint presentation by Tonu Mikk of the Disability Resource Center, Amy Drayer of University Libraries, and Kim Doberstein of the Office of Information Technology.

There’s a multitude of accessibility testing tools out there—so many that it can be hard to know which one to use. Our presenters will cover the pros and cons of various tools and how to get the most out of each in your testing.

Make ARIA Sing

ARIA is an important accessibility component that ensures complex web applications will work well with screen-reading software. However, when used incorrectly it can actually make accessibility worse.

Whether you are a soloist or part of a large group, learning the who, what, when, where, why, and how of ARIA can be daunting. Jenn Czeck will be your conductor, leading your site from a cacophony of sound to a harmonious melody. GIFs included.

Jenn is a former UMN employee. She currently works at US Bank as an accessibility consultant.

Creating an Accessibility Testing Plan

Once we know the basics of accessibility, it can be a daunting task to actually ensure that our work is accessible. In this session, Jen Sanders will go over the lessons she’s learned in her time as an accessibility-focused developer, things to watch out for, and how to make an effective testing strategy that works for your team. This is the same material as Jen’s presentation at DrupalCon Global 2020, but the content is not exclusive to Drupal. This presentation will be useful for anyone involved in creating accessibility plans—whether they be content creators or developers.

Folwell Web Theme Accessibility

When the Folwell Web Theme was created, component accessibility was considered every step of the way. Kathy and Dimitri will talk about the up-front research done for each component, the methods used to properly configure components to be accessible, the testing done for each component during and after development, and the ongoing updates being made to keep Folwell accessible.

Develop Accessible Websites

Following accessibility guidelines will help everyone who contributes to websites make web content that is more usable by more users on more devices.

Subscribe to Websites and Applications