// Stacy Carston Sporie

WAI (not) ARIA

Today, ARIA is an integral part of the modern web experience. Many common patterns require at least a little ARIA to support an accessible experience. Yet, the WebAIM Million also finds that home pages with ARIA average over 30% more errors than home pages without. At the very least, using ARIA appropriately requires skill and judgement.

This presentation is aimed at getting you started on learning the skills needed to use ARIA wisely. We will briefly touch on foundations of ARIA and how it fits in with HTML, before diving into common web design patterns and evaluating if ARIA is needed, and if so, what ARIA is appropriate to apply? Attention will be brought to typical mistakes encountered as well as any testing and maintenance considerations.

WAI (not) ARIA slidedeck (PowerPoint)

ARIA Basics

ARIA Inspection Exercise

Patterns

Disclosure (Expandable Content)

About this pattern:

A disclosure component contains additional content that can be shown or hidden by activating a control. For the purposes of this exercise, let's primarily consider content that expands inline with the rest of the page, either as part of the main page body or a toggle that shows additional content in a sidebar. Disclosure components go by many names, including "show/hide", "expandable", "expand/collapse", "details/summary".

Disclosure Exercise
Why ARIA? Disclosure

aria-expanded seems like a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • <details> and <summary> are semantic HTML alternatives, however, it has some gotchas.
    • Support is varied enough that I would be comfortable answering this as "Yes".
  • Does the ARIA pattern I want to use fit the intended behavior?
    • Yes, aria-expanded can be used with the button role, and describes the behavior accurately.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes (as there is no additional behavior needed).
  • Is this ARIA pattern reasonably well-supported?

What to watch out for:

  • aria-expanded must be set on the control (<button>), not the content container.
  • aria-expanded must be kept in sync with the current state of the disclosure.
References Disclosure

Accessible Disclosure Demo

ARIA documentation:

HTML Techniques:

Names and Labels

About this pattern:

One of the basics of web accessibility is providing text labels (or accessible names) for interactive elements. This pattern isn't really a single pattern, but more so a collection of techniques related to setting accessible names for interactive elements. Whether to use ARIA or not will depend on the specifics of each scenario, and the drawbacks should be carefully evaluated.

Names and Labels Exercise
Why ARIA? Names and Labels

Some tips for evaluating these scenarios:

  • Are there no well-supported semantic HTML alternatives?
    • While there are valid use cases, the answer to this question is often no.
      • <label> provides an accessible name for input fields
      • Links and buttons are named using their content.
    • Ask yourself: Is there a strong need to override this name with something else?
  • Does the ARIA pattern I want to use fit the intended behavior?
    • Remember that aria-label and aria-labelledby will override other labeling methods (and aria-labelledby will override aria-label). It's easy to create a situation where the accessible name does not match what would be visually seen as the label for an element.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes, as there is no additional behavior needed.
  • Is this ARIA pattern reasonably well-supported?
    • Yes, aria-label and aria-labelledby are generally well supported.

What to watch out for:

  • The accessible name must stay in sync with the visual experience
    • 2.5.3 Label in Name
    • Copy & paste where the visual label is updated but not aria-label or aria-labelledby points to invalid ids
    • Future updates change page content but forget to change aria-label
    • Typos that go unnoticed if testing is not thorough
  • aria-label is usually not translated by automated translation tools
  • If a control needs extra context through ARIA, is that information truly obvious visually?

To emphasize the first point: One of the most common ARIA issues I encounter during testing is incorrect labels provided with aria-label.

References Names and Labels

Accessible Names and Labels Demo

ARIA documentation:

HTML Techniques:

<svg> Text Alternative

About this pattern:

Providing a text alternative for <img> elements is typically a straightforward technique. However, <svg> can also be used to provide graphics, and there can be a little extra work to ensure role and accessible name are correctly represented.

<svg>s are not limited to representing a single graphic with a single corresponding alt text, but that is the most common use and what this example is focused on.

<svg> Text Alternative Exercise
Why ARIA? <svg> Text Alternative

