<scribe> scribe: Dmontalvo
Wilco: These were for agreement
last week, I don't think we need to survey them back, will move
this for CFC then
... Kathy's one will go for CFC, but these are a composite rule
and we don't have the atomic rules approved
... As a question I mean, I would say
Trevor: Agree
Daniel: Agree
Wilco: Do we want to put it into CFC saying that we are waiting for the atomic to be approved but we don't send it to AGWG yet?
s/will move them for CFC/will send them to AGWG/
Wilco: Mine is ready, it has three approvals and need to go for review
Tom: Nothing from me on this one
Helen: This is waiting on reviews still
Wilco: Next one still needs editorial changes
Trevor: I made the changes and sent the call for review, Jean-Yves sent comments that he did not want to do it. His reasoning was not exactly why we thought we should remove it
Wilco: It seems technically
correct but it does not feel great to do it this way, this is
going to be a CG agenda item
... It is reasonable that if someone has a bad role value there
might be a WCAG failure
Trevor: Is there a way to cancel call for review?
Wilco: Let's revisit next week
Wilco: Jean-Yves open this 15
minutes ago
... I opened a draft related to today's surveys
... #1857 came back as feedback from AG last week. We should
address their comments to have it approved
... #1856 is the same, just another example of the above
... #1855 has some changes requested
Helen: I had some feedback from JEan-Yves and then talked to Wilco. Then we changed the expectations
Wilco: I also suggested to change
the applicability to include focus navigation
... And then having the expectation that the tabindex was not
negative
... #1850 is up for review, #1835 I need to send that out
today
<Wilco> https://deploy-preview-103--wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/
Wilco: We had feedback from AG
last week, I processed it, and I also had feedback from Shawn,
I left comments on the things I did not addressed from
Shawn
... Changes to the title, tag line, and navigation
Helen: Should it be in methodologies and tools given the order of the elements?
Wilco: Could be
Helen: Implementations of test tools and methodologies is lengthy
Wilco: I did not like "implementations"
Daniel: What are we saying about "Test tools and methodologies"
Wilco: It is not a generic list of tools, it's tools that implement the rules
Chris: When you click on that the heading is ACT Rules Implementation. Maybe having that as the tab name would be better
Wilco: How do others thing about not having "test tools and methodologies" in the tab?
Helen: I prefer it
Chris: If you are on the parent page, just clicking on the ACT Rules at the top left, then you have the page content area. Maybe just having All and About as the two main tabs and then if they want to go into methodologies they could go to that from the page contents
Trevor: Don't feel strongly
Tom: Same here
Wilco: I am taking it out
... I think we are getting close to merge. Process wise I'll
make the change and send this to Shawn for approval and then
bring it back for the group to review it again
<trevor> https://github.com/act-rules/act-rules.github.io/issues/1836
Trevor: I made some extensions to
that comment. We looked at in-line link in paragraph is
distinguishable. No-one liked that formulation. it was
confusing and too technical
... I played with this and included ideas from that c
conversation
[Trevor walks through the examples in above issue comment]
Trevor: In the first one is the
most open ended
... leaving it all to the implementer
... The second is close to what we saw last week, using the CSS
pseudo selectors
... Finally in the third one we try to specify what not to
test
Wilco: What we want from
implementers with this?
... Do we want implementers to identify certain states and to
actively put pages in to these states?
Trevor: At least one of those will have to be true
Tom: You can compute without necessarily putting it into that state, assuming there is no Javascript
Trevor: For this rule yes, not for others
Chris: Is the implementer evaluating or it is more from an authoring tool's perspective?
Trevor: We track which vendors are implementing it and which results they get
Wilco: There is also a bit of
methodology
... Would it be OK for a manual methodology not to mention the
states where they tested it?
Trevor: My preference would be for them to at least give some indication
Wilco: Is there a sense that we
can write rules either to be actively causing states or passive
in watching state changes
... The example with the aria-expanded. I think there is at
least two ways for writing that. One is where we say from the
collapse state activate the button and test the expanded
state
... OR we could say if you encounter the button in a collapse
state and then you eventually encounter it expanded, this is
the expectation
Daniel: We may want to be less prescriptive
Trevor: I think some prescription is needed to help automation but I see the point there that it will be difficult some times
Wilco: When I implement this
rule, I can do it in two ways. I can have an active role in
this rule watching out for elements and firing a click event
and then checking the results.
... I could be a passive tester, I keep record of
aria-expanded="false" and only when I see a click event is when
I watch for it
Trevor: That could bring all
sorts of problems. Are we sure that the click event is doing
things as it should?
... You can see that false and try state but how can you make
sure it's representative?
... There is going to have to be some additional check to
determine if they both correspond
Wilco: I think it is not an unreasonable assumption to expect that will expand something
Tom: You may have an aria-controls thing. I think this is about aria roles and we could wrap them up in one
Wilco: If I have a button with aria-expanded="false" I can expect that when I click it it will be expanded. Therefore the expectation is that the attribute gets updated
Trevor: We could specify the
transitions rather than the states themselves
... States are like a single instance in time. Transitions are
pairs of states
... There is a fine line there as to how those would be
tested
... As per timing, when we put this in a transition framework
it may become easier to describe
Helen: I like the fact that when
using certain items the expectations are listed
... I have seen buttons where aria-selected should be used and
they are using aria-expanded, so it is nice to know the actual
expected uses and transitions
... There is a lot of dependance on how it is utilised
... There will be help for testing this or just applied to
specific elements?
Trevor: I see this like having
some top level applicability and then you would have to run
each rule on all the elements
... Wilco do you have any thoughts on states versus
transitions?
Wilco; I think we should do something about it. I don't like the arbitrary timings. I don't know how we could better deal with that, but I think we need some concept of states and transition between states
scribe: Color contrast for example should not apply during a transition
Trevor: For this rule I think
transitions are useless. But we have some weird rules with
different formulations where there is room for
transitions
... How do we allow rules with transitions and rules with
specific states?
Wilco: I am not sure if we want to have multiple ways of writing these things
Tom: The expand collapse you can catch the transition without even talking about it
Helen: The transitions I don't
know if that is something for when there is an exception to the
norm
... States are more likely to conform to the expectations
Wilco: Let's discuss next steps on the planning meeting