Rewording of normative text for 1.4.2 Audio Control #1824
Conversation
Taking @bruce-usab's suggestion from #1533 (comment) Closes #1533
patrickhlauke
added
WCAG 2.2
Normative
1.4.2: Audio Control
Errata
In contrast to #1824 this rewording accepts that the mechanism does not necessarily have to be implemented by the web page itself, but - per the definition of mechanism - can also be provided by the user agent/system. What this change does implement though is the clarification for the pause/stop clause that the pausing/stopping must be *independent* from any other audio output (which does address @jake-abma's original concern that a system wide general mute/audio off would automatically satisfy the SC, which is not the intended outcome #1533 This still changes the structure of the SC text, as suggested by @bruce-usab, to a more understandable list format. If the change in structure is deemed too radical, the addition of "independenlty from any other audio output" could likely be slotted into the current wording/structure of the SC. while a normative change, I don't believe this actually changes the meaning as intended at the time. Closes #1533
|
I would read this version as clearly implying that the author is responsible for implementing the control to stop / change level of / audio - which might be a good thing, given that availability and place of UA/OS level controls will vary and many users will struggle reaching them. |
|
but the normative wording already currently talks about "mechanisms" being available, which can come from UA/OS. whether those mechanism are then pervasive enough is the question that people evaluating content need to assess (as they do with other "mechanism is available" SCs) |
|
https://www.w3.org/TR/WCAG/#dfn-mechanism
specifying that the mechanism must be done by the Web page itself as in this original suggestion seems to go against this idea. which is why #1825 is my preference, since it keeps the original wording/spirit |
It is certainly more consistent and in line with the normative text. Still, for something as disruptive unstoppable audio blaring out of a page, I would prefer a requirement that it can be stopped by content controls (admittedly this is more then the normative ask - and for the sake of consistency I think #1825 is preferable). Lacking an author-provided control, any PASS/FAIL decision then has to take into account the accessibility baseline of the conformance claim - I would imagine on several UA / platforms there won't be a control to mute audio independent from system audio, but that would need some digging... |
which is fine, so in practice nothing changes here. that's what's the SC currently says. and we'd still fail these cases because we know that the UA/OS based solutions aren't pervasive enough yet to count. But then, in audits that are very specifically scoped to a platform (e.g. a site that only targets a particular UA/OS, which does provide this option easily), it can be passed. that nuance/decision making ("does this mechanism count as being an acceptable mechanism to pass this SC") has already been there from the start. |
|
I agree that we should make it clear that in some very specific situations where the scope of the audit can be limited to certain browser combinations that you can rely on the browser feature to mute audio otherwise today this is generally solved by the author providing a mechanism in the page to pause/stop audio. Of note Trusted Tester indicates that auto play should be disabled in the browser for this test: https://section508coordinators.github.io/TrustedTester/auto.html Note: |
|
Could this be taken for discussion/vote @alastc ? |
|
To simplify matters, I'm going to close this and say it's superseded by #1825 |
Taking @bruce-usab's suggestion from #1533 (comment)
Closes #1533
[edit: here's an alternative, which I'd actually prefer https://github.com//pull/1825 ... leaving this here as an option though]