Meeting minutes
ACT Standup
Kathy: Catching up on open issues.
Daniel: I worked on planning with Kathy and Trevor, and looked at some standing issues with WAI architecture website
… worked with some people on presentation for CSUN
Tom: open issue on aria for 1.3, CFC timeframe
Helen: Some work with community group on usability study for voice reco users
… Hopefully discussion another item I'm waiting on to finish my changes
Catherine: No report
Todd: No report
Updated Work Statement - Daniel
<dmontalvo> ACT Work Statement
<dmontalvo> PR for review
Daniel: We just introduced this a few weeks ago. Work statement is a document that describes what a TF will do - scope, approach. Specifies how you can become a participant, minimal expectations.
… We included more explicit ARIA definitions, ACT version update to 1.1. Updated communication section, contacts, which weren't the same in 2020
… This is so you can have a look if something's missing from the work you're doing, which is what you should be focusing on.
… If you all agree, we'll present to AGWG
Tom: Should doc be referencing 1.1 in the objective?
Daniel: That's not current yet, so that's in the approach below
Kathy: How often is this updated?
Daniel: Whenever we recharter
Kathy: We update when 1.1 is released?
Daniel: Yes, we should
… This is still a pretty generic document. We didn't get into what will be in the format because that's still subject to change, and if we put it here, then we have to do regular updates to this document.
Kathy: One format thing with ACT-Rules to ACT Rules.
Catherine: In first use of the community group, should put the acronymn in parens after the first use.
… for ACT-R CG
Daniel: If there are further comments, PR is in the minutes
Audio element content has transcript - Helen
<Helen> act-rules/
Helen: PR is 2064
… We decided in the TF in the surveys that transcript available in the accessibility tree is not needed, or if we look at the actual decision, it was Wilco decided because that fails 1.3.1 not 1.2.1.
Helen: Row 82 because Ex. 6 is a failure, the reasoning for removing the transcript being in the accessibility tree is because it's not a failure of the rule that's being tested as in 1.2.1, however, when I did these changes, Jean-Ives said, no, it should be part of the accessibility tree.
… Since Wilco and Jean-Ives are not in agreement, thought I'd bring it here.
… Jean-Ives said taking that definition out makes it no longer a normative example. We shouldn't fail another checkpoint.
<Todd> I am in agreement with Jean-Yves
https://
Tom: doesn't agree that available to all users means in accessibility tree
Kathy: In the PR, it's removing it from the transcript and the play button
Helen: I might have done that wrong. My spotty recollection was that the included in accessibility tree was going to be removed from the transcript, but don't recall for the play button.
Helen: (prior was Kathy), I may have been overzealous.
Helen: I think we took it out because it was autoplaying. More about the fact that it was autoplaying or has a button.
Kathy: Maybe we need to start from the top of the PR and see if our memories are in alignment.
Helen: Survey says remove from the expectation
… And these are Wilco's comments
Kathy: I think it just applies to the transcript
Daniel: I also think that was the conclusion - just transcript, not the play button
Helen: That was because of the autoplay
… The line about remove accessibility tree doesn't say just the transcript.
Kathy: Jean-Ives first comment is about secondary, we can skip. Second comment is about play button where button replaced with autoplay. He's asking what does autoplaying mean. No problem using it, but needs more definition.
Helen: Yes, I'm okay with that. More the accessibility tree part that I need help on.
Kathy: Wilco's comment was this rule shouldn't be covering this.
Tom: I think typically we say in the accessibility tree as in right now.
Helen: It is or it isn't.
Tom: It may not be included right now, but might load later.
Kathy: My memory was if the transcript is provided and visibly on the page, the fact that it's in the accessibility tree or not is not a 1-1 check and he was considering making whether it was in the accessibility tree as a separate rule.
… We were discussing if it is removed from this rule, then we would remove the failed example related, so there wouldn't be any 1.3.1 issues in this rule.
Helen: And Jean-Ives last comment is going through the understanding document showing that it needs to be in the accessibility tree to be a proper transcript.
Kathy: I don't think the point of disagreement is that it should be in the accessibility tree, but the discussion is that if this is 1.2.1, then we shouldn't include issues with a different SC.
… Looking at it more from an ACT rules perspective, we generally avoid combining SCs.
Tom: Can we add a note to the expectation that it needs to be in the accessibility tree, but is not covered by this rule
Kathy: Maybe in another section. Assumptions maybe.
Helen: I'll add definition for autoplay and then add a note for the assumptions.
Daniel: Maybe add a note to the minutes to the PR
ACT Taskforce Clarification - Equivalent resource - Tom
https://
Tom: iframe elements with identical accname have equivalent purpose
… is 2 iframes named "advertising" a problem?
… alistair comment doesn't see it as a problem
… is this rule needed?
Kathy: I think I saw a recent PR to update the understanding of 4.1.2 that it needs to be descriptive
Tom: Descriptive does not necessarily mean unique
… Helen: Isn't it a clasification type of thing where role and name make the thing unique?
Daniel: Not sure if we have the normative requirements to ask for that
Kathy: It just says if they are the same they should point to equivalent resources
Tom: Does the SC say they have to be unique?
Helen: It says it is preferred
Tom: Agree this is a best practice thing, not sure that it should be normative
Kathy: We are talking whether this rule is needed
Tom: Yes
Kathy: I think it relates back to accessible name is descriptive. We have a similar rule for images
… Not sure if we have an iframe accessible name is descriptive, that would fit best here
Tom: I agree
Kathy: Iframe element has non-empty accessible name
Kathy: I am kind of leaning in your direction, Tom, that this rule is not needed
… Can we ask the CG to take a look?
Kathy: I think I am leaning towards not maintaining this rule