|
Most web designers have heard of usability. Few designers, however,
fully appreciate the difficulties faced by users as they attempt to
understand a website. In this article I will give a simple example,
discuss the connection with accessibility, and exhort you to perform
some real-life user testing (with real-life users, no less!).
A usability example: links
Usability
relies on convention. By violating conventions, you can damage
usability. For example, many websites remove the default underline on
links, perhaps reinstating it on hover; this makes links difficult to
find. Worse yet, some websites use underlining for headings or
emphasis; this frustrates users because they expect the underlined
items to be links.
Although you may be a daring and
unconventional person, it is a mistake to carry this persona into your
web design. By all means wear pyjamas and slippers to the pub, and
discourse provocatively on the hypocrisy of the West; but don't make a
"radical" website design. Your website is not primarily an expression
of your personality: it's a tool for your users.
The best way to ensure users can discover links is to stick to the convention:
- Links are always underlined.
- Unvisited links are blue.
- Visited links are purple.
- No other text is underlined, blue, or purple.
This won't suit the colour scheme of every website. Yet if you change the colours, you can still follow the other conventions:
- Links are always underlined and coloured.
- Visited
links are coloured with a duller version of the unvisited link colour
(bright red becomes dark red or faded pink, for example).
- No other text uses these colours, and no other text is underlined.
Failing
this, just stick as closely to convention as your design permits. For
example, if you can't find any good colours to distinguish visited
links from unvisited, then use some other effect to distinguish them,
such as a dotted underline on visited links. Although the most usable
option is to follow convention exactly, thoughtful deviations from convention will carry little penalty.
(These conventions are for links within the main text. Dedicated navigation bars may follow different conventions.)
How is usability connected to accessibility?
Intimately.
Usability
and accessibility are both disciplines whose central premise is to
design websites that the widest possible audience can use effectively.
Accessibility is a subset of usability: it's about making websites
usable for disabled people.
What is disability, anyway?
When
you think deeply about disability, you should realise that the world is
not divided neatly into disabled and non-disabled people. "Disability"
only has meaning relative to social norms, and not everyone whom you
perceive as disabled will identify himself as such; not all disabled
people wish to define themselves by their disability.
If
that seems like rarefied political correctness, think again. When you
reach middle-age, if you have not already, you will probably suffer
from deteriorating eyesight. But will you have a disability?
Objectively, yes: compared to someone in perfect health (whatever that
might be!), your eyesight will be inferior. Yet most people who wear
glasses don't call themselves "disabled".
Perhaps you think I'm just playing with definitions. Then consider Oscar Pistorius,
who is attempting to become the first amputee runner to compete in the
Olympic Games. Oscar's application is meeting resistance, because the
governing body has claimed he has an unfair advantage over
"able-bodied" runners. Oscar can run 100 metres in 10.91 seconds. I bet
you can't do that; so who is the disabled person? Oscar himself says:
"I don't see myself as disabled. There's nothing I can't do that
able-bodied athletes can do."
Accessibility = usability
This
is what I'm getting at: the difference between accessibility and
usability is like the difference between a partially sighted person
(disabled) and a middle-aged person who wears glasses (non-disabled).
It's a difference of emphasis, a difference of how you think, a
difference of how you perceive.
My friend Ellie, who
is blind, uses the screen-reader JAWS. She has it set to read sentences
at many times normal speaking speed; it's far too fast for me to
understand. Provided a website is well-designed for screen-readers,
Ellie can find information much faster than I can. I ask again: which
of us is disabled?
Given a sufficiently egalitarian understanding of disability, we can conclude that accessibility and usability are the same thing.
The word "accessibility" merely serves to remind you that you must make
a special effort to accommodate some users, such as blind people.
This requires a special effort because you are not blind yourself.
If you were a blind web designer, then accessibility would be turned on
its head: you would need to make a special effort to accommodate sighted
users. Blind web designers will have no difficulty making websites work
with screen-readers; but sighted users would suddenly feel disabled by
a web page devoid of familiar visual aids. The blind users would make
fools of the sighted, using screen-readers to jump around the page
faster than the eye can follow.
By failing to accommodate blind users in your web design, you create disability for them. If you accommodate them properly, they may out-perform sighted users. Stick that in your pipe and smoke it.
The surprising benefits of user testing
Caring about usability is a good start. Caring and thinking is even better. But to ensure excellent usability, there is no substitute for a real test. You may be surprised by the results.
Self-styled
usability guru Jakob Nielsen has been banging on about this for years.
Although Nielsen has a vested interest, and although he hardly makes
the most attractive poster boy for usability, he is actually correct. I
particularly recommend his article, "Why you only need to test with 5 users". To summarise his article:
- Test with a small group of users (say, five).
- Fix the problems they find.
- Then repeat the process.
A real example, with a real user (who has no added sugar)
Even testing with one user is worthwhile. Anyone will do, but not a web designer. I recently asked my dad to test my website; from this simple test, I discovered several usability problems.
When you perform user testing, you must:
- Listen to what your users say.
- Watch what your users do.
1. Listen to what your users say
My badminton website
has a preferences menu, which allows the user to: choose instructions
for left-handers or right-handers; choose a skill level (lower skill
means simpler instructions); and alter the visual style of the pages.
In the original menu, you could change the settings by clicking on
links.
My user told me that he found the menu
confusing. He expected the links to take him to another page, or at
least do something obvious; instead, most of them just quietly changed
a setting. He said that he thought they might be broken.
By
listening to what he said, I realised that my menu was
counter-intuitive. I changed those links to radio buttons instead. The
screenshots below show the changes: on the left, the original menu; on
the right, the new menu.
 
