Is the classic persona of the
sighted keyboard-only user
too coarse and simplistic?
People who are blind need full keyboard access. Period. There are many people who are sighted who also need keyboard access. However, my proposition is that our 30 year old model of a sighted keyboard-only user is coarse and simplistic, and needs refinement regarding who we are actually trying to help and how. This is important because people with episodic disabilities are neglected in our coarse characterization of the sighted keyboard-only user. I hope we can begin to raise the profile of people with episodic disability, which is not well understood and not well accommodated in law and policy.
There is no recommendation here to reduce current accessibility requirements for visible focus or keyboard accessibility. Users need Keyboard AND Mouse. This is simply a proposal to change our narrative.
This discussion is to help those who create personas of sighted people who need keyboard access and to understand why they need it. The discussion is intended for those who are:
- Involved with disability accommodation research
- Those developing personas, which may include sighted keyboard-only users
- Accessibility professionals writing reports where they mention keyboard-only users
- Accessibility professionals writing standards, such as WCAG.NEXT
- People new to accessibility who are interested in learning about end users
I'm an assistive technology user
There was such a strong reaction to the original version of this article, that I feel a need to say I use assistive technology every day. I had 5 surgeries on arms/hands, and wrote a feature piece in Abilities magazine in 1999 about a zero force keyboard I eventually patented. I got through university by using a mouse with my feet.
I owe it to Mark Novak (currently at the Paciello Group) and Gregg Vanderheiden, who created SerialKeys for Windows and coached me to write GUIDI code keyboard emulation using my zero force keyboard. That's how I got into this industry in the 90's. When I first had arm trouble the web was in its infancy.
Although I've had much improvement over the years, I still use a zero force keyboard and click the mouse with my feet every day. That's why my typing is so full of errors when taking minutes for the WCAG group (sigh!). Assistive technology has enabled me to become a productive and reasonably successful accessibility professional.
Most accessibility professionals these days are front end web masters who converted to accessibility
Most web accessibility professionals are former webmasters who converted to accessibility. That is good for web accessibility but it carries with it a perspective and some limitations. They may have learned about blindness, low vision, and a bit about cognition and have some knowledge of JAWS, NVDA, VoiceOver, Zoomtext, and a bit of Dragon. It usually stops there.
They know little about the weird and wonderful world of keyboard emulation, head wands, GUIDI Codes, Alternative and Augmentative Communication (AAC), switch access, scanning, ergonomics, and episodic disability. Many don't realize that the keyboard can emulate a mouse, and mouse emulation is common within many of these user groups.
No examples of a sighted keyboard *only* user?
In 20 years of direct accommodations of people with disabilities (hundreds of accommodations in banks, government, etc.) I've never met a sighted person who exclusively uses key bindings on keyboard because of disability. Many use an alternative pointing device or MouseKeys to emulate mouse activity. Some use the mouse (or alternative) intermittently depending on the task or pain level etc,.
I wondered if perhaps I was just unlucky in not meeting such a user. I took my question to Twitter, the IAAP user group, and a CSUN live session to see if others had a similar experience of never meeting this user. After filtering out all the noise of those scandalized by such a question, here's a summary of the 50 responses from long time accessibility pros:
- Many examples of users who predominantly use keyboard, who find it hard to use a mouse (or alternative) because of pain or disability, but use it occasionally as a regular part of their work flow, when an action is easier with mouse (or alternative) even when a keyboard solution has been implemented. I've met many users like this also.
- Many users who use keyboard because it's more efficient, but are not limited by a disability. These usually are programmer types.
- Several users who often emulate the keyboard in Dragon Naturally Speaking.
- Many users who use a head wand, who only press keys with it, but these keys include MouseKeys which emulate mouse.
- No examples (so far) of a sighted user who does not use a mouse or pointing alternative at all (brick wall) because it of disability. The cumulative experience of those responding was about 400 years, literally.
So who needs a Keyboard?
User 1: Pain is a disability
A piece of the puzzle that might blur the line between a predominant keyboard user and a keyboard-only users is "pain". One responder argued that if someone is in pain and are forcing themselves to use a mouse because a site is not keyboard accessible, they are not a predominant keyboard user, they are a keyboard-only user who is forced to use a mouse because of the inaccessible interface.
Many Repetitive Strain Injury (RSI) clients I've accommodated experience pain when using a mouse (or alternative). However, these clients find some actions more painful on a keyboard than on a mouse (or alternative), depending on the number of steps, the key combinations required etc., even when the interface is "keyboard accessible". They may have an episodic disability. Sometimes they are more comfortable on a keyboard, sometimes a mouse. For these users, it is important to have the option of keyboard OR mouse, depending on the day or the circumstance.
There are a several types of assistive technologies that emulate keyboard, such as speech recognition and scanning software.
User 2: Speech Recognition
I've trained a number of users on Dragon Naturally Speaking. Dragon emulates keyboard with much of it's navigation actions and commands, with the user saying things like "press [key]". One Dragon client had trouble seeing the focus ring as she dictated "press tab, press tab". The focus ring was visible (Passed 2.4.7) but was highlighted poorly, so she had trouble tracking it. This is a great reason to strengthen the requirements for a visible focus ring in WCAG 2.4.7, so that it is more visible. Dragon also allows the user to do mouse actions with a command called "mouse grid" which is a pain to use because it takes about 3-6 iterative steps to position the mouse to hover over any target on the screen. So they need keyboard access.
User 3: Switch Access Scanning
Some users with physical or communication disabilities use Switch Access Scanning software which moves from item to item on the screen, and a switch can be activated when the desired item is in focus. The most famous user is Stephen Hawking. Most of this type of use happens within a communication program designed for switch access use. In advanced users, switches might be assigned to macros which perform a number of functions. If the macro emulates a keyboard stroke and the component is not keyboard accessible, it could cause an error. I know of no documented cases of a switch access scanning software user having a barrier based on an interface component not being keyboard accessible. This may be because emulation can be assigned to both mouse activity and keyboard activity.
These users need access to keyboard AND mouse emulation.
User 4: Head Wand Use
People with Cerebral Palsy and other dexterity disabilities often use a low tech device called a head wand or head pointer, which fits over their head and lets them use their heads to select keys. One responder who is an accessibility professional sent me this link as an example of a keyboard only user.
A careful look at her actions shows her activating keys on the number pad. This is MouseKeys which emulates a mouse. It used the arrow keys on the number pad to move the mouse, up down, left right and the 5 key to left click and enter key to right click. Head wand users are often mistaken as keyboard-only users. These users rely heavily on MouseKeys.
Nevertheless, these users need keyboard access, because flexibility is crucial, when using a head wand.
User 5: One armed use
Some users only can use one arm and find it sluggish to go back and forth to a mouse. However, they have a mouse (or alternative) handy and use it when there are many steps, or awkward key combinations to perform an action. This appears to be true whether or not they have a special one handed keyboard. These users need keyboard access because again, flexibility is key.
User 6: Mobile
Mobile manufacturers have been sloppy about allowing functionality by (Bluetooth) keyboard. A user can type words and do data entry with a keyboard, but they cannot navigate well around the OS with a keyboard. This problem also has speech dictation users complaining. Many functions can't be accomplished with voice alone. This is an area of growth for these manufacturers like Google and Apple. Yet at the end of the day, scanning, voice and touch on a mobile device are an array of strategies applied by users. There are no "keyboard-only" mobile users that this exercise has revealed. That doesn't mean the manufacturers should let up on advancing their support of keyboard and voice. Everything should be able to be done with both keyboard and voice.
Isn't it obvious that keyboard only users also sometimes use a mouse?
I received this tweet.
The photo makes fun of the general public's ignorance that some people who use wheelchairs can stand and some people with a cane can see a certain amount. The tweeter was trying to say that just because some keyboard-only users can use a mouse doesn't mean they aren't keyboard-only users.
Accessibility professionals are well aware of these misconceptions about wheelchairs and canes, and we quite often discuss them. Yet when it comes to the keyboard-only user who is sighted, there is a significant ignorance about the fact that they use a mouse (or alternative) every day, and any mention of it, seems to light up the twitter world with rhetoric.
I think it is important that we understand that some wheelchair users cannot get up, and some cane users can't see at all. However, unlike canes and wheelchairs, I have yet to meet a sighted keyboard user who has a brick wall barrier to using a mouse (or alternative) like those users of wheelchairs and canes. So far, I have not heard of one, from any colleague, even when publicly asking the question and in the midst of shrill responses. In other words, applying the example above to sighted keyboard users, I've never met a user who could not stand up to get the alcohol bottle from the top shelf.
This is the most realistic keyboard user. Those who can't use a mouse much. They need a keyboard most of the time, but occasionally reach for the mouse, much like this user in the photo above stands up to reach for a bottle.
Why does it matter?
Some of the most surprising responses I got was, "how many angels dance on the end of a pin", "Why does it matter", "who cares"? It matters because:
- We owe it to people with episodic disabilities, who have little provisions in law or policy to protect them, because one day they are OK, the next day they aren't, and employers don't understand that. We need to make their voices heard, and describe their use cases, rather than making up a mythical "keyboard-only user".
- We need to better understand other disabilities besides blindness and low vision, and the types of technologies they use.
- We owe it to our clients to tell the truth about the types of barriers people face.
Conclusion: Should we consider more granular and more accurate terms?
When creating personas, and when failing a web page on WCAG Success Criteria 2.4.7 Focus Visible, most accessibility professionals write something like "sighted keyboard only users need... ". I expect, after these results, the personas I use will be different. I will describe these users with phrases such as:
- Those who predominantly use keyboard because limited motion, which interferes with mouse/pointer manipulation
- People with episodic disabilities and pain related disabilities who find extended mouse activities painful.
- Those who have software that emulates the keyboard as part of its function. (speech recognition, scanning, macros, etc. )
- Those who are in situations where it's hard to get to a mouse.
We need to shift the discussion from "the sighted keyboard-only user needs..." to new language which realistically describes what is happening with end users.
A web developer cannot predict when a user finds it more difficult to use a mouse or keyboard, so ...
ALL interaction must be accessible to users of keyboard AND pointer events (mouse/pointer/touch).
Keyboard function is required by WCAG and should continue to be required in future versions of WCAG. However, I think the classic persona and use case for a keyboard-only user should be revised to more accurately describe what is happening with real users.
This exercise has reduced my cognitive dissonance when writing about end users that neither I, nor other accessibility professionals, have met.
I think it is important to challenge assumptions about end users and seek to learn as much as possible about the real barriers that people on the web are facing rather than relying on academic models which have been floating around unchallenged for decades. This will help us write better standards and educate the public more honestly and effectively.
Feel free to comment on Twitter @davidmacd
David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.
For a quote or just to chat about your organization's needs