One major tenet of web accessibility is that users have various strategies to operate your website. While still too many web developers aren't able to name input modes beyond pointer devices (mouse and touch), properly covering keyboard accessibility will get you the most bang for your buck. If you ensure that all the features of your site can be operated with a defined collection of keys (tab key, space bar, enter key, arrow keys, etc) you largely increased the likelihood that people with all kinds of strategies and assistive technologies are able to use the site you built.
Rock'n'Scroll
"Navigating a website" can, of course, mean jumping from interactive control to interactive control but most forms of interactions come down to reading or passively experiencing your content. A central way to do that is of course scrolling. It's obvious that mouse owners can use the scrollbar or a particular mouse wheel and touch users drag the site up or down. But I think the strategy keyboard-only users employ for scrolling is known far beyond this user group: using your keyboard's arrow keys (or is it just me, especially when reading long texts on the Desktop?).
Anyway, arrow keys scroll the overall website, regardless of the focus's precise position, and sometimes, this is all you need. But what about particular containers that harbour content that is either horizontally or vertically too large for its parent? It is allowed to overflow, more often than not with the CSS overflow: auto. Alas, the situation around keyboard accessibility of these containers is patchy, and I only completly realized this after a current customer project which had an overflowing container. So, what follows is my little research on the topic and the current state of overflow scrolling afairs (see original sources at the bottom of the article).
Overflow and Focus
Firefox, for example, puts an overflowing container into the tab order, making it reachable and its content scrollable. Because it has no focus styles, it is not really obvious that it has focus, though, but web developers can at least write a CSS selector like .my-overflowing-div:focus to make its state more clear to friends of the Mozilla. However, the situation in Chrome, Chrome-based Edge and Safari is different. Without any changes in the HTML, overflowing content is not scrollable with the keyboard (unless, of course, there is an interactive element inside the container - but this scrolling doesn't uncover every part of the container).
All interactive should be focusable
(Using WAI-ARIA)
Ensuring a coherent experience across browsers
The Webkit and Blink team are aware of this topic insofar that issues related to that exist for 3 or 5 years, respectively (Webkit Issue # 585413 and Chrome's one even is on "Intent to ship" since 2.5 years). Unfortunately, there is nothing tangible beside the tickets, so web developers must apply a hack if they want to convey Firefox's behaviour to all browsers. This workaround, or "hack" as Adrian Roselli calls it, comes from Steve Faulkner and consists of three steps:
- Add
tabindex="0"to the overflowing container to make it baseline keyboard accessible. - Show this keyboard accessibility to users by applying custom focus styles:
.my-owerflowing-div:focus { outline: 2px solid; }(if you want to be both future-proof when it comes to WCAG and an overall good web author citizen, take care of focus style contrasts). - "Promote" the
<div>to a landmark region by both applyingrole="region"and supplying an accessible name, by usingaria-label, for example. By doing so, you provide much-needed context to screen reader users - because they suddenly discover a focussable element that is not interactive in the classic sense (like a link or button would be).
Demos and Links
- Steve Faulkner provided the code mentioned above combined into a CodePen
- More than five years ago, he published Short note on improving usability of scrollable regions
- As for every web accessibility topic, Adrian Roselli has a deep dive article: Keyboard and Overflow
Top comments (0)