Move zoom slider to toolbar

[ajlende]

Follow-up from #21024 (comment)

Having the zoom slider in the toolbar would consolidate all the controls to a single location, making them easier to find. We'll want to be careful with accessibility when implementing this.

If there isn't room for the slider in the toolbar, there are some other options for making the slider feel more contextual.

For small images, the slider can be moved below again as to not cover up too much of the image.

[ajlende]

@diegohaz You've been working on toolbars recently—do you have any insight on using a range slider in a toolbar? I haven't been able to find any accessibility notes on doing that, and the arrow key behavior between the two seems to be at odds with one another. I suppose you'd have to use the up and down arrows to move the slider since left and right are use for navigation among elements in the toolbar.

I also see that Reakit doesn't have anything for range sliders right now. Is that something you think Reakit should have? Because I'd be willing to help get that going.

[diegohaz]

Disabling horizontal arrow keys on the slider seems to be the least safe option here. It may be confusing, and we would have to test it with real users. I would like to see an app doing this, but I couldn't find any, even desktop apps. If this is as rare as it seems to be, it's a good signal to not do this.

I can think of some other options we can explore:

• Put the slider inside a dropdown that is triggered by a toolbar button.

• Instead of a slider, use buttons, like + and -.

• Explore this Editing and Navigating Inside a Cell method:

  The user may need keys that are used for grid navigation to operate elements inside a cell if a cell contains [...] A widget that utilizes arrow keys in its interaction model, such as a radio group or slider.

  The user would use Enter to activate the control and use arrow keys, and then Escape to go back to the toolbar mode. For screen reader users, this would be the same as using a dropdown. But maybe vertical arrow keys could also work here without need for activation.

This latter option sounds interesting, but by far the most complex, so I would rather try other options first.

[ajlende]

Thanks for the input @diegohaz! I can imagine the dropdown being the best choice then.

[ItsJonQ]

Hi there! I prototyped an interaction for Zoom:

• It lives as an overlay on top of the image (bottom/center)
• Pressing (-) zooms out
• Pressing (+) zooms in
• Center is an input (<NumberControl />)
• Entering values increase/decrease zoom
• Up/down + shift jumping supporting
• Drag (left/right) zooms out/in (similar to a range control)

---

Not showing:

• Need a "Reset" button perhaps

---

cc'ing @jasmussen for some Design thoughts!

[jasmussen]

This is a really cool prototype, Q. Nice work!

It seems like it has the same challenges with regards to being in the toolbar, as the slider, necessitating it to be an overlay and additional UI element. That isn't fundamentally bad.

That's said, I have a personal preference for the slider, because it feels like it most fluidly maps to the smooth zooming you get when you scroll.

I also still think the best experience is to have the slider in the toolbar, and that we should look into the solution Diego notes:

The user would use Enter to activate the control and use arrow keys, and then Escape to go back to the toolbar mode. For screen reader users, this would be the same as using a dropdown

I've seen some separate divergent explorations putting input fields in the toolbar, and although these might not come to pass, as the toolbar grows to absorb additional functionality, we'll likely benefit from handling it anyway.

In absence of, or until we're able to move the slider to the toolbar, it seems like the most direct path forward is to keep the slider as the separate element it is now, but tune and polish and refine it.