– DRAFT –
Accessibility Conformance Testing Teleconference

TPAC meet with ARIA

Joint meeting with ARIA

<dmontalvo> Wilco: At TPAC 2023 we will be having a joint meeting with the ARIA WG, 12 to 13 on Thursday. This will be on the TPAC agenda. The topic will be Backwards compatibility of ARIA specs

ACT Standup

<dmontalvo> Wilco: I finished four of the annual reviews

<dmontalvo> ... Sent out a CFR email for updates to secondary requirements text, which should clear up all my assigned issues

<dmontalvo> Catherine: Cleared up all my assignments

<Wilco> Here's the PR I mentioned: act-rules/act-rules.github.io#2060

<dmontalvo> Daniel: Not much from me, ust came back yesterday from holiday

<dmontalvo> Trevor: One Open for video and captions, worked on subjective applicability

<dmontalvo> Suji: Worked on annual reviews, two more pending yet

<dmontalvo> Helen: I have done my reviews, done an acceptance on Wilco's secondary requirements, that is now so much easier to understand

<dmontalvo> Tom: Not much from AT, took a look at subjective applicability and secondary requirements

<dmontalvo> Kathy: New PR for the language to add `lang` attribute. I need one more review

<dmontalvo> ... That's PR 2100, please add your reviews

<dmontalvo> ... Started PR for Label in Name, that's draft

<dmontalvo> ... Shane, I'll be sending you an email with details on how the group works

Secondary requirements and accessibility support

<kathy> https://github.com/act-rules/act-rules.github.io/discussions/2095

<dmontalvo> Wilco: Discussion opened to clarify secondary requirements

<dmontalvo> ... These are requirements that are related to the rule but are not exactly what the rule is specifically testing

<dmontalvo> ... tricter SCs, overlap between some SCs, etc

<dmontalvo> ... One of the conversations that came out of this is if we want to allow rules that have failed examples that depend on environmental reasons: browsers, ATs, OS, etc

<dmontalvo> ... We have a rule about viewports. That only works on mobile browsers

<dmontalvo> ... Do we want these types of rule that require testers to fail all of them or we want to move these failures to the secondary requirements category so that tare's more leeway for testers?

<dmontalvo> Kathy: The discussion was on autoplay

<dmontalvo> Wilco: There are others, such as the iframe related ones

<dmontalvo> ... Are we OK with having rules where failing these become "optional"?

<dmontalvo> Trevor: I feel better about iframes, not so good about autoplay

<dmontalvo> ... Because the browser just handles it, we may end up giving the impression that certain SCs can never fail

<dmontalvo> Tom: If it is a cross device issue that's not good, if it is more obscure I would be OK

<dmontalvo> Wilco: For example in the empty headings there is still the argument that some empty headings do not get ignored by ATs

<dmontalvo> .. We have had that as a failure of 1.3.1 and I've not been particularly comfortable about that

<dmontalvo> ... What does Trusted Tester do with these scenarios?

<dmontalvo> Kathy: For the autoplay scenario I found some examples that were coded to autoplay but didn't. And recently I went back and they did autoplay. I am getting different results

<dmontalvo> ... We document which browser and test environment so that we can tell the results we find in each browser

<dmontalvo> ... Trusted Tester falls back to the browser we tested on and that's the result we provide. We don't use to test in multiple browsers

<dmontalvo> ... For the presentational role where image has role presentation but an alt text, we are still figuring out how to deal with this. I think ACT tackled that discussion a while ago

<dmontalvo> ... When we find the heading tag and there is no visible test, we would fail that

<dmontalvo> ... We still don't test viewport

<dmontalvo> ... And we do require that iframes have an accessible name

<dmontalvo> ... For iframes we'd be open to changing that

<dmontalvo> Catherine: I don't feel strongly either way

<dmontalvo> Wilco: I don't think any of us are dogmatic that if it is not a failure in the browser I would never report it

<dmontalvo> ... The tools we use do check for these things

<dmontalvo> ... There are scenarios where you are relying on the browser and others where you use other means

<dmontalvo> Tom: We would be on the side of flagging the bad code

<dmontalvo> Wilco: Another way to look at this is for example with the iewport, if you are not interested in mobile testing, it's reasonable to skip that rule

