Keyboard-Only Scrolling Areas

June 1, 2022; 0 Comments

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 #anchor

The videos in this post use Sarah Higley’s handy Keyboard Visualizer bookmarklet to show what keys I am pressing. It does not work for cases where key presses are intercepted before getting to the browser (such as with screen readers).

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 #anchor

Firefox treats scrolling areas as tab-stops by default. 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:

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. 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 #anchor

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 Start → Settings → Ease of Access → Display → Automatically hide scroll bars in Windows and set it to “Off”. In Windows 11, use Start → Settings → Accessibility → Visual Effects → Always 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:

• Focus and focus-within styles will not be triggered.
• Putting the caret into a scrolling area does not mean the area has focus.
• The area only scrolls when your text cursor is about to move into a hidden part of the content, which can still be a lot of key presses just to see content.
• If focus is already on a text input, you cannot just arrow past it; you will need to tab out of it and then arrow from wherever you land.
• If you set the text cursor indicator or text cursor thickness in Windows accessibility settings, they are not applied here.

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

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. 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.

Safari: Use Mouse Keys #anchor

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:

Sorry, your browser doesn’t support embedded videos, but don’t worry, you can download it. 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 #anchor

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 #anchor

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.

Twitter poll, which is clearly highly scientific:

Do you use caret browsing in your browser?

Adrian Roselli (@aardrian) May 23, 2022

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 #anchor

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.

Verdict #anchor

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.

accessibility, browser, Edge, Firefox, Safari, usability, UX

Other Posts

No comments? Be the first!