Mary Jo: New year. Time to think about when to get together, formally/informally. We have CSUN coming up
MaryJo: Who will be at CSUN
kathyeng: I will be there
MaryJo: Barring any expense issues, I will be there
shadi: Do we need a host? I plan to be there. Wilco as well will be there.
MaryJo: Let's keep it informal
Wilco: How about lunch or dinner?
MaryJo: I'll be there Sunday thru Saturday
kathyeng: Same here
Wilco: I'm arriving Tuesday afternoon.
... Me too.
MaryJo: I am traveling on Saturday. How about Tuesday
... We'll have to be during the conference days. Schedule is now posted
... How about a Doodle poll?
MaryJo: Buried in emails is a request to rejoin AGWG by February 4. To be part of WCAG ACT Task Force, you need to be part of the AGWG
<Kasper> Apologies for the delay!
Mary Jo: Charu indicated that the assumptions doesn't state if there should be a check that the accessible name is reasonable
Wilco: I have a concern with this
... Falls into the category of listing the things we don't test. By definition, rules are subsets. We would have to do this for every rule
... We're essentially restating the success criteria
MaryJo: I think that if it's clear that it is not a full test, we're okay
Wilco: Moe also added a comment around further testing is needed. SC talks about this. Does rule need to?
MaryJo: What if you are an implementer? Need to make sure to gather the correct rules and need to know which ones to aggregate. It might be hard to figure out unless clear somewhere
... Say you're trying to test criteria. Don't want to have to search through all the rules to determine which ones test the SC. Maybe when we list the rules we identify what SC.
Wilco: The rule does identify what SC it tests
MaryJo: If testing x, how do we determine what rules are needed?
kathy: There are other rules that have accessible name as :) But it rule is only testing the existence of the name, we have to pass it. Maybe it is good to state that the rule is not testing for meaningfulness. Should we link to the rule that is testing for meaningfulness?
MaryJo: Is there another rule that we have that shows the singular ones along with the criteria?
Wilco: Not at the moment.
MaryJo: I think that's the challenge. It makes it harder.
Wilco: Are we saying we should a note for each test?
MaryJo: I think it's helpful
... I assume open issues have been handled.
Wilco: We have an open issue for suggested updates for applicability and examples from Moe's issues.
Can edits still be made if we move forward?
Wilco: Yes. But AGWG may not like it.
MaryJo: If we go forward and then make changes, we force another review.
Wilco: Yes. But it's a moving target. The train is moving.
... Put in bucket with yes, it's good to go.
... I will make a PR to add this rule to the repository.
... Let's hold off on AGWG until we have a couple more
MaryJo: Does everyone agree? Do we need a CFC?
Wilco: I don't think so but maybe send out a CFC before sending to AGWG.
<Wilco> Note: html elements within iframe and object elements are not applicable as iframe and object elements create nested browsing contexts. However, as these elements are meant to provide a layer of isolation, the language of the parent browsing context may not be inherited. This should be tested separately.
MaryJo: From Charu, Add a clarification as to why incorrect language causes a problem.
Wilco: Clarification has been added
MaryJo: Did we discuss Romain's issue last time?
Wilco: Yes. There is an open issue
MaryJo: Implementation data. Kathy, was this issue resolved?
... Kathy noted that there was a failed example and opened issue in Github. Failed example 2 should not fail since rule checks the root page language
Wilco: I did look at this. I am not fully understanding the format. My understanding is that this does not meet the requirements.
Kasper: Not technically valid. Cannot have a single tag that is syntactically invalid. If a lang tag does not follow syntax, it may not pass correctly
kathy: requirement is for the primary subtag, e.g. en is the primary subtag. The rule is only checking the primary subtag. The follow on is not the primary subtag.
Kasper: It's really about the syntax of the entire string.
kathy: It seems that the wording is not checking the same thing
Kasper: Testing the syntax in PCP 47. It has to be syntactically valid
kathy: Should the rule state that the tag needs to be syntactically valid?
Kasper: It does both. The assumption is that the tag is valid.
Wilco: Could potentially say both things in the expectations to make it clearer.
Kasper: Yes. It is hidden away.
Wilco: It could be that accessible technologies don't follow this syntax, they may be parsing a different mechanism than PCP 47.
Kasper: That is a scenario that is hard to anticipate
Wilco: We know if you follow PCP 47 this will work
... Kathy, does this help?
kathy: I need to take some times to check this. We only check the primary subtag for the language
... We only check the "en"
Wilco: Whatever is before the dash
kathy: We test against the IANA listing of tags
Wilco: Right, so you check the existence but not confirm the PCP 47 syntax
... What matters is that it works
... It has to follow some syntax
... There might be screen readers that still work
... role="text" works but it's not standard so not a good idea
MaryJo: Should be using fully valid syntax
kathy: Please send me a link to the resource with the additional requirement.
MaryJo: WE need to state this requirement in the rule as well as part of the expectations. Do we have a GitHub issue?
... This rule, the failed example, it fails because of an invalid tag
Wilco: Right because it doesn't follow PCP 47
... Yes. It is part of the expectations
... We could split up the definition.
MaryJo: Did we address Romain's question last time regarding consistent with WCAG. What about grandfather tags?
... Is there anything additional we need to worry about?
Wilco: Don't see any reason that they wouldn't be allowed
MaryJo: No more open issues
... Readiness for publishing?
... What about minor changes?
Wilco: They have been merged
MaryJo: I don't see anything else holding this up?
Wilco: We're just pending Kathy's analysis
MaryJo: Open issue on the assumption. Also from Charu, in what other ways can iframe be used.
Wilco: We can clarify assumptions.
MaryJo: Do we have an open issue for that
Wilco: I'll make sure that there is
MaryJo: Implementation data. Charu, Should we add an example when iframe is used for presentation?
Wilco: I don't think that should be ignored. Whether or not iframes need ... Firefox puts focus on them. Putting role=presentation doesn't keep it out of focus you need none an tabindex on it.
... Potentially could be added to the rule. Right now iframes used for presentation are inapplicable. Could update it to make it more accurate.
MaryJo: I think that would help.
Wilco: I'm okay with rule as is but if people want the change...
MaryJo: I think this is an important change.
Wilco: Can you open an issue?
MaryJo will open an issue for this one on the Community Group
MaryJo: We also have Trusted Tester implementation.
Wilco: Data not in yet
MaryJo: Use proper case in applicability section. We covered this last time.
... Any other questions? Nothing else new.
kathy: Looking at Trevor's comment in #7. I had the same question regarding bypass blocks. Bypass blocks does talk about adding a title to iframe but not clear why it is mentioned.
Wilco: H64 mentions it. Using title attributes on iframe elements
kathy: Is it common?
Wilco: No.
... But it is consistent with understanding document. We could raise an issue to remove this from the understanding document with the AGWG. I can take it of the rule. Anyone else willing to raise issue with AG?
... I guess I will open the issue with the AG : )
MaryJo: Any other raised concerns that need to be addressed before publishing this one?
... What about stating why more tests are needed?
Wilco: I think this is true for all rules. We can document that better.
MaryJo: Yes. When we have more rules it will be easier to see big picture.
... At the end of our agenda. Thanks everyone.