role="img" seems like a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • <svg> has the <title> element, which should be used to provide the text alternative.
    • However, we still need to provide a role for the <svg>
  • Does the ARIA pattern I want to use fit the intended behavior?
    • Yes, role="img" is an exact fit.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes, as there is no additional behavior needed.
  • Is this ARIA pattern reasonably well-supported?
    • Yes, role="img" is well supported.

Other notes: Sometimes aria-label or aria-labelledby are used alongside role="img" on <svg>s. Currently, they don't seem to be necessary anymore, but worth looking at if you run into issues.

References <svg> Text Alternative

Accessible <svg> Text Alternative Demo

ARIA documentation:

SVG documentation

Inline Error Messages

About this pattern:

Inline error messages are a very common pattern used to display form validation errors. In this pattern, error messages are usually displayed below the invalid input, and dynamically updated based on the current value of the input.

Inline Error Messages Exercise
Why ARIA? Inline Error Messages

Some tips for evaluating these scenarios:

  • Are there no well-supported semantic HTML alternatives?
    • Yes, while there is native HTML error handling, it comes with it's own set of accessibility challenges.
  • Does the ARIA pattern I want to use fit the intended behavior?
    • aria-describedby is not specifically for error messages, but it has been used by convention for this.
    • aria-errormessage also exists, support has typically been lagging but it seems like this may be changing. Worth testing out.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes, as there is no additional behavior needed.
    • However, you should also consider keyboard behavior on form submit. Moving focus to the first field with an error can be very helpful for users.
  • Is this ARIA pattern reasonably well-supported?
    • Yes, aria-describedby and aria-invalid are well supported for input fields.
      • aria-errormessage may require some additional testing if you'd like to use that instead.

What to watch out for:

  • Hidden content (hidden, display:none;, etc.) will still be announced when referenced by aria-describedby
    • Error messages must be added and removed from the DOM instead of toggling visibility.
  • aria-describedby references id values. These are prone to breaking when code is copy & pasted or undergoes significant changes.
    • Make sure your id values are unique!
References Inline Error Messages

Accessible Inline Error Messages Demo

ARIA documentation:

Hidden Content

About this pattern:

Sometimes, we need to hide content. Before reaching for ARIA to do this, evaluate what type of hiding you need to do:

Never use aria-hidden when you intend to hide content from all users. Misuse of aria-hidden creates critical barriers for blind users.

Hidden Content Exercise
Why ARIA? Hidden Content

aria-hidden should be used with extreme caution:

  • Are there no well-supported semantic HTML alternatives?
    • Only if your goal is to hide visible content from assistive technologies. Otherwise, hidden or display:none; work excellently.
  • Does the ARIA pattern I want to use fit the intended behavior?
    • From the ARIA specification: Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes, as there is no additional behavior needed.
  • Is this ARIA pattern reasonably well-supported?
    • Yes, aria-hidden works almost too well.

What to watch out for:

  • aria-hidden should never be applied to focusable elements or a container with focusable elements.
  • Do not use aria-hidden="false", this is not always interpreted correctly.
References Hidden Content

Accessible Hidden Content Demo

ARIA documentation:

HTML techniques:

Current Location

About this pattern:

Sites will often change the visual appearance of a link when it matches the current page. Or, if there is a list of steps, the current step will be highlighted in a visual manner.

Current Location Exercise
Why ARIA? Current Location

aria-current seems like a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • Yes, there is no corresponding "current" HTML attribute.
  • Does the ARIA pattern I want to use fit the intended behavior?
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Yes, no additional behavior is required.
  • Is this ARIA pattern reasonably well-supported?
References Current Location

Accessible Current Location Demo

ARIA documentation:

Announcements

About this pattern:

This pattern is focused on a purely ARIA concept: live (or aria-live) regions. Live regions define an element that is expected to receive updates that users should be made aware of. Typically, screen readers will announce this content. Live regions should generally be used in one of two ways:

  1. Define a region of visible content that recieves updates and should be announced.
  2. Define a visually obscured region that will recieve updates intended specifically for screen reader users.

Announcements Exercise
Why ARIA? Announcements

