There are several groups of people who do not use a mouse or pointing device to interact with Web pages. A few examples:
- Mobility impaired people who cannot use a mouse at all
- People with motor impairments who can use a mouse but lack fine motor control
- Screen reader users who do not use a mouse, or even a monitor
- People using mobile phones
- Laptop users, since most laptops have really bad trackpads or other means of positioning the cursor (ever tried using a hierarchical dropdown menu with a trackpad while riding on a train?)
- Speed typers who have learned to use keyboard navigation efficiently and are slowed down when they have to switch to their mouse (if they have one)
As you can see there are reasons that affect people with disabilities, and others that affect everybody. So when developing a user interface you have to make sure that it does not depend on a particular input device. See also WCAG 1.0 Guideline 9. Design for device-independence.
The most common problems I see are drag-and-drop functionality and
onclick event handlers added to arbitrary elements. For drag-and-drop, you need to give users an alternative way of interacting. How to do that is up to you and is not something I am going to go into here.
onclick event handlers, the solution is simple. Always use an
a element with a value assigned to its
href attribute. In some cases a form control is a better choice, but I’ll use links here.
Doing so makes the functionality accessible to keyboard users and other people who do not use a mouse. And yes, you really need to consider those users. I was very surprised to see several people argue against supporting non-mouse users in Jonathan Snook’s SnookSurvey #2: To Link or Not?. I don’t buy any of their arguments, which mostly seem based on a misunderstanding of the problem.
I’ll illustrate the
onclick case with a couple of code examples consisting of a list of terms and definitions, where the definitions are hidden until the user clicks on a term. The examples use inline event handlers,
style attributes, and excessive
class attributes for clarity – do not use this code.
The wrong way
Here is how to do this the inaccessible way:
<dl class="faq"> <dt onclick="showDefinition('def1')">Term 1</dt> <dd class="def1" style="display:none">Definition 1</dd> <dt onclick="showDefinition('def2')">Term 2</dt> <dd class="def2" style="display:none">Definition 2a</dd> <dd class="def2" style="display:none">Definition 2b</dd> </dl>
dd elements are hidden when the page loads (if CSS is enabled). When the user clicks on a
dt element, the
showDefinition() function changes the
display property for the corresponding
dd elements, making them visible. You could also use CSS to change the
cursor property when the user places the cursor on top of the
This works fine for people who use a mouse. But what if you don’t? When you tab through the page, focus is placed on links and form controls, allowing you to interact with them. But focus is not placed on other elements, even if they have an event handler assigned to them. Because of that, it is impossible for non-mouse users to interact with the page. Bad, bad, bad.
The better way
onclick event. With that in mind, here is the markup that is keyboard friendly (again, inline stuff to show what I mean—imagine the links and event handlers having been inserted by a script):
<dl class="faq"> <dt><a href="#" onclick="showDefinition('def1')">Term 1</a></dt> <dd class="def1" style="display:none">Definition 1</dd> <dt><a href="#" onclick="showDefinition('def2')">Term 2</a></dt> <dd class="def2" style="display:none">Definition 2a</dd> <dd class="def2" style="display:none">Definition 2b</dd> </dl>
href attribute. The links only trigger the
There are usability issues to keep in mind with any approach that deviates from the normal behaviour of web pages, but I’m not going into that here. The purpose of this article is to show that you must not make website interaction depend on a certain input device, and that there is an easy way to make sure everybody can use your interface.
Update: I realise that I didn’t stress enough that my examples aren’t complete. The links in the second example would not be in the raw markup but inserted by a script, as I mention in the paragraph following the code listing.
- Previous post: Introduction to screen readers and screen magnifiers
- Next post: Understanding and extending semantics in HTML