ARIA 1.1 – What’s New?

This article assumes you are already familiar with Accessible Rich Internet Applications (ARIA). If you want a refresher, my favorite introduction to ARIA is the Read Me First section of the ARIA Authoring Practices. And you can’t start using ARIA before you read the aptly named Using ARIA.

ARIA consists of attributes that can be added to native source code (such as HTML or ePub) to communicate information about an element’s name, role, state, properties, or relation to other elements to assistive technologies.

ARIA is a lot like CSS for assistive technology users in that it is purely descriptive. It does not cause the browser to change the underlying element’s appearance or functionality. For instance, putting role="button" on a <div> element does not make it focusable or keyboard “triggerable,” it merely instructs the browser/screen reader combo to describe the element as a button.

For more details on how ARIA is processed by browsers, operating systems and assistive technologies see Google’s Introduction to the Accessibility Tree.

Though the assistive technology adoption of ARIA 1.0 did not happen overnight, it is not an exaggeration to say that it has fueled a web accessibility miracle for people using screen readers because sadly screen readers are the early, and sometimes the only, assistive technology applications to support ARIA.

1. It enabled a new and much more accessible paradigm for tooltip and error handling in forms.
2. It provided a mechanism for assistive technology announcements called live regions.
3. It offered roles and attributes that made it possible to code web-based versions of popular desktop widgets that could not be coded using HTML alone, such as tabs and menus.
4. It introduced landmarks, a mechanism to describe the standard visual layout of webpages independent of their content.

You can also use ARIA to fix “œscratch and dent”€ web pages by providing missing assistive technology semantics for elements such as form labels, headings, lists, and broken tables. This use case actually made ARIA a lot more popular than initially expected.

Any update or successor to ARIA 1.0 had a lot to live up to.

On a dark and stormy February day in 2018, that successor, the ARIA 1.1 recommendation was unleashed on the unsuspecting world. (well, it wasn’t unsuspecting, but it sounds a lot more dramatic to put it that way).

In this article I do my best to make sense of the new and modified ARIA 1.1 roles and attributes.

My approach

I consider an ARIA role, attribute or construct to be effective if it meets 4 conditions:

• It addresses a common problem that cannot be easily addressed using HTML markup.
• It must be understood and applied correctly by developers.
• In order to conform to WCAG it must be accessibility supported.
• It must be understood by the end user (typically a blind or low vision screen reader user).

I use these 4 criteria as the basis for my rating. I rate the usefulness of individual ARIA 1.1 roles/attributes on a 5-point scale.

• A rating of 4 or 5 means I am already using the role/attribute, at least cautiously with user agent testing. These are the items that I go further into detail about.
• A rating of 3 means I want to use the role/attribute as soon as assistive technology support catches up.
• A rating of 2 means I can imagine needing to use the role/attribute but have not found an actual scenario yet, or I don’t expect assistive technology support for it in the foreseeable future.
• A rating of 1 means I don’t understand why I would ever need to use the role/attribute.

My evaluation is purely based on my needs and perspectives. I manage a group of websites, mobile apps and documents for a large financial services provider and do not frequently have to code special purpose web apps such as games or complex spreadsheet applications.

Also keep in mind that ARIA is not intended only for HTML. Some of the roles and attributes that I find baffling for the web would make perfect sense in other formats such as ePub. The evaluation is based on current assistive technology support (which can and hopefully will improve).

From this article I link out to Code Pen examples that I’€™ve created to practice ARIA, track assistive technology support and file bugs. For most up-to-date information on support and bugs, follow the links to the CodePen examples.

And now, without further ado, let’s get started.

ARIA 1.1 roles

Did you know? The role attribute is the only ARIA attribute that does not start with “aria-?” Yes, there is no aria-role attribute.

The ARIA 1.1 roles are defined in the role section of the ARIA 1.1 recommendation. To use an ARIA role, simply add the attribute role="value" to the element, where the value is one of the ARIA roles from section 5.4. When the role value is that of an interactive element, the author must make sure the behavior of the underlying element matches the expected interaction. E.g. a button must be focusable and operable with the enter key or spacebar. When in doubt, consult the excellent ARIA Authoring Practices guide for guidance and examples.

