Accessibility Conformance Testing Teleconference

Wilco: 6 PRs opened, would appreciate review.Published editors draft of 1.1

<Wilco> https://w3c.github.io/wcag-act/act-rules-format.html

Wilco: Reached out to HTML Code Sniffer.

trevor: Mostly working on state stuff.

<Wilco> https://github.com/act-rules/act-rules.github.io/pulls/WilcoFiers My open PRs

kathy: Worked on surveys. Liaison 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.
… Forwarded that to Wilco.

Helen: Reviewed some of Wilco's PRs and one by Sean. Worked on PR 1979. Working on creating a manual test.
… Surveys.

daniel-montalvo: Surveys. Opened a couple of PRs. Some onboarding for CTs

<daniel-montalvo> Tom: I did not get to all the surveys. There is one of the fails we disagree on here

<daniel-montalvo> ... Worked on the iframe has accessible name rule

<daniel-montalvo> ... Not sure what to do with that so many AT/browser variations

Wilco: HTML images contain no text PR was merged and I think is ready for a CFC
… Going to put that out. In case you didn't review the PR, use the CFC for that.

Better define how rules related to page states (30 min)

trevor: Last week we discussed some other options for state.
… 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.

<kathy> https://github.com/act-rules/act-rules.github.io/issues/1953

trevor: First one (see 1953). Link has minimum contrast with in link, visited, focus, and hover states
… Applicability that match CSS pseudo classes :any-link, :link, :visited, :focus, :hover
… :any-link refers to any a or area with an href.
… Expectation is your usual contrast expectation.
… I feel this is simple and handles state reasonably well. Wanting to know what's good or bad.
… Also wanting to confirm that this is what we were talking about last week.

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?

trevor: You mean the regular contrast rule?

Wilco: Would that rule be excluding these states?

Wilco: Current rule just scans whatever state it's currently in

Wilco: Is it saying put this into these states and test

trevor: I think we want to say put it into these states.

Wilco: Second thought - what about multiple states because these aren't mutually exclusive

trevor: Nothing stopping us from adding the combined states
… Something we initially ran into when we went through this with Carlos and Jean-Ives. Not sure this solves that in all cases.

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)

thbrunet: You can push CSS states with snapshot tools

Wilco: But can't account for JavaScript though

trevor: Is their value in writing the rule to assume JavaScript doesn't affect it?

Wilco: Depends on the scenario
… I wouldn't be comfortable for any contrast rule

trevor: Unlikely someone would do JavaScript to manipulate the colors for this scenario

Wilco: We have other rules that do that (orientation)

trevor: Back to that, we have different tools. Do you have a proposal?

Wilco: Wondering if this rule can only be implemented by an active tool, or only makes assumptions about scripting not being there?
… Or these examples should come with the scripts?

thbrunet: Would we add to the rule what types of tools this rule applies to?

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?

trevor: How would we have both live together? If tool wants to do it themselves not actually doing it themselves?

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.

trevor: The CSS is a little specific, but aria-expanded won't

Wilco: Yes, you have to actively manipulate the page state for aria-expanded.

trevor: Could static checkers do the states of aria-expanded given the state?

Wilco: Maybe in some cases, but generally no.
… Maybe a little technical.

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.

Wilco: Kind of what I'm thinking too. I like that you're required to manipulate state.
… It better fits what you would tell a tester to do.

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.

thbrunet: visited is dicey. For security reasons, some scripts can't see that.

Wilco: One thing we could do - original thinking for contrast - not limit this by state, but by components that could be in different states.
… Not long ago, we added widgets to contrast because they were originally excluded.
… We thought we'd have something that would test in all states.

trevor: You mean with the a and area elements?

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.

trevor: Should connect these in the background section somehow, but maybe not a formalized connection right now between the two rules.
… I don't see a good way to formalize that connection right now.

Wilco: Not sure it needs to be

thbrunet: It feels like in this one, the states are a pre-action before you run the existing rule.
… Whereas for expanded, the action is while you're running the rule

trevor: One other thing I wanted thoughts on
… For the aria-expanded for the applicability.
… First part concerns me with the 'any element'. Other places we define the element by what it does.

Wilco: Yes, feels too vague to me
… Like what is interacting?
… Is it time delay? Does it only happen on a Tuesday?
… We've had this issue in the past, might not be direct enough for applicability
… I'd use aria-expanded as a hook first.

trevor: But that doesn't solve the interaction problem

wilco: Could choose specific events
… like click

trevor: Yes, that could solve this expanded on.
… 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
… I haven't solved this. Thought about putting question marks. This adds layers of complexity.

Wilco: Helps to add specifics on how you know.

trevor: Thought of copying some of the status message examples from the understanding document. These would be the cases we care about most.

Wilco: I think that's fine.
… These are informative documents. We can add to them if we need to.

trevor: My homework is to look at status a little more and use understanding as a basis for framing it.
… Will this actually require changes to the rule format?
… 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.

Wilco: If we can make it work in the current format, perfect.

daniel-montalvo: Might need to include instructions for both automated and manual tools on how to get into specific states.

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.

daniel-montalvo: I agree, have to keep this in mind to be consistent.

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
… Just to make it obvious because if it's just written in text, might be overlooked.
… Some indicator to make it obvious.

Wilco: Maybe something to look into next time - talk about transitions in color contrast rules.

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.

Helen: Does some of that overlap with 2.4.7 with the keyboard focus state?

Wilco: Another rule we could look at.

ARIA state or property is permitted

ARIA attribute is defined in WAI-ARIA

Wilco: First comment on Q6: links to #2005 with editorial work
… I thought some editorial fixes that would be good. Could use reviews.
… Q8: Wilco PR 2005, Daniel PR 2009

daniel-montalvo: These might be overlapping.

Wilco: Conclusion - resolve PR 2005 and 2009.
… This was an easy one to be fair.

<Wilco> https://docs.google.com/spreadsheets/d/1OSkPFocXk4K3zYLnwS78WLsWO4PvE5yRcsauyefuIUI/edit#gid=0

Wilco: This is where we track all of our work.
… Published, proposed, surveying, ready for AG, etc.
… These rules once we assign a liaison to follow up on issue.
… Also look at PR 2004, 2008.