Wilco: Chair of CG and TF
... works for Deque
Shadi, W3C staff contact for this TF and CG
Daniel, W3C engaged in the CG, editorials and TF
Carlos, co-chair of the CG with Bill
Ken, team with Chase defining WCAG tests
Lionel, just joining, interested in a11y rules
Danielli: Zag interactive
Jean-Yves Moyen: SiteImprove, writing rules
Kathy: Federal US Access Board, Govt
Sameera: Guardian Life a11y program
Susan: Sigma Healthcare
Trevor: National Govt Mitre Corp, on the TF for a while
Will: Zag Interactive
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1511#issuecomment-759516941
<Danielli> ZAG Interactive-Glastonbury CT-USA
<scribe> Agenda: Today's topic, State and ACT Rules
Wilco: background, Jym77's post above
... should rules describe all the different states that a page can be in?
... the active state, and not consider state beyond the current one, and let users determine teh state?
... or some other way to approach it.
Carlos: We should define state
... considering all the things that a script can do, state can be very hard to define
... what is the scope that we are considering. Allt he states? A subset?
Wilco: State is indeed very broad
... trivial, the color of a link changing on hover
... global, clicking a button and the entire page has new content
... Also, an algorithmic process is likely looking at the whole, and not parts
Carlos: Until now, we looked at the states that we could define from the perspective of selectors
Wilco: Let's look at practice. What do people currently do?
... Tools people, do you write down the states?
Will: We do auditing
... consider a button: hover, focus, etc
... we leave that open to the tester
... buttons can be styled very differently
... [this variance] can leave a hole in the testing
... we do not write it out, leave it up to the testers
Wilco: Do you ever write down state, e.g. hover state, focus state
Will: if you had to write it out you could be testing
Susan: we do write it out for developers, qa, people not fully trained who do not understand all the conformance rules
... on widgets, likely easy to stay in the state desired as you cannot anticipate every state
<Will_C> sorry for jumping the queue!
Jean: Mixed feeling. On the one hand, easier to just look at the page
... especially as we can then ignore the effects of various scripts, "this scripts and what did it change"
... but there are pitfalls
... 1] less consistency. 1 tool may do state changes that another tool does not do
... an important goal is tool consistency of results
... 2] there are cases where state agnostic will not work, e.g. focus! When you are checking focus, you have to be aware of the focus state
... another example: are there elements that should not be focusable, and there is redirected focus
... the redirection happened in a script, the rule cannot just look at the focus order, it has to test if it is possible to put the element into the focus state
<Will_C> ...lionel: manual testers and automated tools
<Wilco> Lionel - Since you're asking for info from the field, for QA we will tell them to investigate states so they know what to expect.
<Will_C> thanks
<Wilco> -...When it comes to automated tools, they have to be aware of desired states and have algorithms around that.
Ken: I have a FE perspective
... need a solid automation strategy
... need to provide assurance that functionality is not only tested, but undergoes regression testing
... using axe as part of automation ...example: open the FE widgets, run axe
... sometimes there was not enough on the page to get meaningful results
... developed a state mapping, and a web driver (also on native) to drive the widget into every state that can be predicted, then test in those states
... e.g., selected, not selected
... e.g., a dialog opens and causes a contrast issue (that's an unpredicted state)
... overall to avoid the whole-page challenge, we test distinct widgets broken down
Danielli: when there are many employees, they rely on decisions made upstream at the very beginning
... what it should have on focus, not
... the tools verify if the widgets conform
... the key is to work closely with the design department, and design should document these indicators
Kathy: In development of our manual testing process, some of our struggles:
... did not test link colors and the different states, since the colors of each state would contrast against each other
... we did not find colors that conformed
... the wording of WCAG 4.1.2 was tricky. can be programmatically "set" rather than "determinable" was a challenge
Trevor: Like someone mentioned, a web driver
... an automated tool that would figure out which parts of the page are interactive
... ended up defining state as "some change in the content or functionality of the page"
... I advocate, we be explicit for some states
... for a link: test on hover, test on expanded
... for a dropdown, there are more options, so it will be harder
... suggesting a per-widget approach, each widget can have possible states stipulated
Will: Agree with "programmatically determined" vs "programmatically set"
... old adage, I cant define if it is conformant but I know it when I see it
Kathy: We focused on programatically determinable
... weren't sure how to set it. Use AT?
Wilco: (summarizing what we covered)
... Most methodologies do not attempt to test different states
... so if rules require different states to be tested, it would not fit well within the current ecosystem
Shadi: Is it good or bad that tools are currently not doing it?
... need to consider, is this a bad practice that needs fixing?
... I am hearing, not inspecting state could be a bad practice
<Wilco> Lionel: General rule of engineering, considering doing A, B and C. Isn't not doing anything the beginning?
<Wilco> ...When states are determined we will require states to be enforced on this widget.
Trevor: Two significant parts. [1] the state you are in [2] the transition between states
<Will_C> drop me from the queue, got answered
Trevor: e.g., pressing play, media changes state from pause to play
... transitions implies that there are multiple states to be considered
... the states likely need to be enumerated, in order to track their transitions
Wilco: e.g., Image rule explicitly ignores images that have not loaded at the time of test
... nothing to compare the "alt" with if there is no image successfully loaded
... But speaking about transitions...the transition itself is not tested.
... e.g., change in opacity, the change period itself, is not tested. Just the before and after\
Ken: Some WCAG criteria need to address state, as they address things dependent on state
... e.g., zoom to 400%, meaningful sequence may need to be re-evaluated
... Consider reflow. Must test at a min size (320x256), then... what? Other states inbetween this min and ...?
<shadi> +1 to Ken
Susan: Image and alt is a good example.
... Testable rules need things like this to be specified
... e.g., put the page into the desired state, as a pre-requisite to a test
... always easier to test a page with pseudo classes
... make sure you test the focus states
Carlos: Example of a rule where we are considering transition
... hoverable
... came up with a 500ms wait for after firing the event, to ensure that the hover event is now testable
... not suggesting this is a best practice, but this is a practice that we chose
Wilco: summarizing
... Current practice, humans are deciding what states to test
... some needs to further define what states to test, what states not to test (transitions)
... should this be stated in the existing rules
... how about:
... add a new section, stipulate what states to test a component in, and what states to not test a component
+1
I like it
<KenP> I like it also
Will: Like it
<KenP> It may not apply to all rules
Will: though it wil be hard to define, it calls out that these states need to be verified
it is what I was trying to say--we are saying, this will need attention.
<KenP> Something like a set of generic "meta rules" that drive the decision around when to test for different states
Will: we do want to promote adoption
... verify the states, here are some examples of good states
... a good first step
<Susan_H> agree with will's point
Trevor: Agree
... Does this meant that ACT rules will become widget focused? (this is a concern)
... Complex widgets that can have a lot of states will be hard
<Will_C> agree
Shadi: remain cautious. stay close to the spec, with balance and rigor
Daniel: A state section with an itemization of relevant states could be added
... This is implied or hinted in the current spec, e.g. audio/video play (in the applicability) we say it cannot be paused
... this is an example of an itemization of state
... we do not want widget-like, or state-like
... there are an enormous amount of states, too many to enumerate
Carlos: Section on states sounds good
... consider the background section (so as not to change the ACT rules format)
... agree with the precautions, avoid being too widget focussed
... rules that do not need to account for state, rules that need to account for state, rules that should account for state
... Need to account for state: can show accountability or expectation
Danielli: Thinking about hover focus. Can I test it? Seems quite testable, added a JS to the tgit
<Danielli> https://zellwk.com/blog/style-hover-focus-active-states/
Jean: Like having a section for states, this is a state that the rules apply to.
... e.g., visible focus: the focus will be part of the expectation (as this is clearly checked)
... you need a visible focus
... distniguish between the part of the state that is optional, and the parts that are essential
... Disagree re: background section. Background is non-normative and not enforced.
... State seems more important than that ...Challenge: how will we validate tools with all these state assertions
Shadi: Agree with Jean. Not background. Let's try a states section on a few rules and see how it works
... Concerned about complexity: some requirements say, "there is a mechanism that..."
... There may be variation that in some states a requirement is met, in another state the requirement does not need to be met
Wilco: Like the Shadi idea, to try an experiment. Maybe a sub-group can try a state section on a particular rule?
+1
<Will_C> I can't run the group but happy to volunteer
<maryjom> +1 to what Wilco said.
Jean: propose two rules for this experiment that have some states (1) color contrast (2) inline link in paragraph being distinguishable
... these two rules have state issues
... Volunteers?
<shadi> (Lionel, Will, Trevor, Jean-Yves, Carlos)
Wilco: Updating the rules format is indeed an option even though it is not in scope right now.
... WCAG 3.0 can allow for an update like this
Carlos: I will be in touch with the volunteers
Wilco: Final thoughts?
Mary: very glad state is being tackled
More coffee!
<maryjom> +1
<Will_C> Thank y'all. looking forward to helping out.
<Will_C> yes, more background, please
Trevor: Will contribute more to the git, background on web archiving and crawling
<KenP> thanks!