Provide visual feedback to changing volume with keyboard in html5 audio/video

RESOLVED FIXED in Firefox 49

Status

()

Toolkit
Video/Audio Controls
RESOLVED FIXED
8 years ago
a year ago

People

(Reporter: tchung, Assigned: jaws)

Tracking

({polish, ux-implementation-level})

unspecified
mozilla49
polish, ux-implementation-level
Points:
---

Firefox Tracking Flags

(firefox49 fixed)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre Ubiquity/0.1.5
Build Identifier: 

The volume slider doesnt show up when using the keyboard up/down arrow keys during video playback.  My mouse is in the video window, and scrolling right/left arrow keys do show the scrubber skipping.

Reproducible: Always

Steps to Reproduce:
1. Launch trunk or 1.9.1 branch nightly
2. open url, and wait for video to load 
3. enable default controls, click the play button
4. while keeping the mouse pointer in the video region, click your UP/DOWN arrow keys
5. notice the sound gets louder or softer, depending which direction you click
6. HOwever, verify no volume slider shows on the foreground

Actual Results:  
Volume slider should appear in the video pane when clicking up/down arrows

Expected Results:  
Volume slider doesnt appear in the video pane when clicking up/down arrows
How does this affect accessibility?

Further why do we hide the controls when having set the focus on the video tag but moving the mouse out of the control? It's one level higher and similar to this bug report.
Hardware: x86 → All
Please also note bug 494175, where this might get fixed.

Comment 3

8 years ago
(In reply to comment #2)
> Please also note bug 494175, where this might get fixed.

I think it won' be fixed in bug 494175.

I think it should affect on accessibility. I believe screen reader user won't hear value of volume control when it's changed if volume control is hidden. But we must fire value change event from slider which we don't do currently I think. Also please consider the case when mouse is out of video element. Will videocontrols appear when you change volume assuming focus is on video element?
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> (In reply to comment #2)
> > Please also note bug 494175, where this might get fixed.
> 
> I think it won' be fixed in bug 494175.
> 
> I think it should affect on accessibility. I believe screen reader user won't
> hear value of volume control when it's changed if volume control is hidden. But
> we must fire value change event from slider which we don't do currently I
> think. Also please consider the case when mouse is out of video element. Will
> videocontrols appear when you change volume assuming focus is on video element?

Currently, when the mouse is out of the video window, default controls will disappear and no controls are shown even when keyboard controls are initiated.  Take the example of right/left arrows, notice within the video pane, the scrubber will skip 15 sec increments and you can see the skipping.  However, do the same procedure with mouse outside of video pane, and its hidden.

Comment 5

8 years ago
(In reply to comment #4)

> Currently, when the mouse is out of the video window, default controls will
> disappear and no controls are shown even when keyboard controls are initiated. 
> Take the example of right/left arrows, notice within the video pane, the
> scrubber will skip 15 sec increments and you can see the skipping.  However, do
> the same procedure with mouse outside of video pane, and its hidden.

That's what I thought. Btw, patch from bug 494175 fixes this. Let's check with Marco if it's really problem for a11y because hidden controls shoudn't be exposed to AT.

Comment 6

8 years ago
(In reply to comment #1)
> How does this affect accessibility?

As I already commented in bug 494175, NVDA does keep up with the showing and hiding of the volume slider, and when it's showing, even gives the accurate value of volume.

> Further why do we hide the controls when having set the focus on the video tag
> but moving the mouse out of the control? It's one level higher and similar to
> this bug report.

This is indeed problematic, and I wasn't aware that this is happening. A blind user generally does not know where his/her mouse is. It could, accidentally, be on the video element, it could just as well be situated in the top lefthand corner of the window. Simply moving the mouse and changing the whole picture here therefore is an unacceptable behavioral pattern. Note that this is different to tooltips, also triggered by the mouse, which aren't keyboard focusable.
But if I choose to interact with the video control via keyboard, the mouse position should have no effect on my interaction model.

Comment 7

8 years ago
(In reply to comment #6)
> (In reply to comment #1)
> > How does this affect accessibility?
> 
> As I already commented in bug 494175, NVDA does keep up with the showing and
> hiding of the volume slider, and when it's showing, even gives the accurate
> value of volume.

Btw, is it still valid if control elements aren't focusable? In general, how these controls are operable if you set @controls="true" which makes controls to be shown initially?
(In reply to comment #6)
> This is indeed problematic, and I wasn't aware that this is happening. A blind
> user generally does not know where his/her mouse is. It could, accidentally, be
> on the video element, it could just as well be situated in the top lefthand
> corner of the window. Simply moving the mouse and changing the whole picture
> here therefore is an unacceptable behavioral pattern. Note that this is
> different to tooltips, also triggered by the mouse, which aren't keyboard
> focusable.

Marco, shall I file a new bug on this issue or is it already covered somewhere?

Comment 9

8 years ago
I *think* this should be covered in the proper keyboard interaction design of bug 494175. At least, I consider it vital that we have consistency here.
Thanks Marco. I commented over there.
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Version: 1.9.1 Branch → unspecified

Comment 11

6 years ago
We're removing the visual volume slider. (See bug 694664.) Nevertheless, we should provide visual feedback for this, so I'm changing the bug description to reflect that.


This is rather low priority, but patches are welcome.
Summary: Volume slider is hidden when using keyboard volume controls → Provide visual feedback to changing volume with keyboard in html5 audio/video

Updated

5 years ago
Keywords: polish, ux-implementation-level
Created attachment 8749209 [details]
MozReview Request: Bug 495162 - Show the HTML5 video control bar during volumechanges. r?gijs

Review commit: https://reviewboard.mozilla.org/r/50807/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/50807/
Attachment #8749209 - Flags: review?(gijskruitbosch+bugs)
Assignee: nobody → jaws
Status: NEW → ASSIGNED

Comment 13

a year ago
Comment on attachment 8749209 [details]
MozReview Request: Bug 495162 - Show the HTML5 video control bar during volumechanges. r?gijs

https://reviewboard.mozilla.org/r/50807/#review47497

::: toolkit/content/widgets/videocontrols.xml:570
(Diff revision 1)
>                              var volumePercentage = Math.round(volume * 100);
>                              this.updateMuteButtonState();
>                              this.volumeControl.value = volumePercentage;
>                              this.volumeForeground.style.paddingRight = (1 - volume) * this._volumeControlWidth + "px";
> +                            // Show the controls to highlight the changing volume,
> +                            // but only if the controls can get hidden.

Can you make this comment more explicitly related to what we're testing for? Something like:

"Show the controls to highlight the changing volume,
but only if the click-to-play overlay is not present and we can therefore show the controls"

or something.
Attachment #8749209 - Flags: review?(gijskruitbosch+bugs) → review+
Created attachment 8749227 [details] [diff] [review]
Patch for check-in
Attachment #8749209 - Attachment is obsolete: true
Attachment #8749227 - Flags: review+
Keywords: checkin-needed

Comment 15

a year ago
https://hg.mozilla.org/integration/fx-team/rev/26c864103983
Keywords: checkin-needed

Comment 16

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/26c864103983
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49

Updated

a year ago
Depends on: 1271976
ni on jaws - is this release note worthy, and if so do you want to suggest some wording? Thanks.
Flags: needinfo?(jaws)
No, I wouldn't say that this is release note worthy. We always allowed changing the volume from the keyboard, except we will now show the controls when they're being changed so it's more obvious. Not a big enough feature change or functionality improvement to call out.
Flags: needinfo?(jaws)
You need to log in before you can comment on or make changes to this bug.