ARIA 1.1 introduces a smattering of new roles and updates the definition of a few existing ones. In this article, roles that are either ready for use (a rating of 4 or 5) get their own entries. The remaining roles are demoted to a table with brief explanations of why I have my reservations about their usefulness.

The table and cell roles

(Let’s gather around the synthetic table)

• My Synthetic ARIA table on CodePen
• Rating: 4/5.

ARIA 1.1 introduces a duo of tabular construct roles, table and cell.

• The table role goes on the simulated table container element (equivalent of the html <table> element).
• The cell role goes on a simulated table cell element (equivalent of the HTML <td> element).

The new roles supplement existing ARIA 1.0 row, columnheader, rowheader and rowgroup roles to provide a complete set of building blocks for a simulated static data table. yes, now it is possible, however semantically criminal as it may seem, to build complete tables without using any HTML table markup elements whatsoever.

At first I was a bit baffled as to why we need a full set of table roles. Then I came across an article by longtime accessibility superhero Leonie Watson that explains how the ARIA 1.1 table roles can be used to provide a text alternative to SVG graphs.

Even more recently, much to my shock and chagrin, I came across tables implemented without a single HTML tabular element. As much as a part of me would like to knock some sense into whoever coded them that way, I can do the right thing and gently instruct them to use the ARIA table roles to fix them.

We’€™re also tackling the problem of responsive tables, which may involve coding real tables as series of divs sprinkled with dark CSS magic. In that scenario, the ARIA table roles may be required.

Screen reader support for synthetic table is surprisingly robust, see specific notes in my CodePen example.

The region role is now officially a landmark

• The ARIA 1.1 definition of region
• Grade: 5/5

The ARIA 1.0 definition of the region role has been updated. An element with role="region" is now a landmark if it has an accessible name. I’ve often come across situations where content should be grouped in a landmark, but no other landmark roles are appropriate for it. Most assistive technology applications already interpreted regions with an accessible name to be landmarks even if the ARIA 1.0 specification did not clearly state so.

Roles that didn’t make the cut

Here is a table of roles that didn’t make my “use now” or “can€’t wait to use” lists.

Role	Grade	Notes	Screen reader support
feed	3/5	The purpose of the feed role is primarily to bring the (dis)pleasures of infinite scrolling to screen reader users.	This role requires screen reader vendors to implement auto scrolling behavior, which, in turn, requires a whole new interaction mode.
figure	2/5	Useful in ePub and other formats, figures are rarely used on the web. When used, the <figure> element (equivalent to the figure role) is usually incorrect.	Mixed, some screen readers announce the figure role, some announce a group role, some don’t announce it at all.
none	2/5	Replaces the presentation role, developers find the name just as confusing and still think it hides the element’s contents. Problem should be addressed with better documentation and more examples, not with a new role whose name is just as confusing as the old.	Decent support
searchbox	3/5	The searchbox role goes on text input elements used for website search and distinguishes those inputs from your run-of-the-mill text inputs used for information gathering.	Currently assistive technology support is pretty rudimentary.
switch	2/5	We already have two toggle controls, a checkbox and a toggle button, I don’t see how adding a third control that toggles between two states helps users or developers.	Jaws has decent support, NVDA treats it like a toggle button.
term	3/5	The term role supplements the ARIA 1.0 definition role to form an explanatory combo.	Assistive technology support is pretty much non-existent.

ARIA 1.1 attributes – from potent new properties to deprecated duds

ARIA attributes are used to communicate information about elements, such as their accessible name, state (e.g., checked or selected), properties (e.g., read only or invalid) and relationship to other elements (e.g., an element with a tooltip or an error message) to assistive technologies. A full list of ARIA 1.1 attributes can be found in the Supported States and Properties section of the ARIA spec.

ARIA 1.1 introduces a smattering of new attributes, expands the meaning of a few existing attributes, and marks a couple of ARIA 1.0 attributes as deprecated, which means that while they are valid for backwards compatibility they should no longer be used, may they rest in peace. Attributes with a rating of 3 or higher get their own sections, attributes with a rating of 2 or 1 are demoted to a table.

aria-modal

(I can finally have a date with a super modal)

