search

w3c / matf

Guidance from the Mobile Accessibility Task Force (MATF)
https://w3c.github.io/matf/
Other
6 stars 1 forks source link

Success Criterion 1.4.2 - Audio Control - Level A #27

Open JJdeGroot opened 3 months ago

JJdeGroot commented 3 months ago
MATF meeting on July 17, 2024 [Source](https://www.w3.org/2024/07/17-matf-minutes.html#t03) Independent from system volume? Super weird I would say we should follow the current WCAG structure - otherwise we could rewrite a lot of the success criteria. JJ; There is some overlap, but this is under perceivable and focused specifically on audio, as opposed to operable and more general +1 Mick +1 to Mick JJ: What about Splash screens? I see (hear) it on spa and salon websites a lot still in the US Chromium and other browsers have the ability to mute now, but that would fall under UAAG IMO Jamie: Do we need to discuss this, what do we need to change Tori: Building on what Jamie said - a lot of these are general - these are the areas that are fairly agnostic +1 to Tori,, and we need an actionable item from Agendum 2 JJ agrees I do feel that since phones have a dedicated rocker for volume that it should respect the user settings Jamie: Can we add action items for agenda 1 + 2 to take ownership for 1.4.1 and 1.4.2? ACTION: Create subgroup to discuss 1.4.1 and 1.4.2 within the Github repo move to previous agendum

WCAG2ICT guidance: https://w3c.github.io/wcag2ict/#audio-control

Share your thoughts for applying to mobile apps as a comment below.

qbalsdon commented 3 months ago

The only thing I would like to discuss here is why 2.2.2 Pause, Stop, Hide can't cover this criterion? I'm nothing if not redundant, but it seems a bit odd.

julianmka commented 1 month ago

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT.

Proposal In MATF's first draft of guidance, this SC's section will read as:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.2, replacing “on a Web page” with “in a screen or view”, “any content” with “any part of a screen or view”, “whole page” with “whole screen or view”, and “on the Web page” with “in the screen or view”; and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

1.4.2 Audio Control: If any audio [in a screen or view] plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

NOTE 1 Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [screen or view], all content on the [screen or view] (whether it is used to meet other success criteria or not) must meet this success criterion.

Would we also want to include the not on Closed Functionality?

NOTE 2 See also the Comments on Closed Functionality.

julianmka commented 1 month ago

After discussion and voting at the meeting today, the task force members present accepted the proposed language for the first draft of our guidance, minus the note on Closed Functionality.