Revise SUMO Block autoplay instructions to address scroll issues, review "Block Audio and Video" setting description
Categories
(support.mozilla.org :: Knowledge Base Content, task)
Tracking
(Not tracked)
People
(Reporter: alice.wyman, Unassigned)
References
()
Details
+++ This bug was initially created as a clone of Bug #1560635 +++
Bug 1560635 comment 7 Post by MarjaE 2020-06-01 14:41 EDT
The instructions ask users to scroll down to certain preferences. If we need to page down instead, about:preferences still goes haywire due to focus bugs. The instructions do not include alternatives for users who cannot scroll in general or on about:preferences.
The instructions also state that "The Block Audio and Video setting will prevent autoplay for all media, including video, even though audio is muted." Which is not true.
The https://support.mozilla.org/en-US/kb/block-autoplay instructions currently say to "Select the Privacy & Security panel" and "Scroll down to the Permissions section". We could add " (or enter autoplay in the Find in Options/Preferences search box)" to address the scroll issue. Note that other SUMO articles besides this one may include scroll instructions. Joni, is this an accessibility issue for other SUMO article instructions?
I'm not sure about the Block Audio and Video setting description. Wesley?
I think the block is supposed to block these. If so, it may be worth noting that due to the variety of implementations, the autoplay settings may not yet work with all sites. If not, it should specify which video it is or isn't supposed to block.
|
Reporter | |
Comment 2•4 years ago
|
||
Copied from bug 1560635 comment 9 Alastor Wu [:alwu] Reporter 2020-06-02 13:35 EDT
The instructions also state that "The Block Audio and Video setting will prevent autoplay for all media, including video, even though audio is muted." Which is not true.
This is partially true, because it indeed blocks all media, but it only happens before the page gets activated by user gesture. [1]
Copied from bug 1560635 comment 10:
And how are users supposed to block autoplay so that it actually blocks autoplay? "Activated by user gesture" is toxic, because:
-
Allowing "gestures" to activate the video or other online migraine delivery system makes it unclear how not to, because we don't know which ones will activate it.
-
Relying on "gestures" creates a situation where even if we know the triggers, users with various disabilities and/or alternative controls not be able to avoid it or not be able to activate it. Relying on "tapping" creates similar problems.
I can't check the linked article because:
- It's on Google Docs, so the text is unreadable, the text animates scrolling after each page down, which is one of my migraine triggers, and the site combines that with a non-scrolling sidebar which is another.
|
||
Comment 4•4 years ago
|
||
In short, the reason of using the user activation is to keep compatible with other browsers. Most browsers are using the user activation as their blocking policy, although its actual user experience is not so good.
Therefore, we provide other two policies that can be enabled by setting
media.autoplay.blocking_policy=1 or media.autoplay.blocking_policy=2. I've copied the detail of those policies from the goole doc, and pasted on bug 1642250 comment 6.
|
|
Reporter | |
Comment 5•4 years ago
|
||
(from comment #0)
The https://support.mozilla.org/en-US/kb/block-autoplay instructions currently say to "Select the Privacy & Security panel" and "Scroll down to the Permissions section". We could add " (or enter autoplay in the Find in Options/Preferences search box)" to address the scroll issue.
I updated https://support.mozilla.org/en-US/kb/block-autoplay to address the scroll issue.
Description
•