Keyboard-Only Scrolling Areas

I have spent a few years banging on about ensuring scrolling areas on a page are accessible to keyboard-only users. This is partly because the term “keyboard” maps to other input types that we distill to “keyboard” for ease of reference (speech input, sip-and-puff, on-screen keyboards, scanning software, etc.). When something cannot be operated with the keyboard, a whole bunch of users are blocked.

The most common technique to make a scrolling area work for keyboards is to give it a tabindex. Once it has focus, arrow keys can scroll up and down, left and right. This accounts for scrolling areas with no interactive controls to take focus from a Tab, or when arrowing through those controls also sets their value (radio buttons, select menus) or triggers an action (broken radio buttons or select menus).

Once this otherwise generic area can accept focus, however, we have to address how that impacts screen reader users. It must have an accessible name so a screen reader can announce it. To have an accessible name, it must also have an appropriate role, which also brings along any interaction instructions (I use region since it is a generic landmark).

Remember many areas do not scroll until something happens. Viewport changes, dynamic content, or other actions can cause content areas to change size on the fly and then generate scrollbars.

This all means screen reader users get a verbose interface as we work to support keyboard-only users, even when that area does not yet scroll.

Solutions for Users

As a keyboard user, the good news is that you can make use of scrolling areas without a tabindex, role, and accessible name strapped onto every instance. Here are three methods.

Switch to Firefox

Firefox treats scrolling areas as tab-stops by default (and has done so since at least 2011 and Firefox 4). This means you can tab to it and then use the arrow keys to scroll.

This feature was requested and supposedly added in Chromium in 2018, but disabled a week later, and continues to be an open issue. In other words, it is not coming soon. I could find no feature in development or related bug for Safari.

This video shows how Firefox experiences a scrolling area of the page:

At 0:03 I put focus on the scrolling area by tabbing to it, then I use the arrow keys to scroll left and right.

Activate Caret Browsing in Chrome, Edge, or Firefox

Each of Chrome, Edge, and Firefox let you navigate a web page with a text cursor (caret). You can arrow your way through a page, into a scrolling area, and then use the arrow keys to make it scroll.

To better spot scrolling areas on Windows 10, head to StartSettingsEase of AccessDisplayAutomatically hide scroll bars in Windows and set it to “Off”. In Windows 11, use StartSettingsAccessibilityVisual EffectsAlways show scrollbars and set it to “On”.

To try caret browsing, press F7 in your browser and start arrowing.

There are some things to note:

This video shows Edge on Windows using the text cursor with text cursor accessibility settings in use:

I spend the first two seconds trying to tab to the scrolling area with no luck. At 0:04 I type in the text box so you can see the text cursor indicator with its big purple ends. At 0:09 I press F7 to activate caret browsing and spend the rest of the video using arrow keys to move the text cursor. Notice how the down arrow moves within and then among cells, and notice how the entire cell does not scroll into view just because the text cursor is in it (evident at 0:32).

For some context, here is the text cursor in Windows 11 with a more obvious indicator and a thicker line. Note how the caret browsing cursor looks nothing like it, retaining its single-pixel-thick line instead.

A text cursor in a string of text; it has a purple bell on the top and bottom and is the width of a letter, with an inverted letter showing through the bar.

Safari: Use Mouse Keys

If you are on macOS and using Firefox, you can still tab to a scrolling area. If you are using Chrome, Edge, or Firefox, you can use caret browsing. But if you are using Safari, you have to rely on macOS itself to emulate a mouse (Full Keyboard Access is no use here).

First you must enable Mouse Keys. Then you can use your keyboard or the number pad to move the mouse pointer into position over the scrolling area. Then use your keyboard or the number pad to simulate a mouse click, essentially giving the scrolling area virtual focus. From there you can use the arrow keys to scroll the area itself.

To better spot scrolling areas on macOS, you may want to go into System Preferences → General → Show Scroll Bars and set it to “Always”.

If you are a mobility-impaired user, there are other ways to scroll an area that may be far easier than hammering the keyboard, but they are all based on also emulating a mouse. Joysticks, switches, voice, facial expressions, and so on.

This video shows Mouse Keys setting virtual focus to allow scrolling:

I spend the first 13 seconds trying to tab to the scrolling area or scroll it using arrows with no luck. At 0:13 I press F7 to confirm there is no caret navigation. At 0:21 I activate Mouse Keys by pressing five times. Then I hold down K to move the mouse pointer into the table and press I at 0:32. Then I use the arrow keys to scroll left and right.

If you have no number pad, you will likely need to disable Mouse Keys immediately after using it (press five times). Otherwise the next time you start typing in a text box you may be surprised when some letters and numbers do not appear (7, 8, 9, U, O, J, K, L, I, M, and .).

Solutions for Developers

Given all the information above, as developers we need to weigh this against what we know and can discover. This involves understanding the scrolling area’s purpose, the point of the page, the overall reason for the site, the patterns extant on the screens within the site, and so on.

It also involves understanding our user’s technology profile, mood, stress level, comfort with technology, skill with same, willingness to experiment, tolerance for mistakes, and so on.

Anecdata

Anecdotally, I have found most users are unaware caret browsing exists. How many mobility-impaired users know it exists is unknown to me, at least not without a more formalized research effort.

Out of 672 respondents, 79.2%, or 532 of them, did not know what caret browsing is. Only 25, or 3.7%, use caret browsing. Those percentages stayed consistent throughout the 24 hours the poll ran.

Try It

Use this example to test your own caret browsing or mouse emulation techniques. It is what I used for the videos above. Note the scrolling container has both :focus and :focus-within styles. Visit the debug version free of the wrapping cruft to try it.

See the Pen Caret Table by Adrian Roselli (@aardrian) on CodePen.

Verdict

A warped keyboard with a pair of carrots, greens still attached, resting on it, and instead of a computer screen is an unrolled blank papyrus scroll.
What you get if you ask an AI to show you how to scroll on a computer with a caret.

If I am building screens for a small set of users within an organization that is standardized on Microsoft Windows and I am in a position to train those users, then I will consider dropping my tabindex / role / accName approach.

If I am building a public-facing site where critical information could be in a scrolling area that anybody using any browser on any platform could use, and I will never know them and they may never come back, then I am still leaning on tabindex / role / accName.

Until Apple implements caret browsing for Safari and we have some comfort our audience uses caret browsing (or are all on Firefox), screen reader users will be stuck with overly-verbose scrolling interfaces. With the added irony that a blind screen reader user won’t even know it scrolls.

Update 6 June 2022: Spatial Navigation

I have seen some side discussion of spatial navigation as another option for users. The problem is that spatial navigation is meant for moving between interactive bits on the page, not non-interactive scrolling areas.

You can try this yourself and see it will not work in this scenario. Either:

  1. grab a Presto version of Opera (before it moved to a Chromium engine),
  2. try the --enable-spatial-navigation switch when launching Chrome (which does not seem to work anymore?), or
  3. install Vivaldi and enable it (with the Shift modifier key).

If you make the scrolling region interactive by giving it a tabindex, role, and accessible name, then spatial navigation will work to put focus on it. Then you can use the arrow keys (no Shift modifier). At which point you are back to the verbose coding technique I am recommending.

No comments? Be the first!

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>