SES: introduction to proposed section: adding an optional information section to the structure
WF: Should accessibility support be an optional - it is using the word should
... optional things are useful things, but the should part absolutely should be there, but exception if certain information is missing
WF We shouldn't use a must on parts that could be unknown
SAS: Let me clarify. We MUST have the accessibility suport section in every rule, but it may be empty or incomplete. Or these are the accessibility support limitations that I know of as rule author, but that would be a must requirement. If it is completely optional I could have a rule without that section at all.
... Same applies for assumptions. If there are no assumptions, do I leave the section out or say there are no assumptions
WF: See what you mean
SES: It is fair to say a section is compulsory, but it is possible to let it open
WF: I think accessibility requirements and support should be a MUST, but possible to leave blank or with none
RESOLUTION: ATH and SES will change pull request
SAS: We could add a sentence saying that it is possible to leave the section blank
... I don't particularly like having this optional section. There will now be two things left after the agreed edits. Suggests removing the part about may include in the structure section
... Would be a good thing to put (optional) after headings that are in fact optional
ATH: Asks for clarification
SAS: The section called optional items with the sub level.
ATH: We could just leave it out and remove the extra layer.
<Wilco> https://github.com/w3c/wcag-act/issues/301
WF: Tried to break down this discussion to separate questions.
WF: First one is best practices and relation to WCAG SC. Things that are considered good practice.
WF: Can we use the background section for this to resolve it
ATH: I'd like to see something that allows structured data, not free text fields..
WF: What is the relations hip between a best practice and a SC
<shadi> scribe: trevor
shadi: My question is, when we talk about relationship. Relationship between outcome of the rule and thing we are testing, or thing we are testing and success criteria
... Lets say we are testing no heading levels have been skipped. We all agree this is an advisory technique.
anne: Couldn't we talk about both, the types of relationships will be similar. And we don't need it to be perfect
wilco: I see two categories of relationships. Either directly testing a thing, or thematically related to thing
... Failing rule means you failed the thing. Thematic is everything else such as same types of technologies, similar techniques etc.
anne: I disagree there are only those two types of relationships. For example, we have the html passing. If we have a passing requirement, there are specific ways to fail, but if you pass the advisory you may pass another.
... Just saying that because a rule fails means the success criterion failed is too simplistic
wilco: We defined a rule as being failure test. Failing a test means failing a sc
... Allowing rules as passing things is a significant scope change for the rules format
anne: I agree, but we have changed so many things in this direction I am surprised that is still our scope
<Wilco> https://w3c.github.io/wcag-act/act-fr-reqs.html
<Wilco> https://w3c.github.io/wcag-act/act-fr-reqs.html#rules-test-for-failures
wilco: This is the requirements document from way back when we started
shadi: what is the consequence of changing the scope? What would we break
wilco: I don't know the answer, which makes it hard to change
... An example would be having valid html. You could have valid or invalid html that passes the parsing requirements
shadi: Would that be a problem or a change?
wilco: That would be a problem, it confuses the actual requirement
... If you had a rule that said the page has no video, it could be a valid rule for the video success criteria
... If it has no video you pass, if it does you fail. If we drop the failure stuff, you could write rules like that and you could mix up applicability with expectations
... We would be releasing a restraint we have been using to achieve consistency in rules
anne: I don't see it as such a problem
stein: still two types. Explicit and more loose relations. Wilco has a fair point. In the case of the video you wouldn't list any sc, but could have another section. Having people create creative rules isn't a bad thing
wilco: I do see the use case for what Anne is pointing out. There is an interesting one for extended audio and contrast where a passing a rule means you pass a lower level rule as well.
... I am nervous to let go of that completely, since we have definitions of what is in applicability and expectation. How many constraints may we lose?
anne: I don't think there is any problem with that.
stein: I agree that we should change applicability and expectation.
wilco: If we let go of the constraint, it allows you to do the same thing in more than one way.
... I think the more variations in how you allow a rule to be written, the harder to standardize the rules
anne: I think we already have that today
... As I see the rule format is one thing, but there should be some vetting process for rules added to WCAG
stein: Lets see if we can get closer to resolution. Should we change words in expectations and applicability
wilco: No I think thats good
... I think sticking with background info and mapping failure to failure
stein: Could it be helped by adding more to background information
anne: The accessibility requirements section still needs a rewrite correct?
wilco: Yes, we have reached an agreement that changes will need to be made.
anne: My issue with all of this, is that the failure to failure relationship does not stand out as better than a pass to pass relationship
anne; I think the accessibility requirements only contains those, needs to explain why that mapping above all other mappings
wilco: That we can do.
anne: I don't know, the accessibility requirements list doesn't really say anything about it. Its not just the accessibility requirements. These are specifically the non-conformance mappings
... I think it could be made clearer, maybe even in the title of the section
shadi: I still don't understand why the non-conformance is more important. But I understand why wilco wants the rules to be clean.
... there are examples for when passes that are reflected onto other rules can be useful
wilco: I will write this up better later. But i see it for consistency.
... There are some rules that do not map directly to sc but are required for wcag.
anne: I completely agree, but my vision of a solution is that people write the rules as ACT rules, and then look at their rule suite applies to wcag test
stein: I agree as well. If you can make it clear that their is a clear relationship of passing and then have to take extra steps to make sure people are writing high quality rules.
shadi: I think there are failures that equally cause problems. With fail to fail, there are still some methodologies that have incorrect interpretations
... I think we need to address both aspects of documenting things the group agrees on that are failures and passes
... I think the pass will be much less than the fail, but would still be noticeable
wilco: Let me finish up on this, and let me think if I am okay dropping this, and we need to follow up on this next week.
stein: We should also think about some compromise solutions.