WF: not as far as I had hoped
... updating ACT-R rules to the latest format
... slightly behind schedule
... hope to complete by the end of the day today
... would use that to fill our list of rules for the exit criteria
... need the e-pub rule
RD: ready by next week
WF: need a second manual methodology
SAZ: could check with some people
WF: fall-back could use Deque methodology
<Wilco> https://www.w3.org/2002/09/wbs/35422/ACT-rules-process/results
WF: survey in AGWG on proposed rules publishing process
... question about 3-step model
... was explained during the call
... also discussion about adding pages to the WAI website
... will be first publishing ACT Rules
... then looking at integrating them later on
<scribe> ...on-going project to redesign supplemental WCAG guidance
https://w3c.github.io/manual-of-style/
[agreement]
[agreement]
[agreement]
[appreciation for positive feedback]
AG: for example, no standard definition for accessibility tree
... could have different implementations for the same accessibility tree
WF: good point
AG: collection of show-case implementations of an accessibility tree
WF: how does that issue relate to the ACT Rules Format spec?
AG: guess does not need change to the spec but something we need to work on
WF: agree, maybe this should go to the ACT-R community group
AG: whatever group picks this up, we would want to contribute to it
... also relates to shadow DOM implementations
... all these areas need work in my opinion
WF: maybe also for the additional aspects note we have
[updates to the Note may be needed]
AG: with the extent of questions I had, maybe need better example
... like the one in my email
... other issue is that different implementations have different outputs
WF: JSON-LD allows you to frame the input automatically in the structure you need
AG: makes sense, but still need simpler example
WF: wo
... working on updated documentation on the ACT-R website
AG: yes, not the easiest documentation
[add another example based on Alistair's suggestion]
AG: the tests we write in our engine are very atomic
... which need to be combined together to become "atomic" as defined by the spec
... so we have 3-4 chains of composite rules
... but spec does not allow that
WF: reason for not allowing cascaded composite rules to be less tied to specific implementations
AG: makes it difficult for us to bring in our rules
WF: has been in the spec since the beginning
AG: yes, but didn't pop-up during reading only during implementation
... want to use this format internally
... for example rule on Button is not really atomic
WF: really depends on abstraction level
AG: want rule that addresses entire success criterion
WF: don't need rules to aggregate results
AG: isn't that the output mapping section in the spec?
WF: outcomes could apply to atomic rules too
AG: would expect rule for each success criterion
... could live with it for now, but could revisit in a future version
WF: could also add a note clarifying that aggregation within implementations is fine
AG: also here, happy to take this to next version