I worked hard to inform people around me about the importance of accessibility. It takes time, but it’s totally doable. Everybody can understand it when they are made to think beyond. I still have to work on it but I like the current level of awareness I was able to help them reach. But awareness alone is not enough – it can even be dangerous. In this post I will focus on the technical part of accessibility, especially ARIA (Accessible Rich Internet Applications, opens in new window) and what to be careful about it.
ARIA gives developers additional semantics that is missing from HTML. It’s based on concepts and needs that were established with Windows 98 and beyond. That’s one of the main reasons for some problems with it, I think. Some aspects of desktop PC semantics from previous millennia can’t really be applicable to present mobile, as an example. I was also surprised to learn that some parts of ARIA can’t even be supported on non-Windows desktop computers like Mac. Mac’s accessibility APIs just don’t support all of ARIA. Reasons for that are simple, naming just one of the most obvious – it isn’t possible to support something that is not there, as for example tree view.
In modern times we have to think beyond patterns from Windows – for example mobile devices. When we compare native mobile applications with desktop it’s quite obvious that a lot of desktop semantics can’t really be relevant for mobile devices. But that’s not the whole problem.
Some ARIA is only available in theory and some ARIA is widely unsupported
We have quite a lot of ARIA attributes available to us. I found that we have at least 53 different aria attributes available at the time of writing:
- aria-activedescendant
- aria-atomic
- aria-autocomplete
- aria-braillelabel
- aria-brailleroledescription
- aria-busy
- aria-checked
- aria-colcount
- aria-colindex
- aria-colindextext
- aria-colspan
- aria-controls
- aria-current
- aria-describedby
- aria-description
- aria-details
- aria-disabled
- aria-dropeffect
- aria-errormessage
- aria-expanded
- aria-flowto
- aria-grabbed
- aria-haspopup
- aria-hidden
- aria-invalid
- aria-keyshortcuts
- aria-label
- aria-labelledby
- aria-level
- aria-live
- aria-modal
- aria-multiline
- aria-multiselectable
- aria-orientation
- aria-owns
- aria-placeholder
- aria-posinset
- aria-pressed
- aria-readonly
- aria-relevant
- aria-required
- aria-roledescription
- aria-rowcount
- aria-rowindex
- aria-rowindextext
- aria-rowspan
- aria-selected
- aria-setsize
- aria-sort
- aria-valuemax
- aria-valuemin
- aria-valuenow
- aria-valuetext
These attributes are theoretically used to:
- make advanced widgets that are not available in the HTML,
- allow us to make live regions and specify how they behave,
- establish relationships between information in HTML,
- add semantics about states,
- define and even overwrite properties.
I’ve seen quite a lot of ARIA used wrongly and that’s naturally causing problems for assistive technology users. WebAIMs project Million (opens in new window) that scans a million webpages with automatic accessibility testing tool established that home pages with ARIA present averaged 70% more detected errors than those without ARIA.
Home pages with ARIA present averaged 70% more detected errors than those without ARIA.
WebAIM Million project on use of ARIA related with more errors (opens in new window).
Please don’t take this fact in isolation though. I think it has a lot to do with the ability of automatic accessibility tools detecting problems mainly in code. And the more ARIA used automatically mean we can detect more code-oriented errors. Like wrong syntax, missing required children and so on. Such kind of errors can be prevented with proper tools and processes and I think are not the main problem with ARIA.
Besides using wrong syntax – that can easily be prevented – the next problem is to use ARIA wrongly. As for example Adrian Roselli’s article “Don’t Use ARIA Menu Roles for Site Nav” (opens in new window) has to say about menu roles and why not to use them. It drills down to parts of ARIA that were meant to mimic old patterns in Windows 98, I think. And it’s very attractive for people new to ARIA to think “I must make a menu, nice there is ARIA with that role. I will use it to improve the semantics”. Why are they wrong is nicely defined by Adrian and I suggest you read it before you use it, but from my perspective it’s just a single example of misuse of ARIA.
I think that besides ARIA misuse, the main problem with ARIA is to use ARIA syntax properly, only to find out it’s not really supported in reality.
The main problem of ARIA, after ARIA misuse, is that we can write valid and proper code and think we have solved problems for everybody, only to find out it’s not really supported for most.
My reflection about some parts of ARIA.
It doesn’t really help if we make an complex widget from scratch, investigate how ARIA should support it, implement it by the rules and then find out it doesn’t actually work for most of our users with screen-readers, because it’s not (yet) supported. I hope we can agree with this.
Here comes the stage after awareness into consideration. We are aware that we need proper semantics in code to make things accessible. We know about ARIA, just enough to use it correctly and make valid code. But if we don’t know about gaps in support then we risk releasing non-accessible products anyway. Potentially products that used a lot of resources trying to make things work out. But then failing at the end due to theoretically perfect solutions that fail in practice.
Stage after accessibility awareness may lead us on wrong paths, for example believing that all ARIA is supported and making theoretically correct interfaces that don’t work in practice.
My reflection on theory versus reality after awareness stage.
ARIA needs to be planned and tested with assistive technologies in mind
The solution to missing support is not a simple one. We can create support tickets, lobby, maybe even fund vendors, but it is probably not very sustainable and practical if we want the support now, because we have to deliver.
So we should maybe take a step back, know our end users and what (assistive) technology they actually use and then plan accordingly. In some cases that’s simple, in others it’s impossible. When we do have the data we can be more efficient. When we don’t have the data we have a potential design changes in our hands.
What does the design have to do with ARIA? Well, I am not talking about visual design alone, I am talking about user experience for all users. Maybe there is a widget that can be simplified and maybe we can drop advanced ARIA altogether.
Maybe we can simplify the interactions so that we don’t need ARIA and actually make it easier for all users, even those that don’t really need ARIA.
I liked Eric Bailey’s article “ARIA is Spackle, Not Rebar” (opens in new window), that was writing about similar things years before me. Using HTML more and ARIA less, but learning more about both and how to test would be my summary of it, but please read it as well.
ARIA support should be documented by vendors
I love the Accessibility Support project (opens in new window) where I can easily find out about what works and what doesn’t work (well enough) in different screen-readers and other assistive technologies. We need to appreciate the manual testing that went into it. And that still needs to go into it. It’s a community project found on GitHub (opens in new window) where anybody can contribute. But that’s also the problem – it needs the community to follow up on different versions, test and document it and publish findings.
I really think it should be the vendors that will document what they support, where and how. I know that there are vendors that expose this info if we drill down in different sources, but if we want developers to have the information vendors should do better.
It would be amazing if we had Accessibility Support-like project where all assistive technology vendors would document their part on support. For example aria-errormessage support that would then include all screen-readers and totally up-to-date info if they support it or not, plans for when it will be supported and test documentation.
Then we could always know when we can use which ARIA and when not and I am sure it would make the web more accessible.
