Applying accessibility techniques to an unusable site is like putting lipstick on a pig. No matter how much you apply, it will always be a pig.
There are many ways in which a web site might be made inaccessible. Believe me, we’ve seen them all. Occasionally we are asked to conduct an accessibility evaluation on a site that is almost entirely unusable. Such efforts are usually pointless. No amount of technical accessibility can fix something that is not useful or usable.
Often the approach to poor usability is to throw more accessibility code at a site. Technical guidelines and solutions are used to attempt fixes for non-technical problems. The POUR principles are applied before considering usefulness and usability. And worse, poor usability is sometimes justified by declaring, “But it’s compliant!”
Types of accessibility lipstick commonly applied to usability pigs:
- Off-screen explanations or ARIA labels so a screen reader user might make sense of an overly complex form.
- Tabindex and keyboard interaction detection on <div> or <span> elements instead of using standard buttons or links.
- Custom widgets when native controls provide the same or sufficient functionality.
- Headers and id to markup a data table that is so complex a screen reader user is unlikely to ever comprehend it.
- Text-only or screen reader versions.
- In-page text resizing widget because a page does not support user-increased text sizes.
Usability First
Many accessibility techniques can be avoided by considering usability first. Does the site make sense? Is it easy to use? Is it presented in a logical manner? Are the interactions standard and intuitive? Is the content useful and clearly written? Does the design enhance or detract from the core content and functionality?
The answers to these questions affect both usability and accessibility for everyone, regardless of disability. When designed or restructured for optimal usability for everyone, accessibility then becomes much easier, and is often found to have been addressed entirely in the usability fixes.
The ARIA Hammer
As ARIA is increasing in popularity, it is quickly becoming the accessibility lipstick of choice. And some sites are smothered in it, yet beneath it all, they are still just pigs. While ARIA is a powerful tool for filling the accessibility gaps for screen reader users, if all you have is an ARIA hammer, everything starts to look like a nail.
Next time you are faced with a challenging accessibility problem, instead of immediately considering accessibility techniques, take a step back and consider the usability issues that are almost always an inherent part of accessibility issues. Perhaps by considering usability first, you may find that accessibility is naturally addressed and that things work better for everyone.
Great post. I don’t know how many times I have heard, “We know that there are a lot of usability problems, just tell us if it is compliant.” This is usually followed by “It is an expert interface” which apparently means “We could tell you how to use it but then we would have to kill you.”
Thank you. Often figuratively beat my head on the wall when I point out issues that affect all users and am told “we’ll just add ARIA”.
This is great article and we were proud to tweet it to our followers.
Just want to add the following comment — we often use Section 508 work as a “foot in the door” to doing more usability work. Many software vendors need VPATS but don’t understand what #a11y/usability is all about.
By explaining accessibility issues and creating disabled user personas to help them design and code their solutions to be more accessible, we are able to also help them understand several of their ‘other’ user profiles, e.g. novice users, intermediate users, and expert users–among others.
User-centered design can organically grow from the need to create a VPAT — hmm I think I new blog post was just inspired.
Anyway — keep up the great work you are doing
WebAIM, I think I love you.
Amen to that – The classic example of that is a site I was asked to look at by a blind friend – it was actually very accessible (in the code sense) but horrible to use sighted. That just compounded the accessibility issues. Throwing ARIA at it would’ve (and still hasn’t) made an iota of difference.
Brilliant blog
Excellent post. Thank you.
Massive agreement here!! I’ve made some good friends in our UCD teams by pulling the “required for accessibility” card out for usability issues. By calling an issue an accessibility requirement, we can wave the “legal mandate” wand. The people in UCD who identify usability defects don’t have that lever.
How does this work? It starts with noting the fundamental requirement of compliance that PwD must receive benefits and privileges equivalent to those provided to non-PwD. Very often, the negative impact of a general usability issue is orders of magnitude greater for PwD. So, for example if task completion rates are only 70% for non-PwD, they may likely be under 15% for some segment of the PwD population. Similarly, if time on task is twice the target for non-PwD, it is likely to be 5 or 10 times the target for PwD. To fix this disparity usually requires addressing the fundamental design flaws.
If you do not have actual data, it is often easy to arrive at reasonable expected outcomes using heuristics.
We had a terrific example of this at a presentation we gave yesterday to the Cambridge Usability Group, where we introduced an example of a page component containing accessibility issues relating to quality of alternative text and tab focus order.
The discussions around how these accessibility issues could be addressed soon revealed wider questions on the function and intended user experience of this particular page component – and the usability limitations it had. Thinking about accessibility soon moved to thinking about task completion and goal achievement, and how best to design a way to achieve that for everyone.
This post is gold. @MattKing: exactly! What is simply annoying for the “general user” becomes impossible for the adaptive technology user.
That last comment was very insightful. 😉
I am tempted to put the first sentence of that article as my GMail signature.
I still wonder why divs or spans with tabindex=”0″ and the necessary Javascript and ARIA are so absolutely bad for keyboard access / usability.
Yes, they are not a smart choice of UI (I believe the argument that styling a button element is much more difficult no longer holds), but if the developers want to go through applying tabindex=0, supporting enter and spacebar activation and mapping the element as a button with ARIA, how less usable is it to the actual end user than a normal button? (to screen readers it doesn’t matter).
I am just curious, not making a grand claim. I am certainly in fist-pumping agreement with the article.
Birkir-
You are correct. With the necessary markup and scripting and ARIA, divs and spans will be presented as accessible links or buttons to screen reader users, and they may be presented visually as such. But I’d still argue that it’s unnecessary accessibility lipstick that can simply be avoided by using a standard link or button.
This is a fantastic post. I feel the emotion and frustration in your typing.
Simple is always the best way in my view – anything else and you just start to leave some people behind, even if you then spend time creating extra help to explain the complex bits.
We can argue all we like, it’s developers who are creating the need to add ARIA, unfortunately ‘just say no’ does not work in majority of cases. (say hello to web components….)
Accessibility does not just mean for people with vision issues, it applies to people with all kinds of mobility impairments as well as other disabilities. One very important reason to never apply ‘false’ roles to elements that do not natively receive keyboard focus is that they won’t be recognized by Dragon by these roles. You can call a span a button with ARIA ’til the cows come home, Dragon will never see it as a button. Ever. Dragon recognizes HTML elements by their HTML tags, not their attributes. And, not all screen readers are alike. JAWS may recognize most ARIA roles, but NVDA is not as reliable.
I have to agree with Steve Faulkner, the use of ARIA is developer driven, not accessibility driven. Why take a cat and try to teach it to bark when you have a perfectly behaved dog sitting right there that you can use? Not to mix too many metaphors. 🙂
That’s because Dragon is currently broken. Refer to Short Note on ARIA, Dragon and Standards
I liked “While ARIA is a powerful tool for filling the accessibility gaps for screen reader users, if all you have is an ARIA hammer, everything starts to look like a nail.”
Also see
http://www.deque.com/wai-aria-opinion
===
Sailesh
Thanks guys.
I am never advocating using the ARIA hammer when not necessary, and the blog is awesome.
But I do hope that Dragon will start supporting ARIA, now that it is an official spec and all.