Accessibility by Default: Sliders and Tooltips
Hi, and welcome back to Accessibility by Default. If you’re new here, welcome, and if you’re a returning reader, thank you so much for coming back.
If you’re a regular reader of the series, you may have noticed things have been a little quiet over the past couple of weeks. I’ve been on holiday with my family, and I decided to take a proper break — no work (only occasionally checking emails and teams), no Medium, no accessibility, and no worrying about what I should be writing next.
It was really important to me to properly switch off, spend some time with my family and come back feeling refreshed rather than heading straight towards burnout.
Now that we’re back, though, it’s time to get stuck in. This week we’re going to be looking at sliders and tooltips.
So, these are two components that, as always, look fairly simple on the surface. One is essentially a control for selecting a value, while the other is commonly used to provide additional information when a user hovers over or focuses on something.
They can seem simple, but both components can become surprisingly complex when you start looking at the accessibility behind them. There’s a lot more involved than simply making them look and behave correctly visually. We also need to consider how they function for people using assistive technology, keyboard users, touch users, and anyone else who may interact with them in a different way.
What is it?
What is a slider?
When we talk about sliders we immediately think of an input range bar. It allows you to choose a number from a predefined range, usually by dragging a handle along a track.
What is a tooltip?
A tooltip gives the user additional information about an element without requiring them to navigate away from what they’re currently doing. It’s usually displayed when an element is hovered or receives keyboard focus.
When to use it
Sliders
A slider is a useful input when a user needs to select a value from a continuous or set range, usually when the exact value isn’t the most important part of the interaction.
A common example of a slider would be selecting a volume level. A user might want the volume to be somewhere between 0 and 100, but they don’t necessarily care about the exact number (unless you’re my wife who must have the volume at a number divisible by 5). Being able to move the slider along a track can give a quick and intuitive way of making their selection.
Other examples might include things like:
- Volume controls
- Brightness
- Price ranges
- Zoom levels
- Playback position
- Adjusting image or video settings
However, there is an important point to remember here — a slider isn’t necessarily the best choice just because you have a number. If the user needs to enter an exact value such as their age, their postcode or a specific monetary amount; a text or number input is probably a better choice. Imagine asking a user to drag a slider to exactly £57.24, that isn’t going to be the best user experience.
Tooltips
Tooltips are useful when you need to provide short, contextual information about something on the page without interrupting the user’s current task.
For example, a button containing an unfamiliar icon might have a tooltip explaining what the button does. A form control might have a short piece of additional information that can help the user to understand its purpose.
But, tooltips aren’t a replacement for visible labels or instructions. If the information is important for the user to complete the task you shouldn’t be hiding it behind a tooltip. The same applies if the content is lengthy, interactive or if the user is required to spend significant time reading it. In those situations you’re best off going with a popover or dialog (which you can read about in my previous post)
Accessibility considerations
Sliders
As this is what I say with all of my component deep dives — if you can use native elements, then you should. When you consider how much <input type=”range”> actually gives you
- A recognised form control
- A semantic role
- Keyboard interaction
- Focus behaviour
- A value that can be exposed to assistive technology
- Browser/OS accessibility integration
Remember, the less accessibility that we have to code ourselves means less opportunities for us to get it wrong
For both native and custom sliders, these are the main accessibility considerations to keep in mind
Give the slider an accessible name
As with all inputs, the input should have a label that tells the user the purpose
<label for="volume">Volume</label>
<input id="volume" type="range" min="0" max="100" value="50">A screen reader might announce something along the lines of “Slider, 50”, but that gives the user no indication of what the slider controls. Ideally, it should be announced with its accessible name as well, for example “Volume, slider, 50”.
Make the value meaningful
For a native range input, the browser handles a lot for us. But for a custom solution we have to expose
role="slider"
aria-valuemin="0"
aria-valuemax="100"
aria-valuenow="50"And sometimes aria-valuetext if the numerical value isn't meaningful by itself.
For example, a temperature slider might expose:
aria-valuenow="20"
aria-valuetext="20 degrees Celsius"Although, I’d be cautious about using aria-valuetext unnecessarily when you have a numerical value that already communicates everything to the user.
Keyboard interaction
Get Josh Allan’s stories in your inbox
Join Medium for free to get updates from this writer.
This is a big one for custom sliders.
A user shouldn’t have to use a mouse or touch screen to operate a slider.
At minimum, we need to think about:
Arrow Up/Arrow Right→ increaseArrow Down/Arrow Left→ decreaseHome→ minimumEnd→ maximum
Focus
The user should be able to focus on the slider and it should be obvious where the focus is. As always, with native control we get this built in.
With a custom component, we have to make sure that the interactive element can receive focus — usually by making the slider itself focusable with tabindex="0"
Orientation
A horizontal slider is fairly obvious as that is pretty much the standard. But once we start creating vertical sliders, that is where things start to get interesting.
A custom slider needs to communicate its orientation and the keyboard behaviour needs to be predictable. That is where aria-orientation="vertical" comes in.
This isn’t just about adding the attribute for the fun of it. The visual and keyboard behaviour need to agree with what we’re exposing.
Tooltips
Tooltips have a completely different set of problems.
Don’t rely on hover
I think that this is probably the biggest one when you think about the accessibility considerations surrounding this component. If the tooltip only appears when the mouse hovers over it, then people who use keyboard navigation may never see it.
Anything that triggers a tooltip via hover should also make it available when the associated element gets focus as well.
That gives us:
Mouse: hover = tooltip
Keyboard: focus = tooltip
Don’t use title as your tooltip implementation
<button title="Delete item">The browser may display a native tooltip, but we have very little control over its behaviour or consistency.
We can’t reliably control things like:
- How long it stays visible
- How it looks
- How it behaves on touch devices
- How it behaves with keyboard interaction
- Whether its content is exposed in the way we actually need
Remember, title shouldn’t be used as a replacement for a proper accessible name or description
Make the relationship between the element and tooltip clear
If the tooltip provides additional information about an element, assistive technology needs a relationship between the two.
This is when we use aria-describedby
<button aria-describedby="tooltip">
Delete
</button>
<div id="tooltip" role="tooltip">
Permanently deletes this item
</div>Now the tooltip can provide additional information about the button rather than becoming the button’s name.
Keyboard dismissal
A tooltip shouldn’t trap the user or require them to perform some awkward interaction to get rid of it.
For a tooltip triggered by focus, moving focus away should cause it to disappear.
For hover-triggered tooltips, the user should be able to move the pointer between the trigger and tooltip where appropriate without the tooltip vanishing immediately.
Timing
Tooltips need to remain visible for long enough for the user to actually read them.
We shouldn’t make them disappear the instant the pointer moves slightly away from the trigger, particularly if the tooltip itself needs to be reached with the pointer.
We also need to consider users who may need more time to read or interact with the content.
Touch and mobile
Hover isn’t really an interaction available on a touchscreen in the same way it is with a mouse.
If the information contained within a tooltip is important, we shouldn’t rely on hover as the only way of accessing it. We need to consider how the same information will be made available to someone using a touch device.
Final Thoughts
Sliders and tooltips are very different components, but they share the same accessibility lesson: the visual component isn’t the whole component.
A slider isn’t accessible because it looks like a slider.
A tooltip isn’t accessible because it appears when you hover.
We need to consider semantics, interaction, keyboard access, focus, assistive technology and the actual information being communicated.
I know that this is basically the philosophy of the series, but I think that it’s worth repeating. Whether you’re building a slider, a tooltip, or any other component, accessibility isn’t something that should be added once the component is finished. The way the component is named, focused, operated and communicated to assistive technology is part of the component itself.
Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.
You can find the full series on my profile
