The Usability Principles, Accessibility Style: Part 3

So much for my plan of posting these in consecutive weeks. Ah well, blogging isn’t as easy as it looks.

Anyway, let’s wrap up our journey through the classic 10 Usability Principles.

All blockquotes are from the Ten Usability Heuristics.

7. Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

In creating a good experience, you shouldn’t cater only to the newbies. Find ways to provide shortcuts for experienced users, so that they don’t have to go through unnecessary steps every time they try to do something they routinely are coming back to do.

A classic example is providing shortcuts, such as key commands. New users to computers may go to the File menu and click “Copy”, then go back to click “Paste”. Crusty old vets like us use Command (or Control) C and Command (or Control) V.

Example of selecting Copy and Paste from the File menu, along with their keyboard shortcuts

The Accessibility Slant
Screen readers provide ways for blind users to jump around a web page instead of having to hear every single word, including from ever-present elements like navigation. Properly-coded sites make it easy to hop from heading to heading.

We’ve talked before about adding skip navigation functionality to web sites, to achieve similar shortcuts around tedious repetition. That’s what that “Skip to Content” link at the top of this blog is for. A blind user doesn’t have to hear things the navigation and everything up in the header over and over and over — they can skip it and get to the good stuff.


8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Keep things simple and straightforward. Much like a good writer eliminates unnecessary words to build a concise, impactful piece of work, you should ask yourself with every element you put on a web site or in an application, “Is this really necessary?”

Boil it down to the most critical information. Anything else is probably just noise.

The Accessibility Slant

First off, once again, people are just trying to get information or complete tasks as easily and quickly as possible. If you go crazy with unnecessary words, links, images, etcetera, someone with a screen reader has to trudge through all of that. All of us do!

Now imagine someone with cognitive limitations, or even just a short attention span. If the experience ambles and rambles, they may lose interest, become frustrated, and just plain leave.


9. Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Like I said in the last post, it’s best to come up with ways to minimize errors entirely. But they are going to happen. When they do, make sure the messages that the user sees make sense. “Error 23423432 – System Failed to Execute” is useless. What happened? What did I do wrong? How do I fix it?

Tell the user what’s going on in normal user language, not system garble.

The Accessibility Slant
Some of these are just too easy to draw a direct accessibility connection to. We’ve talked a lot about people with cognitive disabilities. Don’t make it a struggle for a user to figure out why their actions failed. Frustration and failure will send people away, disabilities or not.


10. Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Good user experiences indeed minimize the need to read tomes or hunt through help systems…or, God forbid, frequently asked questions. But sometimes they just have to be provided. If they are, they need to follow all of these tenets. In particular– easy to get through, easy to find what you’re looking for, concise and direct.

The Accessibility Slant
Whether a sighted person is looking at the words or a sightless one is hearing them, clutter and confusion are nothing but obstacles. A person going the help section of an application or web site is having a problem, possibly is frustrated, and just wants to get back on track. Make that as easy as possible. Short, sweet, and easily searchable is key.

If you’re using video for tutorials, remember that not every user can hear. Provide subtitles and/or transcripts so that they get the answers they need too.


There you have it. We’ve gone through all 10. Hopefully it’s obvious that every one of these makes natural sense to good accessibility. People with and without disabilities have many of the same common needs when navigating through a web site or application. Barriers of any kind slow them down, stop them entirely, and overall create a less-than-enjoyable user experience.

Following these 10 tenets require a little diligence, but they aren’t overly complex. It’s common sense really, which is why they are timeless.


The Usability Principles Series:
Part 1
Part 2
Part 3

2 thoughts on “The Usability Principles, Accessibility Style: Part 3

  1. Pingback: The 10 Usability Principles and Accessibility – Part 3 | the art of web accessibility | UXWeb.info

  2. Pingback: Website Design | The Usability Principles, Accessibility Style

Leave a Reply

Your email address will not be published. Required fields are marked *