Secondary requirements and accessibility support

[kengdoj]

ACT Task Force on 3 Aug 2023 discussion: Accessibility support differences have resulted in some inconsistent outcomes.

Outcomes for failed examples in Audio or video element avoids automatically playing audio have been found to vary depending on the browser used to test. Some of the rule's Failed examples did not automatically play in some browsers and therefore did not fail as expected. This results in an inconsistent implementation.

From this rule's Accessibility Support:

Some major browsers no longer automatically play the ‘video’ unless the ‘video’ is muted.

This rule is mapped to SC 1.4.2 and required for conformance.

For rules where accessibility support affects rule outcomes, should the SC be a secondary requirement?

[kengdoj]

Some of the rule's Failed examples did not automatically play in some browsers and therefore did not fail as expected.

This was my experience a while ago using Edge. The failed examples were not applicable because there was no auto play. I checked again (in Edge again but different version from before) in the past week, and all auto played this time, so the Failed examples all failed.

[kengdoj]

24 Aug 2023 Task Force conclusion:

Accessibility support is not a reason for a WCAG SC to be a secondary requirement.

• presence of autoplay in code should be flagged as a failure even if browsers may not automatically play.
• meta viewport rule can be skipped by implementers if they do not perform mobile testing

[WilcoFiers]

Update from Task Force meeting, August 24th

In yesterday's meeting the task force concluded that accessibility support is not a cause for having an accessibility requirement listed as "secondary". There are two parts to that. The first is that the feeling in the group seemed to be that certain cases should be failed, even if they don't cause an accessibility problem every user agent and assistive technology combination in every circumstance. The first conclusion then is that there are scenarios where we think that even if there is variability between browsers, failing that rule needs to be reported as a conformance issue, and not doing so should not be considered consistent.

That leaves the question on whether there are ever accessibility support differences, it is appropriate for an implementation to sometimes call that a conformance issue, but other times not. Going over the example we have today the group generally felt that that wasn't the case.

Autoplaying audio should always be reported as a conformance problem by a tool/methodology that aims to be consistent with the autoplay rule, even if browsers sometimes block the audio. Similarly, meta elements being used to prevent zoom should always be reported as a conformance problem for a tool or methodology that is consistent with our meta element viewport rule.

On the other end of that, the conclusion from task force was also that when failing a rule almost never results in a conformance issue, we should not have a rule that maps it to WCAG. The two examples we have of that today is the lang matches xml:lang rule, and the empty headings rule. The first one is an issue only in older browsers, which we're deprecating. For the second one we have no recent evidence showing this is still an issue, and we should likely deprecate that too.

This approach has a few implications to it:

1. It gives AGWG a responsibility to decide when an accessibility support problem has become rare enough that the rule testing for it needs to be deprecated.
2. It creates an incentive for implementors of ACT rules that strive for a high number of consistent rules to set relatively broad goals for accessibility support. For example, the meta viewport rule would reporting those issues as conformance problems, even though it is exclusively a mobile browser issue, and is something all (??) modern browsers let a user override with accessibility settings