Skip to main content

Thinking about whether an audio player component should use be a toolbar role with a roving tabindex, even though HTML audio controls do not, and if they should, what happens when the left and right arrow keys get you to a range input uses those arrow keys to adjust the number on the input. #a11y #webComponents
#a11y #webcomponents

Peter Vágner reshared this.

in reply to Nikki Massaro

Jamie Teh
Jamie Teh
• •
It's a tricky one. On one hand, a toolbar reduces clutter in the tab order, which can make things more efficient. On the other hand, it has the range problem you describe, plus it makes it harder to have keyboard shortcuts which don't require you to focus the specific control. For example, in Firefox, when you're focused on the play/pause button, you can use left/right/home/end to seek, up/down to adjust volume, all without having to find the specific control. But you can still tab to the control if you wish, which is great if you don't know about the shortcuts.
in reply to Jamie Teh

Jamie Teh
Jamie Teh
• •
I had to think about this quite a bit when I revamped the a11y of the video/audio controls in Firefox last year.
in reply to Jamie Teh

Jamie Teh
Jamie Teh
• •
I guess the other question I'd ask is why not use the browser's builtin controls, but I'm guessing you have a good reason for that, otherwise you wouldn't be investing time into this.
in reply to Nikki Massaro

Jamie Teh
Jamie Teh
• •
You're welcome. In case it's helpful, here's the Firefox bug where this was discussed (at length, over a long period of time and with many differing opinions). I'm linking directly to the comment where the most recent plan was laid out, but earlier comments might provide some interesting food for thought. Or alternatively, they may make you wish you'd just been rickrolled instead. :) bugzilla.mozilla.org/show_bug.…

494175 - Make and controls keyboard navigable

RESOLVED (jteh) in Toolkit - Video/Audio Controls. Last updated 2021-10-06.
bugzilla.mozilla.org
⇧