Lessons in Accessibility: Part 2 – Keyboard Accessible
In part 1 of this series, we talked about some of the fundamentals of developing accessible web applications. In this part, I’d like to go into some more specific ways to develop with keyboard accessibility in mind.
For a non-visual user, a keyboard, especially a braille one, is a much easier way to access a website and their computer in general, than a mouse.
Using a mouse is a feasible option, but a non-visual user moving the mouse around the computer would be like a person waving around their hands in the dark. They would keep feeling around, hoping to find what they’re looking for, but can still easily miss many other details.
Because of this fact, keyboard accessibility is a fundamental part of developing an accessible website for non-visual users.
Tab Order is the order that page elements get focused on when pressing the tab key. It’s a top-down; left to right ordering of the elements on a page. This order is directly affected by how the HTML code is structured.
Let's have a look at this piece of HTML code:
<code> <div> <button style="float: right">First Element</button> <button style="float: left">Second Element</button> </div> </code>
Visually, the button “Second Element” will be on the left, and the “First Element” button will be on the right, giving the visual impression that the “Second Element” button comes first. But if a user were to use the tab key to navigate these buttons, they will notice that they will hit the “First Element” button before the “Second Element” button.
This fact is important, because it means non-visual keyboard users will not interpret the content in the same order as a visual user. They may encounter interactive elements before they are meant to be encountered.
It is good to keep in mind that CSS styling will be ignored by screen readers when it comes to the order of the elements.
Screen Reader Shortcut Keys
On top of the basic navigation controls, like tab and the cursor arrows, screen readers also have shortcut keys for users to help in navigating a web page. A common one is the “H” key to navigate through all the elements marked as a “heading” in the web page.
The shortcut keys can differ between the screen readers, but so long as the website is semantically correct, as the developer, you don’t have to worry too much about the different shortcut keys. We will go more into semantics in part 4 of our series.
What we do have to be concerned about, as developers, is implementing our own hotkeys in a web application.
Say we want the “H” key to do something in our web application. If a screen reader is on, it will take precedence over whatever we’ve programmed the “H” key to do. As mentioned before, it will scan through the “heading” elements, so pressing “H” will scan through the headers on our website, rather than whatever we may program it to do while on the website.
A perfect example is a code review web application I had used in the past. The only way to comment on some code was to press “C” on the keyboard. Unfortunately, the screen reader, NVDA, uses “C” to search for “Combo Box” elements, meaning, with NVDA on, it was impossible to make any comments in the code review web application.
Creating shortcut links
Short cut links can be extremely useful for non-visual keyboard users. They are links placed at the very top of a web page, hidden, but that can still be found by screen readers.
They are hidden with CSS styles, but once focused on, they appear, displaying what they link to on the site.
This image is the site normally.
From the browser’s address bar, when a user tabs in to the page itself, this appears.
A non-visual user can use these shortcut links to skip over content and go to a specific area of the page, like the main navigation, the main content, or the footer. It’s easier than having to tab or use the cursor arrows to navigate through all the elements, just to get to a particular section of the page.
Being placed at the top of the page means that these shortcut links will be the first elements that a non-visual keyboard user will encounter when navigating through the website.
This technique of hiding links or buttons until focused upon can be useful in other areas as well. It does not only have to be used for shortcut links at the top of the page.
Things to Consider in a Single Page Application
Keyboard navigation is a little tricky when it comes to single page applications.
Traditionally, when navigating websites, the page hits the server, downloads new HTML code and then loads it up in the browser. The focus then gets reset to the top of the page by default. Screen readers have been developed with this process in mind.
Now this action could be favorable, but it is something we need to be aware of when developing an accessible website. Users typically are not aware if a site is a single-page application or not. If every other website, that a non-visual keyboard user visits, moves the focus back to the top of the page every time a new page is loaded, that user’s expectation when navigating a single page application would be the same. We should ensure that the non-visual keyboard user is never lost or confused when navigating through a website.
We went through quite a bit here. As you can see, there is a lot to consider when developing with accessibility in mind.
In the next part of this blog series, Lessons in Accessibility: Part 3 – Tools to Help in Development, we will be looking at some programs and plug-ins used to help us out in creating a more accessible website.
We will also be going into a bit more details that the shortcut keys section touched on in a later post focusing on aria attributes and semantic tags.
If you’re curious about a potential solution with the issue raised when we talked about single page applications, that will be in another blog down the road, discussing focus management and announcements.