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

Status: RESOLVED FIXED

(Toolkit :: Video/Audio Controls, defect)

Description

[Tony Chung [:tchung]]

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

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Please also note bug 494175, where this might get fixed.

Comment 3

[alexander :surkov (:asurkov)]

(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?

Comment 4

[Tony Chung [:tchung]]

(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

[alexander :surkov (:asurkov)]

(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

[Marco Zehe (:MarcoZ)]

(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

[alexander :surkov (:asurkov)]

(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?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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

[Marco Zehe (:MarcoZ)]

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.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Marco. I commented over there.

Comment 11

[Frank Yan (:fryn)]

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.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: 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/

Comment 13

[:Gijs (he/him)]

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.

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch for check-in

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/26c864103983

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/26c864103983

Comment 17

[Marcia Knous [:marcia]]

ni on jaws - is this release note worthy, and if so do you want to suggest some wording? Thanks.

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

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.