<scribe> scribe: trevor

CarlosD: I think we start with the link color contrast rule and then see if we can apply the approach to other rules.

Jean-Yves: Yes, will help us to start moving towards more consensus.

LionelW: In the link contrast rule, are visited and not visited states?

Jean-Yves: There may also be a hovered state as well. This is complex since there are multiple state dimensions.
... There could be other factors on the page that affect the state. Such as slider that changes the color contrast of the link
... Could be anything that makes the link change color.

Lionel: If it can be any, then it can be a set. Focused, not focused, visisted, not focused, hover, not hover, or some global changer.

LionelW: All of these are very local to the link, not yet visited, and visited depends on the action. Focused or not focused is not really action, but tab index position. Hover or not hovered is the mouse position.
... I think there may be other states that are not as local. The contrast rule for link, was that meant in isolation or something else.

CarlosD: This one in particular is looking at text in widgets. The text in a widget might fail a minimum contrast

LionelW: It could take on a larger number of states that we did not specify before.

CarlosD: The css psuedo classes show a bunch of states that might also apply, so there could be very long lists of all of the states. May include roles as well
... A button cannot have the same visited state as a link. For the link states, they are three seperate dimensions, so a large number of potential states.

LionelW: See the link problem as a subset of states that we can tackle and may off evidence towards the higher problem.

<Will> nebulous, not nefarious

LionelW: Another dimension is time, how much do we need to be considered for it.
... Some should be synchronous, like errors after submitting a form.
... Do we care that something was hovered or not hovered, my guess is that we don't care.

CarlosD: I don't think we can dismiss time, we must ensure everyone testing the same page will get the same results.
... Only after visiting every link, I might get a different result

Jean-Yves: I think visited is different, it could be changed by something completely external. For example, visiting from a clean browser.

LionelW: I don't see that as time, I see that as scenario/test setup and execution.
... And we want to state this in a way that are amenable to different testing strategies.

Carlos: They can be automated if we have the technology, but could be tested manualy.

CarlosD: ... There is another rule about content appearing on hoverable that might care about time.

trevor: Might have example where we have violations during a transition, such as a flashing issue.

LionelW: Had been thinking something similar. I think that illustrated the seperate setup vs. elapsed time.

Jean-Yves: I think its a good example of when there could be an elapsed page, there may be other states such as loading state that might occur

CarlosD: We want to ensure that any content that is exposed on hover stays in place while the pointer remains over the content.

LionelW: So the states we might care about, are hover or not hover. When hovering, hover on the original element or exposed content keeps content visible.

CarlosD: The problem is how to specify when to test. I need to test this rule when the content is visible.

LionelW: A possible setup and execution might be loading a page and hovering over the element.

trevor: concerns about us specifying the methodology and that we are stating the steps

CarlosD: Yes, we don't do that, we say when it needs to be tested

Jean-Yves: Visible focus rule - difference between the rule being focused and not focused. Regardless of how you might be testing for that. Could have scripted interaction between focused or not focused.

CarlosD: Our end goal should be a proposal on how to address state rules that need this kind of definition. Most rules are applicable in any states, but for rules that are dependent on states, we need to figure out how to express in which states the target element needs to be checked.

LionelW: So setup/execution or elapsed time, we can convert to your language. Items that can be tested after some setup and other rules that may be tested over a period of time.

Jean-Yves: If we look at the hover rule, then we need to move the mouse pointer, so there cannot just check in a static state. Whereas the color contrast can occur in a static state.

trevor: We did use a finite state machine in doing some of this work, which can work well, but I am not sure how we would compress all of that information into something readable for an ACT rule.

CarlosD: Yep, the problem we have is expressing in in simple terms that can be used in an ACT rule.
... Describing this rule: https://github.com/act-rules/act-rules.github.io/pull/1396/files#diff-1699539772884c266aa725853d03fd83f32956aca3045f33d3e4ce2c93c2d62c

LionelW: Our discussion is then about how this rule will improve if it explicitly considers state.

CarlosD: Our current understanding is that we need to discuss state.

LionelW: So the question is then how to discuss state in the ACT rule.
... What is we have a *State Transition* heading and so requires a pre-evaluatory setup state.

trevor: Concern is that we get into an "if/then" approach, which I have concerns about how that will scale

CarlosD: The example for the forms came up since we couldn't clearly define what counted as an error indicator. So the condition had to move from the applicability to the expectation.

LionelW: So my proposal might be shutdown, since there might be a state explosion.
... Is it possible to just talk about the immediate state dependencies.

trevor: Wondering if we could have more complex rules that build off of the rules on the more local dependencies.

LionelW: Could we have a local state dependency, limiting ourselves to the most critical local dependencies.

Jean-Yves: This might be like an extension of the applicability, finding the specific test target and then only listing the states that affect the test target.

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: CarlosD, Jean-Yves, trevor, LionelW
Present: CarlosD, Jean-Yves, trevor, LionelW
Found Scribe: trevor
Inferring ScribeNick: trevor

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)