Closed
Bug 495162
Opened 15 years ago
Closed 8 years ago
Provide visual feedback to changing volume with keyboard in html5 audio/video
Categories
(Toolkit :: Video/Audio Controls, defect)
Toolkit
Video/Audio Controls
Tracking
()
RESOLVED
FIXED
mozilla49
Tracking | Status | |
---|---|---|
firefox49 | --- | fixed |
People
(Reporter: tchung, Assigned: jaws)
References
()
Details
(Keywords: polish, ux-implementation-level)
Attachments
(1 file, 1 obsolete file)
2.07 KB,
patch
|
jaws
:
review+
|
Details | Diff | Splinter Review |
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•15 years ago
|
||
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
Comment 2•15 years ago
|
||
Please also note bug 494175, where this might get fixed.
Comment 3•15 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•15 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•15 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•15 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•15 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?
Comment 8•15 years ago
|
||
(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•15 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.
Comment 10•15 years ago
|
||
Thanks Marco. I commented over there.
Updated•14 years ago
|
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Version: 1.9.1 Branch → unspecified
Comment 11•13 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•11 years ago
|
Keywords: polish,
ux-implementation-level
Assignee | ||
Comment 12•8 years ago
|
||
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 | ||
Updated•8 years ago
|
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Comment 13•8 years 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+
Assignee | ||
Comment 14•8 years ago
|
||
Attachment #8749209 -
Attachment is obsolete: true
Attachment #8749227 -
Flags: review+
Assignee | ||
Updated•8 years ago
|
Keywords: checkin-needed
Comment 15•8 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/26c864103983
Keywords: checkin-needed
Comment 16•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/26c864103983
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment 17•8 years ago
|
||
ni on jaws - is this release note worthy, and if so do you want to suggest some wording? Thanks.
Flags: needinfo?(jaws)
Assignee | ||
Comment 18•8 years ago
|
||
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.
Description
•