Accessibility Lipstick on a Usability Pig

Photo of a pigApplying 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

Meme: ARIA all the things!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.

Comments

  1. Mike Moore

    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.”

  2. Susan

    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”.

  3. The Usability People (@UsabilityPeople)

    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

  4. Denis Boudreau

    WebAIM, I think I love you.

  5. Kevin Prince

    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

  6. Dennis

    Excellent post. Thank you.

  7. Matt King

    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.

  8. David Sloan

    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.

  9. Michelangelo

    This post is gold. @MattKing: exactly! What is simply annoying for the “general user” becomes impossible for the adaptive technology user.

  10. Birkir Gunnarsson

    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.

  11. Jared Smith

    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.

  12. Graham Armfield

    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.

  13. steve faulkner

    But I’d still argue that it’s unnecessary accessibility lipstick that can simply be avoided by using a standard link or button.

    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….)

    First rule of ARIA
    If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour 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.
    Using ARIA in HTML

  14. Pam Taylor

    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. :)

  15. steve faulkner

    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.

    That’s because Dragon is currently broken. Refer to Short Note on ARIA, Dragon and Standards

  16. Sailesh Panchang

    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

  17. Birkir Gunnarsson

    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.