An article I wrote on keyboard accessibility was published at Practical eCommerce magazine this morning. The topic is keyboard accessibility – what constitutes keyboard accessibility and how crucial it is for users who are blind, low-vision, or have mobility impairments.
Which brings to mind the question: is there really such a thing as a fully keyboard-dependent user?
This is a question that gets asked in accessibility communities occasionally. Most uses who are unable to use a standard mouse can still use specialized pointing devices such as a trackball, joystick, track pad, switch interface, or a voiced touch screen, to name a few possibilities. How often will it come up that a user is actually dependent solely on the keyboard?
I think that’s a misleading question.
It truly doesn’t matter whether there is such thing as a user who can only navigate a web site using a keyboard – what matters is whether or not a user may need to navigate any given portion of a web site solely using the keyboard – and that’s a context question. When focus is currently on one item, and you need to move to the next focusable point in the same set, moving via keyboard may still be the easiest option – and it should work. If any one part of the web site does not support the keyboard, then that experience will be broken. The user may still be able to use the site, because of their alternative pointing device, but that does not justify requiring an unnecessary change of device context or lack of clarity because the keyboard wasn’t considered.
It’s a dangerous thought to consider that the failure to identify a keyboard-only, sighted user means that any part of a site can be exempted from keyboard accessibility. It’s a thought that seems to be derived from actual users, but doesn’t consider creating an optimal experience to be a priority; only ensuring that things are possible.
It’s also worth pointing out that even if a user has an alternative pointing device, it’s worth addressing the fact that any external device can break. If your pointing device breaks, the keyboard should still be a viable option.
Situational or temporary accessibility problems are still problems, and should be considered of equal importance to any permanent problem.
Joe Dolson; June 1, 2018 at 12:47 pm
The point of making all elements accessible via the tab key is not so that people can walk through the entire site using the tab key. It’s so that they can navigate to a location using whatever method they prefer, but have the option to get to the next point using the tab key, which may be the most convenient option at that point. That does, however, require that it be possible to walk through the entire site using only basic keystrokes.
And there are many people who are severely limited in mobility to the degree that multiple-key combinations are actually very difficult to engage. In these cases, simple keystrokes may be a necessity.
BlackCap; June 1, 2018 at 10:15 am
I am a keyboard only user, not for accessibility- but for efficiency and comfort reasons. However, I don’t think I have ever used a websites built in keybindings!
You could have the best keyboard integration in the world, but it cannot possibly beat my own tooling, because I have tweaked that over years to make it just perfect for me. I know exactly how it works, and I know that it will work reliably across the entire internet. I don’t care what you thought was a good idea for one particular page.
Furthermore, to most people, keyboard integration on a website means the ability to reach all clickable elements by spamming tab repeatedly; that’s a joke. Nobody is going to scroll trough every element on your site until they get to number 300 or whatever they actually wanted. Nobody does that.
Joe Dolson; April 2, 2016 at 9:38 am
To me, this is the key element: “based on a user’s circumstance when they are navigating.” We can’t presume to know in advance what the circumstances are in a given user interaction – and any option available should work predictably and consistently.
David MacDonald; April 1, 2016 at 9:49 am
One very good thing that I’m seeing coming out of this discussion for the first time ever, is the acknowledgement that the case for keyboard only navigation is not based on a mythical user, that the industry has been talking about for 20 years, but rather on a requirement for a flexible interface that can be used with a mouse OR keyboard based on a user’s circumstance when they are navigating.
As a lifetime assistive technology user who depends on AT every day, I understand how important it is to have flexibility based on the situation. I also think it’s important that we get honest about how end users are using the computer.
If in some way I’ve moved the discussion forward by asking a provocative question, and getting us all to acknowledge the truth about end user’s requirements, then my job has been successful. The original article is here, it has been updated as information came in, and will continue to provide any new evidence of computer use:
Debra Kyles; March 31, 2016 at 1:35 pm
Excellent article. I’ve been working with a developer on keyboard accessibility, and he was asking this same question – how many people use a keyboard? I totally agree with you – it should be available to the keyboard user, even if other options are available. Well stated.
Joe Dolson; March 31, 2016 at 9:41 am
I won’t deny that it was a bit of a deceptive headline… 🙂
Amanda Rush; March 31, 2016 at 8:40 am
When I read this headline, my first thought was, “He’s been talking to David MacDonald.” so I’m glad to see your position on this is actually that whether the mythical unicorn of the truly not-VI keyboard user can be proven to not be myth, but fact, doesn’t actually matter.
Jeanne Spellman; March 30, 2016 at 4:46 pm
I am concerned at this idea that there are no sighted keyboard-only users. I personally know 3 where we have discussed the challenges. I probably know more keyboard-only users, but I don’t usually stare at how friends/colleagues use their mouse — or not. I appreciate that your article focuses on the need and not the size of the user community.