Keyboard and Overflow

Imagine that as a user you regularly use the keyboard for non-data-entry tasks. Think about how frustrating it is to have to grab the mouse to hover over something on the screen just to see it. Now imagine that you are a keyboard-only user.

That problem can be addressed somewhat easily by just making sure you enable :focus (or its equivalent) for anything where you rely on :hover (or its equivalent) to display. Now imagine a feature that doesn’t use hover, but relies on a mouse, like a scrollable area of the page.

Steve Faulkner has demonstrated a simple technique to make scrollable regions accessible to keyboard users in his post Short note on improving usability of scrollable regions. Just add tabindex="0" to the element.

As we might recall from my post on tabindex, adding the attribute with a value of 0 puts the element into the tab order of the page, meaning a keyboard user can access it. This also means a keyboard user can scroll up and down (and/or left/right) by first giving it focus.

What about Hidden Overflow?

Steve’s post came right about the same time I was looking at a data grid with a client that has a large chunk of content that is hidden on overflow, and only displays on hover. No scroll. The client wanted to retain this.

There is an added wrinkle — because screen widths and the volume of content are variable, sometimes the cell can fit all the content and sometimes it cannot. I certainly don’t want to make a tab-stop for every cell as that can be annoying and slow.

So I began to experiment with both overflow: hidden and text-overflow: ellipsis to hide content without a scrollbar. Then I worked up some (barely passable) script to find content that overflows (since this can be different for every piece of content and every viewport) and add tabindex="0".

What I found out pretty quickly is that <table> and overflow don’t work as well as I had hoped. Once I had stuffed a <div> into every <td> and leaned on vw units (block elements need a width to work with ellipsis, which doesn’t work so well in a liquid <table>), I had a mostly responsive table that worked with text-overflow: ellipsis.

Then I folded in my script and created some sample grids with content that will overflow at various viewport sizes. That experiment is embedded below, though you can also go to the full-page version so you can run through it more easily with a keyboard.

See the Pen Testing Overflow in Tables by Adrian Roselli (@aardrian) on CodePen.

Animated Examples

I’ve made some animated GIFs to show the effect (Chrome, Windows):

Showing how I handle text-overflow:ellipsis for keyboard users.
Showing how I handle text-overflow:ellipsis for keyboard users.
Showing how I handle overflow:scroll for keyboard users.
Showing how I handle overflow:scroll for keyboard users.

To-Do List

This demo is nowhere near done. This is not production-ready code.

The requirements with my client changed, so I shelved this a few weeks ago. However, I thought this might be a neat idea worth sharing. Perhaps someone sees something obvious that I missed. Perhaps someone has a better idea. Perhaps this is a wild goose chase. Feedback is (generally) good, but I cannot get any if I leave it sitting on my machine.

As such, I have a brief to-do list:

This Is a Hack

Some of this would not be necessary if the browsers properly exposed scrollable regions to the keyboard. As for non-scrolling hidden regions, well, that’s a slightly different take as it depends on whether the intent is to display it with any user interaction.

Regardless, Steve Faulkner has filed bugs with two browsers to address the lack of keyboard support of areas that scroll as a result of an overflow declaration.

3 Comments

Reply

As for text-overflow: ellipsis, the functionality from your demo should be provided by the browsers themselves, I think. If a part of the text cannot be displayed due to width limitations, that part should not be completely lost to the user, and the browser should provide a mechanism to access it. What do you think?

In response to Šime Vidas. Reply

I think I agree. The browser should already provide a tab-stop for overflow: auto, as the bugs Steve has filed suggest, so I think text-overflow: ellipsis should be included. Though it occurs to me that perhaps that should be an explicit request as it might not occur to the browser engineers.

Reply

[…] Keyboard and Overflow – Adrian Roselli – http://adrianroselli.com/2016/02/keyboard-and-overflow.html […]

Leave a Reply to Šime Vidas Cancel 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>