This content originally appeared on marcus.io and was authored by marcus.io
In my experiences as an auditor (for WCAG and EN 301 549) I stumble over a large number of barriers. Heck, my job is to find and to help the website developer and owner to get rid of them to make their web project more inclusive and – in the truest sense of the word - accessible.
But there is a certain type of barrier that are more, well, tragic than others. Instead of not being aware about the problematic approach the developer chose, they try to improve accessibility but – unbeknownst to them - create new barriers in the first place doing it. Let's talk about three types of barriers, specifically related to WAI-ARIA, created with the best intentions:
Adding aria-label as some form of accessible description
Sometimes web developers use aria-label to add info to an already visually labeled control. This is all well and fine, as long as the visual label is part of the programmatic name (for example, supplied by aria-label). WCAG (Web Content Accessibility Guidelines) success criteria 2.5.3 even specifically checks if the visual label is a substring of the programmatic accessible name.
But the tragic begins when developers use aria-label to provide a form of accessible description. The value of this attribute may be helpful, it may even add more context and explanation to the control – but as long as the visual string is not part of the programmatic one, a new barrier is created, because aria-label overrides, not extends the accessible name of a control. WCAG 2.5.3 has users of voice control software in mind, and if they say "Click foo" (because it is the visual label), but foo is nowhere to be found, because the programmatic name of the control is bar – a barrier is established, albeit with a good original intention.
What could help solve this situation is if aria-description gains more support in screen readers – because this attribute is actually what these well-intended developers where looking for. It does not override, but extend the output of screen readers. [Problems with the automatic translatability] of aria- attributes still remain, though. Therefore, it is always recommended to work with ID references to other elements via aria-labelledby or aria-describedby (both of which are well-supported).
Adding an ARIA Role is enough, or: Adding ARIA implements functionality
For many, WAI-ARIA is considered some kind of magic fairy dust of accessibility – and often, ARIA is the first or second keyword I hear when the topic comes to inclusive web interfaces (usually aria-label- which leads me back to the first part of this article).
So, all in all, ARIA seems to not have an awareness problem. The real issue lies in the understanding what it does and what it does not do. It is built on top of HTML, but only a syntactic extension, and therefore offers information about what an element is, what state it is in and how it is meant to be used. But what ARIA properties do not do is implement key event handlers or other functionality of this kind. Most of the time, it only announces an element as something, therefore builds up expectation e. g. about a certain form of keyboard usage. But adding for example role="button" to a <div> only makes a statement and a promise, "I'm a button now", but does not deal with other properties of such a control. Web developers have to implement focusability and keyboard activation forms (reacting to SPACE and ENTER) themselves, for example, Alas, this is the part that is often times forgotten, leaving it as a barrier with best intentions (because the developers likely overestimated ARIA's power).
What to do instead
With very few exceptions, there are HTML elements that bring both the necessary role and all accompanying behaviour with them: Let's take the <button> element, which has the implicit role of button and relays SPACE and ENTER key presses to the click event handler. It's the easier and more convenient route to go and the reason why the first rule of ARIA is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
Roles that are not what you think they are
Sometimes, an approach of "I'm sure that what is meant with a particular semantic role" is a bad one. Let's show some examples:
Menu
The word "menu" is very blurry when it comes to user interfaces, and its definition is at least as unclear as "dropdown". Both keywords could mean many things: navigation lists or select inputs or disclosure widgets respectively. While the colloquial definitions of "Menu" or "Menubar" each may be rather obscure, the ARIA specification is quite clear what these roles (and sub-roles like menuitem) are meant for. To quote Adrian Roselli:
To clarify — if you are rebuilding the interface for Microsoft Word, then the File menu gets
role="menu", lives inside arole="menubar"container, all while File → New, File → Open, File → Save, and so on each getrole="menuitem".
So, unless you are building the next web-based desktop-like app (think: Google Docs), better not use ARIA menu or menubar roles. Like I said in the last section - semantic roles are "promising" a certain kind of keyboard usage pattern. Also, you can't put just any role in a menu, you are limited to menuitem, menuitemcheckbox, menuitemradio, separator and group roles. These two obligations combined should make you reconsider to maybe use another element:
What to do instead
Use so-called disclosure widgets. They consist of - in general - two parts: a trigger and a container. An interaction with the trigger (it makes the most sense for it to be a <button>) influences the perceivability of container – and that is about it. No keyboard behaviour is promised (the focus stays on the trigger after activation), no semantic roles are "forbidden" in the container. The only thing the developer has to take care of is the sequence, meaning that trigger and container should follow each other directly:
<button aria-expanded="true|false">
<!-- aria-expanded communicates that the construct is a disclosure widget in the first place. Thus, the true/false values have to be changed dynamically -->
Navigation
</button>
<div><!-- It would be the easiest option to add or remove a "hidden" attribute -->
...
</div>Banner
Sometimes, the role of banner seems to look like something that should be applied to page regions that are visually a banner, for example cookie banners. But its original intention is something different, als MDN states correclty:
The banner role is for defining a global site header, which usually includes a logo, company name, search feature, and possibly the global navigation or a slogan. It is generally located at the top of the page.
So, role="banner" is the central header of a document.
What do do instead
I guess the intention of misleadingly choosing the banner role was to convey that the following block is its own area with its own content and functionality (like a cookie banner would be). The better way to communicate that is a generic landmark:
<div role="region" aria-label="Manage Cookies">
...
</div>Listbox
I sometimes saw developers applying role="listbox" on containers that are listing items, for example slides in a carousel. That testifies to good intentions, but, alas is wrong :
A listbox according to the ARIA specification is a container for interactive items, from which the user can select one from in context of data entry – think of the list of options you can choose from when you are triggering a <select> element. That does not quite fit into the exemplary carousel widget. It is much more sensible to use the following:
What do do instead
Simple list semantics (<ul> or <ol> and <li>) will suffice when you're not looking to re-build a <select> element with ARIA (or a combobox for that matter).
Conclusion
My advice is to handle ARIA, its roles and other properties with care. I like to compare the ARIA toolbox to a set of knives in you kitchen: Very mighty if you know what you are doing (and - in rare occasions - even necessary), but also potentially dangerous, since you can hurt maybe not yourself, but others. Just as you would not wave around with a sharp appliance (even with the best intentions), I would advise not to use WAI ARIA if you are not exactly sure what it does. And while ARIA can be hard to grasp and the specification can sometimes be cryptic, abstract and not always helpful at first glance – it's the wiser choice to leave it be, if unsure. Best intention barriers could be prevented this way.
Update May, 13th, 2024
"ARIA doesn't implement anything" was too broad of a statement. I changed that sentence, but keeping the notion that ARIA is most of the time not the magic (and complete!) tool many assume.
This content originally appeared on marcus.io and was authored by marcus.io
marcus.io | Sciencx (2024-05-11T00:00:00+00:00) Best intention barriers (ARIA edition). Retrieved from https://www.scien.cx/2024/05/11/best-intention-barriers-aria-edition/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.