Re: nuance in ARIA

In a recent post, Dave Rupert wrote about how HTML is general and ARIA is specific. He explains that unlike HTML, in ARIA is quite specific.

This resonated with me. Of course, to use HTML, you’ll want to be specific about what you use, because semantics. But, as Dave writes, there is usually more than one way to do something. Between different ARIA roles, states and properties, there is more nuance.

One reason ARIA is more nuanced, is that the world of ARIA mimicks the world of assistive technologies, through platform accessibility APIs. Assistive technologies already exist, and they already interact with platform APIs in specific, defined ways. When web developers build interactions that assistive technologies are aware of, ARIA can be used to describe most of these specific interactions.

ARIA specifically distinguishes between menu items and links, or between alerts and alert dialogs, because operating systems and assistive technologies do. Technologies like voice control software, hardware switch controls and screenreaders rely on the roles, states and properties that are conveyed to them. Being specific helps them get it right. Whatever their ‘it’ is, there is a wide variety of tools that convey web content and parse accessibility meta data. Standardised nuance makes things more interoperable, reducing gaps between what websites want to do and what different assistive technologies are able and used to do. It also makes things more consistent for end users.

Because ARIA maps to the nuance of operating systems’ accessibility APIs, web developers have to understand those nuances too. Or… the nuance gets lost. In WCAG audits, I often find ARIA where the developer missed some of the nuances of specific ARIA concepts. I hear the same from other auditors, and, anecdotally, it feels to me that ARIA misunderstandings in real websites are quite common. To nobody’s fault, really, the nuance exists and it can be complex.

When developers misunderstand the nuances and specifics of ARIA, end users draw the short end of the stick. Which brings me to a closing question… what if there are ways to move the specifics and the nuance of ARIA towards browser code?

As Greg Whitworth tweeted the other day:

My personal goal is that the majority of web developers don’t have to touch ARIA for 80% scenarios. Thus devs will be delivering our users a more accessible and yet richer experience

Nicole Sullivan tweeted about this in October, too. Quoting from the middle of her thread (read the full thread, it is good):

I’m advocating for CSS & HTML that can swap from one tab to another.

Could we cover 80% of the use cases for tabs if we had a declarative way of building them? Then JS could handle the 20% of tabs that are so custom they can’t be declarative? Idk yet, but let’s try?

I’m also advocating for a11y to be built in. It’s beyond nonsense that every developer has to manage individual ARIA properties.

The ARIA part got over a 100 likes, it seems there is interest in this stuff!

I would love to see some of the current Open UI CG and CSS WG work lead to this. I’m thinking HTML elements that have ARIA baked in, and/or CSS properties that impact accessibility trees. You wouldn’t set ARIA as a developer, but if you would look at the afffected DOM nodes in the accessibility tree, you would find that the expected accessibility information is conveyed. This is, of course, easier said than done. Because web developers will have to indicate somewhere what it is they want. Browsers can’t magically make up the ‘nuance’ (but in some cases, they could cover quite a lot of ground).

As I understand it, ARIA attributes were once introduced as a temporary solution. Moving more ARIA specifics to browser code could reduce the surface for problematic ARIA in individual websites. The challenge, I guess, is to come up with ways to let developers express the same ‘ARIA nuance’, but in HTML and/or CSS, maybe by combining specific bits of nuance into easier to grasp primitives (this is non trivial; if it sounds like fun, join us in Open UI!).