<dmontalvo> ... The downside is that you have your rules implemented in ACT and we may create an implicit incentive for those of us trying to implement as many as we can to be stricter and potentially fail things that are no longer relevant

<dmontalvo> ... But I may be OK with that

<dmontalvo> ... I am OK with saying "autoplay always fails" irrespective of what the browser does

<dmontalvo> ... Methodologies would tend to update to cover these cases

<dmontalvo> Trevor: If there was additional metadata that we could include in the implemnetation reports that expains why they arrived at that result, then Jean-Yves would agree with that

<dmontalvo> Wilco: I think this came from Trusted Tester

<dmontalvo> ... I don't think there was an implementation problem from SiteImprove

<dmontalvo> Kathy: I mentioned this a while back but now the autoplay examples are working

<dmontalvo> Shane: The way is written is code-wise

<dmontalvo> ... The thing that this works or not depending on the user agent is complicated, there is a great variety on configuration to rely on whether user agents will do the right things

<dmontalvo> ... It would make sense to test whether these is built in a way that could create an accessibility problem

<dmontalvo> Kathy: When we do our tests we do not disable autoplay

<dmontalvo> ... But I am find with the suggestion that if it's coded to autoplay that's a failure

<dmontalvo> Wilco: Then accessibility support is not a reason to set something as secondary requirement

<dmontalvo> ... I am OK with those. I am not sure what it means for empty headings

<dmontalvo> ... This is an issue sometimes. Does it mean we should deprecate that rule?

<dmontalvo> Trevor:The heading example feels like it's so rare thta it would border an optional test case

<dmontalvo> Wilco: This is an entire rule

<dmontalvo> Tom: If there is no primary SC then what's the point on having the rule?

<dmontalvo> Wilco: The reason we wrote it is because we had a number of implementers who thought this was important

<dmontalvo> Wilco: I think we have another rule like that, which is just a best practice, no accessibility requirements

<dmontalvo> Wilco: Several things:

<dmontalvo> ... Accessibility support is not a reason to make something a secondary requirement. We should put this in the ACT Rules format

<dmontalvo> ... If the problem is common enough that there should be a rule to cover it, we should

<dmontalvo> ... We are happy with all the ones we currently have, except for headings, where we think that's not such big of an issue

<dmontalvo> Kathy: What conclusion reached about the heading rule?

<dmontalvo> Wilco: We should remove 1.3.1 from the rule

<dmontalvo> Kathy: Those implementers who would fail that, would they have inconsistent results?

<dmontalvo> Wilco: I don't think that is what that means

<dmontalvo> ... According to rules format we don't have a mechanism to cover those, as there won't be a way to fail this under WCAG

<dmontalvo> ... We could consider this a common failure but not a WCAG failure

<dmontalvo> ... We may need to have that conversation, there is a TPAC agenda item for that

<dmontalvo> Wilco: Leaving that question aisde, are we happy with these conclusions?

<dmontalvo> Kathy: Yes

<dmontalvo> Wilco: I think we should put that in the rules format

<dmontalvo> Kathy: I can draft something

Subjective exceptions in the applicability

<trevor> https://github.com/w3c/wcag-act/pull/539/files

<dmontalvo> Trevor: This is about subjective applicability.

<dmontalvo> ... We have found cases in our rules where we need to test something subjective:

<trevor> https://github.com/act-rules/act-rules.github.io/discussions/2061#discussioncomment-6245094

<dmontalvo> ... We ended up pushing parts of the applicability into the expectations

<dmontalvo> ... These subjective attribute affect the applicability

<dmontalvo> ... I started to flesh out some updates to the rules format

<dmontalvo> .... We are working on allowing subjective applicability but with a number of exceptions

<dmontalvo> ... There is also wording in favor of objective applicability as much as possible

<dmontalvo> ... We have "allowed subjective forms" to guide authors on how they write subjective applicability

<dmontalvo> ... The second is that the subjectivity needs to be captured in a gglossary definition

<dmontalvo> ... If we were to write a rule for things that look as headings to be actually headings, the actual applicability would be the HTML element that is styled as a heading

<dmontalvo> ... We would need to define styled as a heading

<dmontalvo> ... We have a definition for styled as a heading and some logic as to why this definition exists

<dmontalvo> Wilco: Everybody please have a look at this, we will get into this next week