• The ARIA 1.1 definition of aria-modal
• My aria-modal example on CodePen
• Grade: 4.5/5

Aria-modal is my favorite ARIA 1.1 attribute. Making modals accessible is a tricky business. You have to:

• Manage focus, (when a dialog is displayed, place focus inside the dialog). When dismissed, focus goes back to the trigger unless the dialog interaction changes the context).
• Ensure that the keyboard focus is trapped within the modal (users should not be able to tab into the webpage from the modal).
• Hide the regular webpage content from assistive technologies while the modal is visible, to prevent screen reader users casually ambling out of a modal dialog in browse mode and trying to interact with the inert background content.

The first is fairly easy, just manage the focus when the dialog is displayed and dismissed. The second is not too difficult. Just add a keyboard listener to the first and last focusable elements in the modal dialog and make sure pressing tab key (with focus on the last element in the modal) or shift–tab (with focus on the first element in the modal) either wraps around within the dialog or does nothing. But the third requirement can be a PITA to implement, Tzatziki sauce optional.

See more information in the article “The current state of modal dialogs” from the Paciello Group.

If the modal dialog container element is a sibling of the webpage content element, the task is not too hard. Just add aria-hidden="true" to the webpage content element while the modal dialog is visible then remove it when the dialog is dismissed. But if the modal dialog element is a descendant of an element whose contents need to be hidden, you can’t use that approach, hiding the parent element also hides the modal dialog element and its content.

