14:05:54 RRSAgent has joined #wcag-act 14:05:58 logging to https://www.w3.org/2023/01/19-wcag-act-irc 14:05:58 RRSAgent, make logs Public 14:05:59 please title this meeting ("meeting: ..."), daniel-montalvo 14:06:08 Wilco: 6 PRs opened, would appreciate review.Published editors draft of 1.1 14:06:17 https://w3c.github.io/wcag-act/act-rules-format.html 14:06:42 ... Reached out to HTML Code Sniffer. 14:06:43 Chair: Wilco 14:07:03 trevor: Mostly working on state stuff. 14:07:31 https://github.com/act-rules/act-rules.github.io/pulls/WilcoFiers My open PRs 14:08:00 kathy: Worked on surveys. Liason to rule visible label accessible name. Jean-Ives asked if open spaces are allowed. Might want to update understanding article to state open spaces are allowed in certain situations. Not sure where to go with that right now. 14:08:18 ... Forwarded that to Wilco. 14:09:04 Helen: Reviewed some of Wilco's PRs and one by Sean. Worked on PR 1979. Working on creating a manual test. 14:09:16 ... Surveys. 14:09:52 daniel-montalvo: Surveys. Opened a couple of PRs. Some onboarding for CTs 14:10:18 Tom: I did not get to all the surveys. There is one of the fails we disagree on here 14:10:25 ... Worked on the iframe has accessible name rule 14:10:42 ... Not sure what to do with that so many AT/browser variations 14:10:50 Catherine_Droege has joined #wcag-act 14:11:02 Wilco: HTML images contain no text PR was merged and I think is ready for a CFC 14:11:27 ... Going to put that out. In case you didn't review the PR, use the CFC for that. 14:11:41 Zakim, take up next 14:11:42 agendum 2 -- Better define how rules related to page states (30 min) -- taken up [from Wilco] 14:12:35 trevor: Last week we discussed some other options for state. 14:13:15 ... Pin it down to what states we'll tackle, but not necessarily all of the states. I put together some samples of rules that we can poke at for examples. 14:13:37 https://github.com/act-rules/act-rules.github.io/issues/1953 14:13:49 ... First one (see 1953). Link has minimum contrast with in link, visited, focus, and hover states 14:14:48 ... Applicability that match CSS pseudo classes :any-link, :link, :visited, :focus, :hover 14:15:27 ... :any-link refers to any a or area with an href. 14:15:42 ... Expectation is your usual contrast expectation. 14:16:02 ... I feel this is simple and handles state reasonably well. Wanting to know what's good or bad. 14:16:18 ... Also wanting to confirm that this is what we were talking about last week. 14:17:11 Wilco: I like it. I think this is straightforward. Two things worth talking about. What does this mean for regular non-state rule? What's the relationship to that rule? Would we update that to say not in these states? 14:17:21 trevor: You mean the regular contrast rule? 14:17:37 Wilco: Would that rule be excluding these states? 14:18:07 Wilco: Current rule just scans whatever state it's currently in 14:18:35 Wilco: Is it saying put this into these states and test 14:18:57 trevor: I think we want to say put it into these states. 14:19:15 Wilco: Second thought - what about multiple states because these aren't mutually exclusive 14:19:47 trevor: Nothing stopping us from adding the combined states 14:20:12 ... Something we initially ran into when we went through this with Carlos and Jean-Ives. Not sure this solves that in all cases. 14:21:46 Wilco: Something I've been thinking about. Maybe there are different types of tools that we need to distinguish. Like snapshot tools (whatever the current page is), observational tools (things that sit and watch as you interact), active tools (things that manipulate the page) 14:23:02 thbrunet: You can push CSS states with snapshot tools 14:23:11 Wilco: But can't account for JavaScript though 14:23:28 trevor: Is their value in writing the rule to assume JavaScript doesn't affect it? 14:23:35 Wilco: Depends on the scenario 14:23:49 ... I wouldn't be comfortable for any contrast rule 14:24:07 trevor: Unlikely someone would do JavaScript to manipulate the colors for this scenario 14:24:21 Wilco: We have other rules that do that (orientation) 14:24:49 trevor: Back to that, we have different tools. Do you have a proposal? 14:25:09 Wilco: Wondering if this rule can only be implemented by an active tool, or only makes assumptions about scripting not being there? 14:25:28 ... Or these examples should come with the scripts? 14:25:47 thbrunet: Would we add to the rule what types of tools this rule applies to? 14:26:29 Wilco: Not necessarily. Is this rule only implementable by tools that guess the state based on CSS or actively manipulate the state because we supplies the scripts necessary to trigger those states? 14:26:49 trevor: How would we have both live together? If tool wants to do it themselves not actually doing it themselves? 14:27:15 Wilco: I think I agree. But it's an important decision that we make. To implement a rule like this, you have to actively manipulate, or make some assumptions and infer. 14:27:42 trevor: The CSS is a little specific, but aria-expanded won't 14:27:56 Wilco: Yes, you have to actively manipulate the page state for aria-expanded. 14:28:40 trevor: Could static checkers do the states of aria-expanded given the state? 14:29:04 Wilco: Maybe in some cases, but generally no. 14:29:22 ... Maybe a little technical. 14:29:55 Helen: From the manual side, I think we can do it from the instructions. Would be clearer if state that the tester would put the element in that state. 14:30:17 Wilco: Kind of what I'm thinking too. I like that you're required to manipulate state. 14:30:30 ... It better fits what you would tell a tester to do. 14:31:23 trevor: Feels like this conversation is somewhat similar to discussion on linting tools that there are some limitations. Maybe we should take that offline. What can we get away with for being inclusive of tool limitations. 14:32:21 thbrunet: visited is dicey. For security reasons, some scripts can't see that. 14:32:59 Wilco: One thing we could do - original thinking for contrast - not limit this by state, but by components that could be in different states. 14:33:16 ... Not long ago, we added widgets to contrast because they were originally excluded. 14:33:29 ... We thought we'd have something that would test in all states. 14:33:43 trevor: You mean with the a and area elements? 14:34:52 Wilco: Maybe leave the current rules as it is, and then have a separate rule that says you have to test specific states. Sort of overlapping, but this adds something. 14:35:58 trevor: Should connect these in the background section somehow, but maybe not a formalized connection right now between the two rules. 14:36:16 ... I don't see a good way to formalize that connection right now. 14:36:21 Wilco: Not sure it needs to be 14:37:40 thbrunet: It feels like in this one, the states are a pre-action before you run the existing rule. 14:37:55 ... Whereas for expanded, the action is while you're running the rule 14:38:03 trevor: One other thing I wanted thoughts on 14:38:25 ... For the aria-expanded for the applicability. 14:39:04 ... First part concerns me with the 'any element'. Other places we define the element by what it does. 14:39:51 Wilco: Yes, feels too vague to me 14:39:59 ... Like what is interacting? 14:40:20 ... Is it time delay? Does it only happen on a Tuesday? 14:40:36 ... We've had this issue in the past, might not be direct enough for applicability 14:40:45 ... I'd use aria-expanded as a hook first. 14:41:07 trevor: But that doesn't solve the interaction problem 14:41:42 wilco: Could choose specific events 14:41:48 ... like click 14:42:02 trevor: Yes, that could solve this expanded on. 14:42:28 ... But if we get to status messages. The applicability is awkward. Both have an element you need to activate, but you're evaluating some other element 14:43:06 ... I haven't solved this. Thought about putting question marks. This adds layers of complexity. 14:43:31 Wilco: Helps to add specifics on how you know. 14:43:50 trevor: Thought of copying some of the status message examples from the understanding document. These would be the cases we care about most. 14:43:56 Wilco: I think that's fine. 14:44:16 ... These are informative documents. We can add to them if we need to. 14:44:35 trevor: My homework is to look at status a little more and use understanding as a basis for framing it. 14:44:51 ... Will this actually require changes to the rule format? 14:45:15 ... Maybe we can add some notes on best practices. I don't think we've added anything that's a new requirement to the format yet. 14:45:26 Wilco: If we can make it work in the current format, perfect. 14:46:08 daniel-montalvo: Might need to include instructions for both automated and manual tools on how to get into specific states. 14:46:44 trevor: My feeling is all of this discussion might be worth some notes in the ACT document to try to hash it out more, but not need a full section on how state always gets dealt with. 14:46:58 daniel-montalvo: I agree, have to keep this in mind to be consistent. 14:48:07 kathy: I was thinking the opposite. If the rules format for tests that require various states to be covered within the rule, that it's pretty obvious. Whether it's a subset of applicability or expectation, there could be an obvious indication that all of these states need to be included in the implementation 14:48:20 ... Just to make it obvious because if it's just written in text, might be overlooked. 14:48:32 ... Some indicator to make it obvious. 14:48:52 Wilco: Maybe something to look into next time - talk about transitions in color contrast rules. 14:49:37 trevor: Yes, that's a tricky one. We'd check a couple of times to see if the page had settled to avoid checking in the transition. 14:50:04 Helen: Does some of that overlap with 2.4.7 with the keyboard focus state? 14:50:25 Wilco: Another rule we could look at. 14:50:50 Zakim, take up next 14:50:50 agendum 3 -- ARIA state or property is permitted -- taken up [from Wilco] 14:51:06 agenda? 14:52:34 Zakim, take up item 4 14:52:34 agendum 4 -- ARIA attribute is defined in WAI-ARIA -- taken up [from Wilco] 14:53:16 Wilco: First comment on Q6: links to #2005 with editorial work 14:53:36 ... I thought some editorial fixes that would be good. Could use reviews. 14:54:04 ... Q8: Wilco PR 2005, Daniel PR 2009 14:54:35 daniel-montalvo: These might be overlapping. 14:55:03 Wilco: Conclusion - resolve PR 2005 and 2009. 14:55:11 ... This was an easy one to be fair. 14:55:47 https://docs.google.com/spreadsheets/d/1OSkPFocXk4K3zYLnwS78WLsWO4PvE5yRcsauyefuIUI/edit#gid=0 14:56:23 Wilco: This is where we track all of our work. 14:56:46 ... Published, proposed, surveying, ready for AG, etc. 14:57:37 ... These rules once we assign a liason to follow up on issue. 14:59:09 ... Also look at PR 2004, 2008. 14:59:13 zakim, end meeting 14:59:13 As of this point the attendees have been Will_C, Helen, thbrunet, Wilco, kathy, Daniel, trevor 14:59:15 RRSAgent, please draft minutes 14:59:17 I have made the request to generate https://www.w3.org/2023/01/19-wcag-act-minutes.html Zakim 14:59:24 I am happy to have been of service, daniel-montalvo; please remember to excuse RRSAgent. Goodbye 14:59:24 Zakim has left #wcag-act