In the beginning, there was only the command line.
Xerox and Apple brought us a graphical user interface (GUI)and the mouse. A small handheld tool to help you move across the GUI and interact with the objects on it. But we still had the keyboard. As time wore on, people forgot about the keyboard more and more.
Why do we need to make our projects usable with a keyboard?
Not everyone uses a mouse. Not everyone has access to the mouse. If it can be done with a normal keyboard, it will likely work with eye-tracking. It will also work with sip-n-puff, switch, and more alternative hardware. This opens up the opportunity to grow your audience.
How do we make our sites keyboard friendly?
Like I’ve said, and many before me, start with semantic HTML. Why? Well when we use HTML the correct way, things like buttons, links, and inputs give us keyboard control for free. They also handle mouse clicks with no issue. Using semantic HTML, we reduce the reliance on JavaScript to do everything.
There will be times when you cannot use semantic HTML due to the site’s construction. When this occurs, always make a note to refactor when allowed. Then use ARIA to fill out the other required control properties.
Something to understand about assistive technology, most of it doesn’t interfere with input. Screen readers do. Screen readers have two primary modes of use, virtual browser and forms modes. There are more, but these two cover most use cases for the web.
Virtual Browser
In virtual browser mode, the screen reader intercepts all keyboard input and will respond based on that. This means if I am on a button and press enter, the screen reader will absorb it. It translates it into a mouse click. People without screen readers running do not get this.
Forms Mode
Using a keyboard only is actually more akin to the forms mode of your screen reader. Here, the screen reader announces what is on screen, but it allows all keystrokes through to the page. That same button I was on, now will actually get the keypress event with a keycode to match Enter. If you have only been listening to “click” events, your button will now fail to fire. The same happens if you turn off the screen reader.
This is a clear indication that you missed an event listener.
Whenever your design requires adding mouse functionality with JavaScript, do more than listening for “click.” You should also look for “keyup.” Ensure any function set to the click event functions when the user releases the related key. In most cases, this key is Enter.
If you are testing with the screen reader on, make sure to try changing modes first. It might not work otherwise. Using the AT’s hotkey (Insert or Capslock on NVDA) and Spacebar, you can switch modes.