From previous meeting ; research into different page / component states
Carlos proposes :
Carlos, lionel, trevor , jean yves , will have met 5 times and have come up with a proposal for how to check states for ACT rules
State element has greater impacts than expected, (CSS styling, aria attributs, DOM effects, or user actions)
Many are represented through css pseudos. Css is well defined. But the JS not so (for ACT rule writing)
Transitions between states need to be addressed (as opposed to beginning or end states)
1. consider only states that can be defined by css pseudo classes matching an element (ex: hover )
because states effect applicability and expectations, they need to be declared (and this applies to transitions)
2. new subheading to applicabilty : new states and transitions : in hte applicable case this section will enumerate
-- the combination of pseudo classes that match
--- missed :(
3. for expectations , add subheading "Expected states and transitions" and should liste
--combination of css pseudos
-- transistions between matching pseudo classes
While applying the above to some existing rules, some rules are applicable in all states, but some states are more important than others (example inline link in p)
in such instances, applicability to all states (in applicability section) but in the background section suggestion of where to test in particular
Test Cases : exponential explosion if all pseudo classes are combined . So, not a test for each combination, but reasonable number with most combination of states, as current practice
Trevor proposes an example
<bruce_bailey> Where is the bit about being limited to link states as described in the CCS spec?
<bruce_bailey> I am not sure I got that correct.
<Wilco> https://docs.google.com/document/d/1f7646sT2PQcR9qDLeLJQoedYjpNDrO8vFpNm_m1tktg/edit?usp=sharing
wilco: why specifically css selectors and not an objective measure of state ?
trevor: tried a few things, looked at aria states ... no comprehensive list found ; complex states seemed to be too intangible
therefore, stayed with css pseudos as a stable and reliable fall back
Lionel: objective, predictable, but also limiting the space ; ruled out JS provoked states because too wide ; css states useful and significant
Anne: back when act rules was almost pseudo code, the introduction of these css states seems to be too complicated for the ACT rules
Jean Yves : but it's only pseudo classes, so less complicated ; couild be a problem with pdf though
Carlos: definitions can be written (like for hover) that match the state ; no need to introduce the css terms themselves .
Objective definitions of state are welcome !
<SusanH> I have to drop now for another mtg
Wilco: survey for more feedback
Trevor and Wilco : finite number of states
<Wilco> https://www.w3.org/2002/09/wbs/1/act-process-03-2021/results
ACT review process to be combined group (not 2 different processes)
Also: moving to a single website for published rules
<Wilco> https://github.com/w3c/wcag-act/pull/515#issue-597990695
Non approved elements would be considered in pre-published state
<Wilco> https://www.w3.org/2002/09/wbs/1/act-process-03-2021/results
Reponses to comments in the survey (11 responses, with many comments)
(responses in survey)
Shadi's comment. Wilco : it needs to be in a place where reviewers can see it . Moving hte section and renaming the publish approval OK
<Wilco> https://github.com/w3c/wcag-act/pull/515/files#r601459007
<bruce_bailey> thanks, sounds good to me
Bruce's comment. Wilco : not in doc , what is editorial ? (decided between authour and reviewers) authour suggests, reviewers approve (or not)
Kathy's. Wilco : precision needed on comment ? Kathy : order needs changing ? (without changing meaning). putting editorial into the 2nd place to avoid having to go further . Confusion due to page layout (Wilco) . OK
<Wilco> https://github.com/w3c/wcag-act/pull/515/files#r601548419
precision about the creator of a draft proposal (modified by W)
Trevor's comment : "call for implementation" ? Wilco : implementers will get the mail, so OK. Shadi : rule will be published with a proposed label, but also could have a note seeking implementations, explicit
agreement
john's suggestion (implementations) ; Wilco : this is an old subject we should take offline
Bruce's comment (question 4) "annual review very ambitious" . Wilco : i expect it will be manageable ; Shadi : need to distinguish the two types of review (review and "check up")
Bruce agrees, soften language could be a good thing. Don't put the bar too high;
Kathy's . Wilco : more for the implementation tracker than the rule process itself
Susan's comment : also about the annual review process.
Wilco to Jean Yves : taskforce needs at least one implementation for a rule to go to AG (formerly 2 implementaions, but not complete). 1 complete implementation is necessary to show that each test case can be tested consistently
Jean Yves : decision to be perhaps dicsused in the community group ; (old choices to look over)
<shadi> +1 to Anne's point
Anne: who is the liaison
... questions about complete implementations
a complete implementation is an implementation without "cant tell"
Wilco: precision that the implementation is not a complete implementation
Daniel: should comment approval be annotated ? (is extra feed back necessary) . Wilco : approval is about PR, avoiding mutliple feedbacks
<Wilco> PROPOSED RESOLUTION: Process update accepted after editorial changes are made
<bruce_bailey> +1
<CarlosD> +1
+1
<trevor> +1
<anne_thyme_> +1
<kathyeng> +1
<Daniel> +1
<Jean-Yves> +1
<Will_c> +1
<Lionel_Wolberger> +1
RESOLUTION: Process update accepted after editorial changes are made