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. After a year of deploying it and rolling it back, Chrome 127 has it (see updates at end of post). I could find no feature in development nor related bug for Safari.

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

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 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:

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

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:

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.

Twitter poll, which is clearly highly scientific:

Do you use caret browsing in your browser?

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

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:

• grab a Presto version of Opera (before it moved to a Chromium engine),
• try the --enable-spatial-navigation switch when launching Chrome (which does not seem to work anymore?), or
• 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.

Update 28 November 2022: Firefox Feature

Some developers consider the Firefox feature I outlined above to be a bug. Enough that they are trading tips on how to code around it — and making for a worse, less accessible experience in the process.

Bear in mind that when people ask browsers to fix accessibility problems automatically, we may be underestimating developers’ ability to understand why a feature exists in a browser. Oh, and their desire to leave it be.

Update 2 August 2024: The Year-Long Chrome Saga (So Far)

Chrome has been trying, and failing, to match the Firefox feature since September 2023 and Chrome 118. I restructured the updates to put them under this common heading and push them all down a heading level.

Update 22 September 2023: Chrome Feature

Per Issue 1444450: Enable KeyboardFocusableScrollersEnabled code in ax_object.cc, Chrome 118 should mimic Firefox’s support for making scrolling areas focusable by default. If WebKit (Apple Safari) ever gets on board, the hack I outline here can go away.

Update 13 October 2023: Chrome Feature?

Looks like this will land in Chrome 120 instead:

Enable feature KeyboardFocusableScrollers to stable

Intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/jzMA5vUqNDs

All regressions and blocking concerns were fixed as part of M119. We are now doing a slow rollout of the feature through Finch. Once M120 reach stable, the feature should be fully enabled.

I have found nothing from WebKit / Safari.

Update 9 January 2024: Chrome Feature??

Chrome appears to have again rolled back the feature. Issue 1504160: iframes with no focusable elements get focused, but have no visible focus indicator demonstrated that neither :focus nor :focus-visible works to set a focus style on an iframe that lacks focusable children. With that glaring 2.4.7 Focus Visible violation for potentially every site, Chrome has moved it back to experimental.

I have still found nothing from WebKit / Safari.

Update 23 March 2024: Chrome Feature???

Google Chrome appears to have again committed to deploying a feature to let scrolling areas get focus. Its announcement Keyboard focusable scrollers promises it’s coming in Chrome 124. The Chromium bug linked in the previous update is still marked as “new”.

Unfortunately, that update from Google is full of terrible information about how authors would have to address this, ranging from suggesting a positive tabindex is acceptable to failing to give the scrolling region an appropriate role or accessible name. I appreciate the change to Chrome but not the problematic implications of what authors should do in the meantime.

I continue to find nothing from WebKit / Safari.

Update 18 April 2024: Chrome Feature????

Chrome is almost fully committed now, promising all users will get focusable scrolling areas in Chrome 125 (it had rolled out only to some users in Chrome 124). Nobody fixed the bad advice in the related post.

I continue to be unable to find anything from WebKit / Safari.

Update 1 May 2024: Chrome Feature?????

This is causing some elements to get incorrectly recognized as focusable. Rolling back the release until we fix the bug.

Nada from WebKit / Safari.

Update 29 July 2024: Chrome Feature??????

The Google Chrome team has once again announced support for keyboard-focusable scrolling areas, this time in Chrome 127. I rather hope it sticks this time.

If you are new to WCAG, then you should be aware this statement from the Chrome post is wrong: Accessibility best practices recommend that all features must be available using a keyboard. WCAG requires it. WCAG 2 has required it since 2008, the same year Google released Chrome 1.0 (the same day, in fact).

Still not a peep from WebKit / Safari. So I filed an issue: 277290 – AX: Scrolling containers inoperable with keyboard.

Update 1 August 2024: Chrome Feature???????

At some point I will run out of question marks.

Yesterday I witnessed the Chrome 127 feature failing to work. While my version (across two point releases) of Chrome puts focus on scrolling containers, their version would not. We played around in dev tools, made tests, alternated styles, checked syntax, compared with Firefox, and generally were unable to see why our two matching point releases exhibited such different behavior.

So I asked for testing from folks on Mastodon and also on the A11y Slack, limited my request to Windows (to avoid any confusion with macOS’ default keyboard settings). 4 of 4 on Mastodon and 2 out of 3 on the Slack could not get it to scroll. These are not thorough tests and are mostly anecdata, but I would have expected nobody to have an issue.

One user identified, under chrome://flags/, that switching Enables keyboard focusable scrollers to “Enabled” caused the feature to work. But my version is set to “Default” and it already works, so it seems the feature may be in Chrome but not enabled properly for all users.

So I filed a Chromium bug report: Scroll containers are not keyboard focusable in 127.

Unrelated, the Safari issue I filed was imported in Radar but otherwise no activity.

Update 2 August 2024: Chrome Feature????????

However, this is only true for 10% of users:

[Chrome is] slowly rolling it out on stable 127. Currently, 10% of users see it. By 128, 100% of users should expect keyboard focusable scrollers to be enabled by default.

That means the Chrome for Developers announcement for Chrome 127 was 90% wrong. Which I suppose is better than Chrome’s other announcements of this feature for the last year.

I filed an issue to make the release announcement less wrong.

My mistake was that I took the blog post at its word, as I (and projects) have been waiting for this feature since its first planned roll out in 118.

I started testing to confirm it worked (it did for me), started updating project documentation and timelines when my tests panned out, and started to socialize it to stakeholders. Then I got reports it did not work for other version 127 users, so I had to build tests, recruit people to test, and file a sufficiently detailed bug report so it would not be auto-closed as non-reproducible (again, since it worked for me).

As a dev said to me in response to all this, now I take the changelogs with a grain of salt. Which, frankly, yeah. Fool me six times over, shame on me.

Interestingly, Safari’s inaction here makes it look simply clueless versus incompetent by comparison. And yes, I may be a tiny bit incandescently angry.

Update 6 August 2024: Chrome Feature?????????

Chrome has addressed the issue (by updating the blog post):

Note that this change is being enabled for users slowly over time, so we can monitor for issues. Therefore, some users may not see this feature enabled until version 128.

Note that the original language is still in place (the content was added), there is no acknowledgment in the content that anything has changed, and the post “last updated” date is 23 July even though it was clearly changed on 5 August.

Which adds support to why I don’t trust content on Google Chrome sites.

Update 20 August 2024: Chrome Feature??????????

Chrome 130. Not a peep from Safari.

Update 6 November 2024: Chrome Feature???????????

Keyboard focusable scrollers has been updated to push it to Chrome 132 (though the “last updated” date of the post did not shift, further supporting why I support to why I don’t trust content on Google Chrome sites.

The silence from Safari continues.

Update 18 January 2025: Chrome Feature!

Kudos to Google! After a year and a half of stuttering roll-outs and -backs, Chrome 132 landed with support for keyboard-operable scrolling areas (per its claim and my testing). At least for me. Chrome sometimes rolls out features (like this one) to some users to see if it breaks. As long as this time it sticks, the Windows side of the web at least has support.

The inaction from Safari continues.