<Wilco> https://github.com/w3c/wcag-act/pull/313/files
Wilco: First topic is this pull request I have been tweaking
... The feedback I got from last meeting was that the relationship to a specific standard should be made a proporty
... and it shouldn't necessarily be tied to a W3C standard
... I have only just pushed it
... Besides a few editorials, what do you think?
... Anne, is this in line with what you were thinking?
Anne: Yes
Shadi: I think conceptually this is great
... One suggestion is to make the first paragraph a definition and move it out of that section would be great. Having a definition for Accessibility Requirement would be great.
... European Accessibility Directive might not be a good example, but this can be fixed after CR
... What needs to be fixed before CR are the SHOULD requirement on line 118
... and maybe the ID...
... We can refer to techniques now. The *not required* are in there very clearly now, which I like
Wilco: If I put in an example for the SHOULD requirement on line 118, woudl that help?
Shadi: Would it be difficult to decide the conditions for when a rule must list a requirement and when it shouldn't?
Wilco: I don't know that we know all the conditions for when a requirement must be included
... We don't know all of the accessibility requirements that exists and could potentially be included
Shadi: I just wasn't aware that it was the case
... One case is that it is an atomic rule in a composite rule, and it doesn't map directly to a requirement
... Another case is that it is a best practice
Wilco: We haven't defined Best Practice
Shadi: You have included a paragraph about when it MUST NOT include an accessibility requirement
... And then there are the best practices
... Which other rules should not include an accessibility requirement?
Wilco: This is about each accessibility requirement that is not satisfied. And there could be indefinitely many out there
Anne: Could it be something about "that the rule is intended to test for"
Wilco: That is too much relying on the intent of the designer, it is not objective
Shadi: "must test each accessibility requirement that it is designed to test for"
... at the time of writing the rule, you know what you are meaning to test for
Wilco: Is it possible to make a MUST for an intention?
Shadi: So let's see what happens: I have a rule and test for an accessibility requirement, and the logic doesn't match. Then it doesn't test for the requirement...
... Maybe we can steer away from the word "intention". "An ACT Rule MUST list the accessibility requirements for what it was designed to test for"
Anne: Is this so different from not knowing all possible edge cases or accessibility support issues when writing the rule, and then having them reported in as issues later?
<Wilco> For each accessibility standard that an ACT rule is required to test, the rule MUST list each accessibility requirement that is not satisfied when the outcome of the rule is `failed`.
Shadi: It's different, this is an unfulfillable requirement
... How about "An ACT Rule must list at least one accessibility requirement that it was designed to test for, except if..."
Wilco: I like mine better
Anne: I like Shadi's
<Wilco> For each accessibility standard that an ACT rule is designed to test, the rule MUST list all accessibility requirements that are not satisfied when the outcome of the rule is `failed`.
Wilco: but if you create a rule for WCAG, it should list all of the success criteria that it was meant to test for
... We need the part "that is not satisfied when the outcome of the rule is `failed`."
Anne: I think it's important to mention that it has to be consistent within the standard that the rule is designed to test for
... maybe something about "at least one standard"...
Wilco: I don't see why my proposal isn't doing that
Anne: All right, I agree
Shadi: I am just thrown off by the wording a bit, the "for each...". Maybe a clarification or an example will help. I am not sure everyone will read that sentence the same way
<Wilco> An ACT Rule MUST be designed as a test for one or more accessibility standard or document. the rule MUST list all accessibility requirements from the standard(s) that are not satisfied when the outcome of the rule is `failed`.
Shadi: But I don't have a better proposal right now
Wilco: I have broken it up in two sentences now
... Am I getting warmer?
<Wilco> When an ACT Rule is be designed as a test for one or more accessibility standard or document, the rule MUST list all accessibility requirements from the standard(s) that are not satisfied when the outcome of the rule is `failed`.
Wilco: But will it ever not be designed to test for a standard?
Trevor: When it is a best practice
Shadi: Or an atomic rule in a composite rule
... I think you can add a sentence of clarification. "It is designed to test the conformance to one or more accessibility standards..."
... This means there are rules that are not designed to test the conformance, as Trevor was saying. It's the very last example
... Maybe there should be a definition of accessibility standard or document in this context. Something that sets technical provisions
Wilco: In the first paragraph it says "... that must be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation"
Shadi: Maybe you could use "accessibility document" for the definition. Or just "document", it doesn't have to be accessibility...
Wilco: We have scoped it to *accessibility* requirements
... But it could be "accessibility requirements document"
<Wilco> When an ACT Rule is be designed as to test the conformance to one or more Accessibility requirements documents, the rule MUST list all accessibility requirements from the document(s) that are not satisfied when the outcome of the rule is `failed`.
Wilco: And you also want a definition of accessibility requirements?
Shadi: Yes. Maybe just taking out the first paragraph
Wilco: Anything else, except editorials?
Shadi: Are you sure about the technique H37, that the outcome is "satisfied" when the technique is inapplicable?
Anne: I am also unsure about the passed to satisfied mapping
... but the mapping is to the technique, not the success criterion, so I guess it is fine
Wilco: I will make some more updates before next week so that we can get closer to CR
Wilco: So I am not sure what this is about
Anne: I think it is from what we discussed at TPAC, that we needed a brief introduction to what an ACT Rule is
Wilco: I don't think this piece does that. It is more of a paragraph version of a list later in the document
Trevor: At the first pass, I didn't mind it, but now you are saying it...
Moe: I like parts of it. Maybe we could shorten it and link out to the rule structure
... I think the issue was that we never really introduced what an ACT Rule is
... I think there is really good stuff in here, maybe we need some restructuring
Wilco: So feedback to Mary Jo is to take out some of the details
Moe: I will write Mary Jo
Wilco: That was the end of the agenda
... What do we want to do with the 3 pull requests for accessibility requirements?
Shadi: I think mine has been addressed
Anne: Mine too. We can always close them, they won't disappear
Wilco: I am closing them
... There are a couple of other issues open to resolve before CR, but it seems like we are close to wrapping up the accessibility requirements one, that was the really tough one
... We are aiming at sending out the agenda Tuesday