<Wilco> https://github.com/w3c/wcag-act/pull/200/files?diff=split
Mary Jo, the paragraph talks about AT as accessibility support, whereas the other part is talking about the user agent too with reference to accessibility support in WCAG
<shadi> [[ACT Rules are designed to test the conformance of web content to accessibility requirements.]]
Wilco, could we just say all ATs and user agents?
<Wilco> "assistive technologies" -> "assistive technologies or user agent"
Wilco: conclusion: replace with Assistive
technologies or user agents
... conformance in web technologies as opposed to in the application of
web technologies
<shadi> [[ACT Rules are designed to test the conformance of content using web technologies to accessibility requirements.]]
Wilco, replace with "built with"
Shadi, suggest using the feature rather than "part"
Shadi, The first sentence still sounds very clumsy, so I put in some editorial changes in IRC
Wilco, I like the second suggestion. It needs web technologies as it leads into the next sentence that talks of parts or now features of web technologies
Anthony, Agree with the second suggestion
Anthony, can fix by next week (last agenda topic)
<Wilco> https://github.com/w3c/wcag-act/pull/210/files?diff=split
Wilco, survey closed but PR 210 still open. A lot of editorial work. The general topic was versioned links or not. Pointing to SVG 2 or SVG etc
Wilco, there seem to be some inconsistencies still
Moe, Haven''t had a chance to review the feedback from last week. Three open questions. When we do call up a specification you will often see that normative are in brackets. I was having trouble with the tags when embedding in the document. Bikeshed would give me errors because not all had unversioned tags.
Moe, especially with CSS things started splitting. Trying to figure out...agree it would be good if we had non-versioned tags. Could someone on the Bikeshed team help us with that?
Shadi, this seems to be more of a editing technicality which I will look into
Shadi, unless we do not really need to point to a specific version I prefer not to
Moe, there are two parts. The link to the document - those all had unversioned copies. Then there is the biblio, the normative references get pulled in by the tag in brackets and then Bikeshed automatically pulls in the cross reference. Not all of these have non-versioned versions. Suggest coming up with a list of tags without non-versioned links
Shadi, we''ll contact Bikeshed guys to see if we can have them added
<shadi> https://www.w3.org/WAI/standards-guidelines/wcag/
Shadi, missed by scribe
Moe, I can put in an example of an index page that deviates from what we have done in other specs where we link to the TR.
<shadi> https://www.w3.org/WAI/standards-guidelines/wcag/
<shadi> https://www.w3.org/WAI/standards-guidelines/uaag/
Wilco, these are just WAI-pages, right?
Shadi, these are only for the WAI-spec
<MoeKraft> https://www.w3.org/TR/WCAG/
<shadi> https://www.w3.org/WAI/standards-guidelines/aria/
<shadi> +1 good idea Moe
<Wilco> +1
<MoeKraft> +1
refer to the non-versioned link.
Wilco, can you raise a separate issue, mo, so we can merge this in?
Moe, Shadi commented should we go to quick ref vs. SC. Your recommendation was to go to the quick ref. That is a question I need answered
Wilco, Why would we link this to the quick ref?
<MoeKraft> https://www.w3.org/WAI/WCAG20/quickref/#text-equiv-all
Shadi, the quick ref is more usable to people who are new to the subject matter. They can see all things in one place.
Wilco, I''m ok either way
+1 to quick ref
Wilco, quick ref it is
<MoeKraft> +1 quickref
Wilco, first comment: a fail in a rule doesn't need a fail for an accessibility requirement.
Anne, if you misread it, I am worried that others can do the same thing
Wilco, we could tweak it a little bit. I would propose we change this to say (pasted in IRC)
<Wilco> e.g. a rule not in a group only returns the outcome Fail when the content fails the accessibility requirement.
instead of saying aggregated outcomes, we can say the outcome of the aggregated group.
Wilco, question: Should the aggregation groups them selves be associated with the accessibility requirement? Now it seems inferred
Romain, Aggregation groups shouldn't be promoted to be rules themselves. That would simplify things. I created this issue 214.
Wilco, what other things would we need a rule group to have then?
Wilco, it doesn't need applicability or expectations, and test cases?
Romain, for some groups I would think the applicability would be the same for all the rules in the group. That MAY be the case. It might simplify the definition of the output format as well
Romain, Since groups must be considered as a whole when looking for the outcome. Every time the spec or the tool has to look for outcome we have to distinguish whether the outcome is from a rule or a group of rules
Romain, we have the same issue here. Almost the same text for the rule and for the rule group, so we have to make the distinction. If the group was to be considered as a rule in itself this distinction doesn't have to be made
Wilco, we should try to avoid having super nested rules - rule inside of rule inside of another rule.
Romaine, this nested thing can be avoided by just limiting the nested depth to two levels. - either an atomic rule or an atomic rule.
Anne, it is really interesting. A lot of the things we have for rules would also be useful for rule groups. Expectations I guess would be a way to express which rules you need to pass for the rule group to pass.
Anne, we need a term to define which rules are only a part of a rule group because they do not have to map directly to an accessibility requirement
Anne, would be interesting to follow the idea to see if it is possible
Romain, I think if we say that a composed rule or rule group has to map to a requirement we can say that a rule either has to map to or inherent a requirement.
Anne, if you have a rule in two different rule groups but mapping to different requirements...
Anne, would be interesting with the idea of inheriting from the rule group
+1
Anne, we didn''t change this because it is nice to have as meta date which SC or accessibility requirements it is related to
Wilco, we are close to the last draft so we need to get it done in the next week or two so will need to hammer this thing out pretty soon.
Wilco, we can put together a small group to come up with a proposal and bring it to the meeting by next week
Romain, make a fully described proposal rather than a PR to the spec
Wilco, I''m volunteering, but need more people.
Romain, interested to contribute, but unsure of availability
Anne, I don''t think we do have time from the Siteimprove side
Stein Erik, Siteimprove contributes as well
<rdeltour> for the record, issue #214 is the one containing some early thoughts about replacing rule groups by "composed rules"
<rdeltour> https://github.com/w3c/wcag-act/issues/214
Jey volunteers as well
Wilco, other comments to our new sub taskforce?
<Wilco> https://github.com/w3c/wcag-act/pull/212/files?diff=split
Wilco, some editorial comments on this one.
Wilco, this should be WCAG 2.0. There is no guarantee that SC numbering won''t change.
Anne, I'm fine
+1
Anne, we should align the SC names directly with WCAG
Wilco, let''s put in a proper short name. Romaine, up for doing that?
Romain, cannot put the name in parenthesis because the names themselves have parenthesis to ensure readability
Wilco, any other comments?
Wilco, Romaine feel free to merge this in
Wilco, looks good
+1
<anne_thyme> +1
<shadi> +1
<Jey> +1
<rdeltour> +1
<MoeKraft> +1
<cpandhi> +1
<maryjom> +1