WF: asked AG for CFC
... not sure it happened yet
... will remind the Chairs
WF: follow up from previous calls
... concluded most notes could probably be removed
... suggest we go through the currently published rules
... people agree?
TB: fine by me
[no disagreement]
WF: so let's divide up the work then
<Wilco> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/Rule_Publication_Tracking
WF: maybe keep the same assignees?
... open issue or PR?
... or work on it, here then send it to the CG?
MJM: maybe better to agree here first, then send it to CG
... so that it doesn't go back and forth
KE: rules marked published?
WF: AGWG ready and published ones
... can we do it by next week?
MJM: potentially, will try by wednesday
WF: let's do 2 weeks?
[no disagreement]
<trevor> shadi: Updated based on the last discussion. There were some changes in the "rules are informative" part to make it more clear. Also modified the rules mapping and changed a bit of structure
<trevor> shadi: It points back to the spec, it should give a good overview
me thx trevor
WF: wonder if should open survey for this?
MJM: also other mock-ups from shadi
SAZ: mock-up of Understanding Page Title and of Technique H25
<maryjom> https://w3c.github.io/wcag-act/understanding-act-rules.html
WF: straight-forward adding of a small list
MJM: looks clear
WF: ok, let's get it onto a survey
... maybe for next week
... also prepared JSON file for Michael Cooper
... to help integrate rules into WCAG support documents
WF: editorial commend from MJM can be implemented
... TB, what would you change to address your comment?
TB: make it explicit what we are checking
... right now seems ambiguous
WF: where would you put this?
TB: at the end, where we state it is applicable
... add to say because it exists, not because of value
WF: ok, get it. can do that
... next comment from me
... isn't a WCAG rules
SAZ: are we publishing this?
WF: why not?
SAZ: because it needs of work to clearly explain and distinguish
WF: said we'd review but then put on hold
[agreement]
WF: next comment from MJM
MJM: why not a conformance issues
... it is a way to meet the requirement
WF: passing this rule does not directly mean passing the requirement
... also failing the rule does not necessarily mean failing the requirement
... so not real mapping
... strong indicator but not confirmed
SAZ: think such rules are incredibly useful
... just not for now, as discussed before
WF: next comment from me ... some automation issue
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/1313/files
WF: will fix, also addresses comment from MJM
... next comment from CP
... does it actually help?
SAZ: think technically more precise even if more wordy
WF: does it help overall?
SAZ: if we use consistently
WF: next comment from MJM
... agree technically even not my editorial preference
... suggest we implement all these changes
MJM: also some missing states in the test cases
WF: examples not an exhaustive list
MJM: can't really benchmark that way
WF: difficult to define the drop-off line
... the more tests you have, the more constrained
... suggest to start small and add where we find bugs
SAZ: think need to be careful where to cut off
... might backfire
SAZ: think there are some complex edge-cases
... like some inheritance model, accessibility tree, shadow DOM etc
... but in this case, it is a fixed taxonomy
... easy to create test cases
... and greatly adds to tool consistency
WF: for this rule, not just a list of attributes
... but combination of roles and attributes
... so hundreds if you really want to cover them all
... then you start testing things not really related to the rule
TB: is there a way to split the difference?
... a test subset based on the set MJM listed?
WF: sounds reasonable
MJM: to me too
WF: other question is how many test cases per rule?
TB: depends if we want to go for a unit test approach
... or if just examples to demonstrate understanding
WF: i'm favoring the latter
SAZ: have concerns if we put the bar too high or too low
KE: could this rule be too broad?
WF: not sure
... also image has accessible name does not fully test accessible name calculation
KE: narrowing it to image
... rather than saying "element has accessible name"
... but in this rule we do not narrow the space
TB: will we then have tons of rules?
SAZ: what's wrong with that?
WF: seems arbitrary
SAZ: think we could move forward with this particular rule, since it is non-conformance
... but for conformance rule, would need to agree on level
WF: another comment from MJM
... editorial
... can implement this