In
the new menu, you can clearly see the difference between links and
selection options. Radio buttons are apt here, because convention
dictates that they select a single option from a list. Users will not
expect a radio button to take them to a different page.
Notice that the radio button version is longer than the original,
because I have made all settings visible at once. This is a usability
improvement for two reasons:
- It removes ambiguity. In the original menu, does "low-glare
colours" mean "the current state is low-glare colours", or does it mean
"this link will activate low-glare colours"?
- It shows users a full list of their options.
I enclosed the radio <input>s and text within a <label>, like this:
<label for="skill1Label"><input id="skill1Label" name="skillRadio"
type="radio">Beginner</label>
Adding the <label> associates the radio button with the text;
this provides a much larger target, because the user can click the text
as well as the radio button. Including the "for" attribute should not
be necessary, but IE6 requires this explicit association. To help users
realise they can click the text, I styled the <label> with the
CSS { cursor: pointer }, replicating the cursor appearance of a link
(see the W3schools explanation of CSS cursors).
So far, so good; I'm feeling pleased with myself. But it's not over yet.
2. Watch what your users do
As my user explored the menu, he clicked on the "what does this do?" link (this was a real
link). This took him to the relevant section of my help page, so that
the content was immediately scrolled to the appropriate place. What
behaviour could be more benign?
Linking to internal page anchors (that is, linking to
somePage.html#someElementID) has the advantage of cutting straight to
the relevant information. Unfortunately, it also disorients users.
Because they don't see the top part of the page, they don't know where
they are. I knew this already, but I had judged that the disadvantage
was trivial.
Not so. I fidgeted in my chair, eager to take over, as my user painstakingly carried out the following process:
- He read the explanation, and seemed satisfied. Good.
- He scrolled down the page a bit, hesitantly.
- He scrolled back to where he started.
- He paused.
- He scrolled down again.
- He scrolled up to the top of the page. Only now does he realise his location.
- He hesitated even longer. His mouse pointer wandered uncertainly around the top area of the page.
- Ignoring the back button, and ignoring my large "Home" link, he found my breadcrumb navigation and clicked "Home".
At this point, you may be tempted to dismiss my user as an
idiot, or as hopeless with computers. That would be a gross error. This
particular user has an I.Q. of at least 140, and is highly
computer-savvy, having been personally responsible for the I.T.
infrastructure of one of the world's largest companies.
If this is how he behaves, God help the average user.
Perhaps
now you are beginning to understand how severe the challenge is. Web
designers are pathologically blind to the reality of user behaviour;
there is no substitute for watching a user. In this example, we've seen
how the apparently innocent act of jumping to an internal page anchor
can cause disorientation. Now it's time to make some excuses:
- "My user should have done ... instead; you see, it's really very simple."
- "You'll always get some users who don't understand. I'm sure most people would have no trouble with my design."
- "Okay, I recognise it's not perfect. But what else can I do?"
Indulge
yourself in the excuses; feel their comforting softness; and then
renounce them! The most reasonable excuse is the last one; but I never
said improving usability was easy.
To fix the problem, I place the help information where it's needed: on the same page. Although it's convenient for me
to link to my help page, it's not convenient for my users. In the
source code, this information appears directly after the menu; but I
hide it with CSS, and when the link is clicked I use absolute
positioning to make it appear alongside the menu, like so:
I've
also changed the colour of the help links, changed their underline from
solid to dotted, and applied the CSS { cursor: help }. The purpose of
this is to give visual clues that these are special pop-up help links;
I'm trying to make their behaviour less surprising.
Unfortunately
there are no clear conventions for this (unlike the radio buttons), so
it's not an ideal solution; but it's better than nothing. Solving
usability problems is not always trivial; there isn't always an
obvious, perfect solution. Even Nielsen, provocative merchant-king of
the field, admits he regularly makes usability errors.
Conclusions
User testing is the most effective way to improve usability. All
websites can benefit from this; you don't need many users, and you can
do it for free.
Listen to what your users say; it may provide useful insights. More
importantly, however, watch what your users do; because it is what
users do, not what they say, that gives you direct understanding of
their behaviour.
Since disabled people are users too, the same principles apply to
"accessibility testing"; it's just user testing under a different name.
If you're lucky enough to have a blind friend, ask him to test your
website; listen to what he says, and observe what he does (though you
might be unable to keep up with his screen-reader. That's your
disability; ask him for some assistance).
While you're recovering from the shock of user testing, take a
coffee break and wheel out the usual excuses. Wallow in them for a few
minutes. Reflect that users are the last people who should be allowed
near websites, since they are evidently incompetent.
Then wash out your coffee cup, take a deep breath, and go fix your website.
|
iEntry 10th Anniversary
Announcements
Contact
