This content originally appeared on hiddedevries.nl Blog and was authored by hiddedevries.nl Blog
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’ accessibiity 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
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, 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 it is applied and the accessibility information is conveyed.
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!).
The post Re: nuance in ARIA was first posted on hiddedevries.nl blog | Reply via email
This content originally appeared on hiddedevries.nl Blog and was authored by hiddedevries.nl Blog
hiddedevries.nl Blog | Sciencx (2022-01-28T18:40:00+00:00) Re: nuance in ARIA. Retrieved from https://www.scien.cx/2022/01/28/re-nuance-in-aria/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.