Determining if a live region is a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • There is no HTML alternative for a live region, however, it's worth investigating if another pattern would convey the needed announcements instead.
  • Does the ARIA pattern I want to use fit the intended behavior?
    • text
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • text
  • Is this ARIA pattern reasonably well-supported?
    • Live regions are well-supported by screen readers, but there c

What to watch out for:

  • Don't make a large region of a page into a live region.
  • On a similar note, avoid lengthy, wordy updates when pushing screen reader announcements.
  • Live regions need to be present in the page before content is added/removed. Adding and removing the entire live region will often not work.
  • Consider how often the live region will update, and if this can become overwhelming for users.
  • For screen reader announcements, the text will present and screen reader accessible somewhere in the page.
    • Consider where this is placed to avoid confusing users.
References Announcements

Accessible Announcements Demo

ARIA documentation:

Tab Panel

APG: Tabs with Automatic Activation

APG: Tabs with Manual Activation
Why ARIA? Tab Panel

Determining if the ARIA tab panel pattern is a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • Yes, HTML does not have native equivalent to tab panels.
  • Does the ARIA pattern I want to use fit the intended behavior?
    • Usually tab panels are straightforward to identify, though some more creative designs may push this boundary, especially if there is content between the tab controls and the tab panel.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
  • Is this ARIA pattern reasonably well-supported?
    • Yes, tab panels seem to be reasonably supported. May want to double check the interactions on a mobile device.

What to watch out for:

  • Note that tabs are expected to be navigated with arrow keys, instead of placing each individual tab button in the focus order.
  • Pay attention to the structure and which roles go where, especially on the tablist.
    • The tab role must be applied to the focusable, interactive element that controls each tab.
References Tab Panel

Tabs Pattern (ARIA Authoring Practices Guide)

ARIA documentation:

Dialog

APG: Modal Dialog

APG: Alert Dialog
Why ARIA? Dialog

Determining if the ARIA dialog pattern is a good fit:

  • Are there no well-supported semantic HTML alternatives?
    • A <dialog> element has been added to HTML, and support has been improving. Whether on not to use role="dialog" or <dialog> will depend on your specific needs, and is worth testing out.
  • Does the ARIA pattern I want to use fit the intended behavior?
    • Modal dialogs are easy to identify, however, non-modal dialogs may require some additional consideration to determine what the best pattern is (should it be considered a dialog).
    • Review the description of alertdialog before using it. Make sure your dialog really should be treated as an alert.
  • Can any additional behavior required by this ARIA pattern be accomodated by this design?
    • Dialogs require additional keyboard behavior and focus management that must be implemented.
  • Is this ARIA pattern reasonably well-supported?
    • Yes, though depending on the specific scenario and targetted browsers, additional work may be needed for features like preventing users from escaping modal dialogs without closing them.

What to watch out for:

  • Focus management is key for accessible dialogs.
  • Be aware of the differences between modal and non-modal dialogs.
  • Do not set aria-hidden when the dialog is not displayed. A dialog that opens without removing aria-hidden will be inaccessible to screen reader users.
References Dialog

Dialog (Modal) Pattern (ARIA Authoring Practices Guide)

Alert and Message Dialogs Pattern (ARIA Authroing Practices Guide)

ARIA documentation:

Testing Scenarios

Updating a Disclosure Pattern

Scenario Description:

You are making updates to an existing site in response to an audit that discovered multiple accessibility issues. One of these issues was a lack of feedback when interacting with the disclosure (expand/collapse) components on the site.

Alternate Scenario Description:

Instead of applying aria-expanded to the existing buttons used in this component, you decided to re-work the entire component to use the HTML <details> and <summary> elements instead. How might this change your testing approach?

Testing Scenario: Updated Disclosure Scratchpad

New Checkout Process

Scenario Description:

You are updating an e-commerce website with a brand new checkout flow. This checkout flow includes the following patterns that have been newly implemented for this update:

Testing Scenario: New Checkout Process Scratchpad

Bonus: Maintenance

For either of the scenarios above, what are some ways you could improve the long-term maintainability of these features?