wilco: I have been prepping for CR over the last week.
... Working on making sure consistency while not restricting implementations
<Wilco> https://github.com/w3c/wcag-act/pull/283/files?utf8=%E2%9C%93&diff=split&w=1
shadi: Generally, I do not think we should be talking about using accessibility requirements. Atomic rules are for small and composite round up a few
... but they don't necessarily have a relation to an accessibility requirement
wilco: So basically this needs to be rewritten to not talk about accessibility requirements
... Will make amends and have Shadi look over them
kathy: so basically this allows for rules on best practices?
wilco: Yes
kathy: Atomic rules can be best practices, so composite rules can be as well
*viewing rdeltour comment on separation of responsibility on atomic and composite rules*
wilco: that doesn't seem like a note
shadi: usually it is in notes, but since our spec is more conversational I think it is fine to leave it in the spec
... The atomic test rules are defined as testing web content in a particular solution, but it may not be the case
wilco: discuss earlier in the scope that we are focused on web technology but that it can maybe be applied to other technologies.
<Wilco> https://github.com/w3c/wcag-act/pull/283/files?utf8=%E2%9C%93&diff=split&w=1#r224158592
*viewing shadi comment on how composite rules must identify accessibility requirement*
wilco: this is same as the comment above. Need to remove link to evaluation instructions
*shadi comment on changing to a sub-section*
shadi: in my mind this deserves a small sub-section
wilco: i didn't do it since then it would have just a single sub section, but I don't feel strongly about it
... should we have two sub-sections one for the list and one for the mapping
shadi: that is fine by me
<Wilco> https://github.com/w3c/wcag-act/pull/283/files?utf8=%E2%9C%93&diff=split&w=1#r224055879
wilco: Does the previous proposal "applicability of a composite rule is defined as the union..." is that a requirement?
shadi: We need a lawyer :p, just doing a definition, but maybe not a requirement for the rule author. No consequence, just spec definition is wrong
... new way means that the author would have done something wrong
wilco: which I think it should be
shadi: I think rdeltour is asking if it is testable and feasible for authors
wilco: I believe that it is testable
shadi: He is looking at it from an implementation side. Thus you could create an algorithm to generate the applicability
jey: if we use defined as then there is no room for misinterpretation
wilco: they may omit the applicability
shadi: what if they have a mistake
wilco: then they did not follow the rules format
shadi: If you say it as defined as such, then it provides a clear way to create the applicability
wilco: I don't see how it changes with a must.
... If they want to write it down, then it MUST be a union.
jay: I think we should leave it as MUST
shadi: So if it can be inferred, then why are we asking the authors, there may be a more effective way of generating the applicability
... They may omit applicability, why shouldn't they omit it
wilco: For the sake of a more readable rule
shadi: I would rephrase the entire thing. I want to be clear of what the requirement is for the rule author and the rule reader
wilco: Leave the first sentence as defined as, for the sentence with MAY also talk about union of applicability
shadi: There is going to be repetition that needs a bit more thinking about. I will take a stab at it seperatly
wilco: my vote is that we leave it
shadi: We could leave it, because I am not hearing a change to the requirement so this could be considered editorial
wilco: I think we need to have a MUST in there, how we do the editorial part can be up for discussion
kathy: I think there is a typo on the naming of some images
wilco: yes, will change it
https://github.com/w3c/wcag-act/pull/283/files#r223424484
*shadi comment on evaluating"
^^ correction on removing paragraph about evaluating
wilco: it doesn't really add any requirements. I don't have a problem removing this
... alright, we will take it out, and objections
... that is the last comment on this, i do want to outline the next steps
... So this is the document that will be going into CR. What I want to do is some final editorials that I will do later today or early tomorrow
... Then I will put out a poll for consensus to publish
... Then we will need to talk to AG
... I haven't talked with alastair but we were trying to get a slot on tuesdays agenda
... they also have a call on thursday we could do
shadi: I think it would be good to give them a heads up, about what we have done and what we are trying to do.
wilco: Then it will be up to the AG chairs to decide if the want to look at publication before/after TPAC
... I think at the latest we would publish a week after TPAC
... after we get through CR, we will be into exit criteria and have to prove our rules format does what we think it does
... jey has been working on looking at what we can record
jey: we have a pr open for implementations, but nothing to present right now
wilco: jey is working on a system where we can track how many implementations we have of a particular rule
... How that works is people can submit a manifest file that shows which rules they implemented. They will be required to have outcomes/results for their test cases
... for manual you won't have to can just say it is in the work flow. manifest will include info on if the rule is automated, semi-automated, or manual
... that is pretty much were we are heading next. The next thing that will happen is we have been talking to ag to publish our rules as w3c resources.
... We have been looking at requirements for rules to be published AG
... I am hoping that by jan to march we will be able to push some rules, and have them implemented, and then publish them as a resource
shadi: when we developed that plan we assumed we would be in CR. Assuming we have the spec what is the process for having the rules published
... Michaels opinion is that we might be over loading the group
... having the first discussion on tuesday, they will need some more hand holding, they may not have read the spec, and some more explaining
... describe exactly what we are trying to do, and what has been changed
... then we can talk about next steps about adopting and publishing rules
wilco: kathy, have you thought about starting to use some of the rules in auto-wcag
kathy: we haven't, but I think that is going to be an effort in the future in incorporating into trusted tester sooner
<shadi_> https://github.com/w3c/wcag-act/pull/283/files#r224452566
wilco: been trying to reach out to people to see when they may be able to incorporate some of the rules
shadi: what do you mean rule authors may add a description for a rules applicability
^^ sorry that was wilco
shadi: Instead of saying they can omit it, add more specific language as to what they can do with the applicability
wilco: I am okay with this
shadi: I think there is fallback here. I think implementors can go back to the definition if necessary
<Wilco> https://github.com/w3c/wcag-act/pull/283
wilco: one thing not closed is the exit criteria
shadi: I think having a CFC makes sense
wilco: I will send that out as well.
... we can't change it any more if we are going CFC tomorrow
shadi: is it a normative reference
... I think we are making reference to a normative spec
wilco: Then i am removing this for CR label from the issue
... from issue 216