But developers fret no more, aria-modal to the rescue. Just add aria-modal="true" to the modal dialog element (the element that has role="dialog" or role="alertdialog", and the browser/screen reader takes care of hiding the inert content while the dialog is visible and has focus.

This is an attribute that can save web developers tons of Javascript, testers a lot of headaches, and create a more consistent assistive technology user experience, a shining example of how we can create a better web experience by shifting some of the burden to the user agent/assistive technology.

Thanks to browser and assistive technology vendors, aria-modal is already fairly well supported, though there are still some gaps.

Highlighting current elements with aria-current

• The ARIA 1.1 definition for aria-current
• aria-current explanation and examples from Leonie Watson (great article, like most things from Leonie).
• Grade: 4/5

aria-current is my second favorite aria 1.1 attribute.

We often use CSS to visually highlight the currently active element in a set of elements, e.g., the current step in a progress bar or the current page in a breadcrumb pattern. We’ve had to resort to a mixture of visually hidden text, experimental use of title attributes, and other hacks with inconsistent assistive technology support to provide an equivalent affordance to assistive technology users.

But developers hack no more! The aria-current attribute can handle this. Just apply it to the current element (the element that has a CSS class such as “active” €or “selected“, and set its value to one of the pre-defined tokens of “date“, “œtime€“, “step“, “€œpage“, or “œlocation“. When in doubt just set it to the catch all value of €œ”true“.

This is another scenario where ARIA truly becomes a CSS for, to use an overly politically correct term, the differently sighted. It solves a problem that HTML alone is not able to, brings a new dimension to people who can’t see the page and already has good assistive technology support.

Attributes that did not make the cut

Here is a table of attributes that didn’t make my “use now” or “œcan’t wait to use” list.

attribute	Grade	Notes	Screen reader support
aria-details	3/5	The aria-details attribute is used when an element needs an explanation that is either too long to fit into a text alternative or requires semantic markup for understanding.	Inadequate current assistive technology support.
aria-grabbed and aria-dropeffect	N/A	ARIA 1.0 attributes that have been deprecated, (dropped from the spec), probably due to lack of user agent support.	N/A
aria-errormessage	3/5	The combo of the new aria-errormessage and the ARIA 1.0 aria-invalid attribute provides a mechanism to manage the announcement of error messages by assistive technologies more easily.	Assistive technology support is MIA.
aria-haspopup	3/5	Back in the days of ARIA 1.0, the aria-haspopup attribute used to be Boolean. It was used to indicate that the underlying element was the lucky owner of a custom menu. But custom menus are relatively rare compared to, say, dialogs. The revamped ARIA 1.1 version of aria-haspopup addresses the situation by adding a list of valid values.	The idea is great, the new definition makes aria-haspopup a lot more useful, but the assistive technology support is still MIA.
aria-keyshortcuts	2/5	Too many restrictions, no guarantee it is keyboard accessible, limited assistive technology support, does not translate to mobile devices.	Limited, only half-decent in Chrome.
aria-placeholder	1/5	Inherently inaccessible, (either fails color contrast or likely to be mistaken for user input, can’t be used for visible labeling since it is not persistent).	Not tested
aria-roledescription	3/5	The aria-roledescription attribute provides authors with a rudimentary solution to create custom controls, or more accurately the illusion of custom controls.	There is some assistive technology support but, beware, aria-roledescription can actually override useful semantics in Jaws with IE 11.
Dynamic ARIA table attributes (ex. aria-colcount)	3/5	The ARIA 1.1 spec introduces 6 brand new attributes that go with the new table and cell roles, and expand the ability to refine complex grids and tables.	Assistive technology support is adequate.

Other exciting ARIA and HTML5 developments

My favorite part of ARIA 1.1 is the revamped ARIA Authoring Practices guide.

The documentation has been revised, simplified and contains examples that were written and vetted by the ARIA Authoring Practices Taskforce. We can’t stress it enough! Misused ARIA is worse than no ARIA, yet the ARIA spec, just like any other spec, is complex and at times confusing.

Having access to a detailed documentation and examples on how to develop common custom widgets has turned out to be a game changer for me and my team.

The guide examples also serve as a foundation for discussions on sufficient assistive technology implementation and a reference for filing assistive technology bugs.

Conclusion

In my opinion, ARIA 1.1 is a mixed bag. Some of the new and expanded roles and attributes truly shine and exemplify why ARIA is revolutionary for assistive technology understanding of web content.

The problems primarily have to do with the limitations of the ARIA framework.

• ARIA is only descriptive, it does not alter browser behavior.
• The ARIA specification does not dictate, or even suggest, how assistive technologies should expose the attributes, yet assistive technology vendors have limited presentation in the ARIA working group.
• The ARIA specification is published without a supporting implementation.

The primary challenge to the rapid adoption of ARIA has to do with the WCAG conformance requirements.

To conform to WCAG, digital content must be accessibility supported (supported by at least one combination of a mainstream user agent and assistive technology application); writing standards compliant markup is not sufficient.

This creates an ARIA chicken and egg problem.

• Authors can’t use unsupported ARIA and are forced to resort to hacks and workarounds.
• Assistive technology vendors see limited demand for updated ARIA support. After all the content authors are not using it.

To turn a chicken and egg problem into a chicken and waffles problem (sweet and delicious), any future publication of ARIA should come with at least one supporting implementation and the documentation of an ARIA role/attribute should include a more detailed description of expected or adequate assistive technology implementation.

Another thing that is a bit of a mystery to me is why ARIA is so focused on HTML parity. Some HTML is inherently inaccessible, e.g., placeholder content. Other content is best coded with real HTML, like definitions. My favorite ARIA roles and attributes are the ones that supplement HTML and/or make some tasks simpler and more consistent.

My guess is that the ARIA working group is thinking beyond HTML to other markup languages, something that I don’t really have to deal with, or supporting the semantically devoid code frequently generated by the latest and not-necessarily-greatest Javascript frameworks.

I have a list of challenges that I wish I could solve with ARIA, but I will leave that list for another day, another Christmas, ho ho ho.

What can we do to move ARIA forward

We need to strengthen networking between the people writing the ARIA specification, the assistive technology vendors implementing ARIA, the experts and developers trying to use ARIA in everyday situations, and the end users.

I had a brief stint in the ARIA and ARIA Authoring Practices working groups a few years ago while working for an accessibility vendor, and I have some insider information. The people working on ARIA are some of the smartest and most forward-thinking experts in the field of accessibility (or any other field for that matter).

But there’s a lot of work to be done and it can’t be achieved by a dozen people, however superhuman their skills may be. Taking ARIA to the next level requires all the hands, advocacy, analysis and brain cells we can spare.

It’s up to us to explore ARIA, ask questions, file bugs, use new ARIA roles and attributes even if they are not fully accessibility supported (as long as that use does not create a user blocker), and suggest new roles and attributes that we’ve put on our wishlist.