Meeting minutes
ACT Standup
Kathy: Waited on a decission, coordinated with Bruce on that
<kathy> http://
Tom: Not much to report
Katherine: Out these weeks
Trevor: Started to look through some of JM PRs on the target rules, huge PRs
<Daniel> Publication to WAI website, coordination with CG for joint discussion, planning meeting, sent email to AGWG Chairs to request approval for ACT-Rules format FPWD
Next 2 meetings cancelled (April 18 & 25)
Kathy: Canceling next two meetings. Daniel will join in case someone wants to work on the GitHub guidance
Review spreadsheet Updates needed
Kathy: Media alternative for video content being visible -- I expect some decission by the end of this week. I'll follow up when I'm back. That is going to affect one or two rules. There were two atomics and one composite
Focusable element has no keyboard trap via non-standard navigation
Kathy: We got through a bit of this survey
Kathy: Question 7
… Tom, it might be easier if you are the liaison in the others you may want to take this up as well
Tom: Being able to escape in one direction may not be sufficient for SC 2.1.2
[[Commentss on added background note]]
Kathy: Any questions?
[[Expectation 3]]
Tom: It would be clearer if that was on expectation 2 instead of 3
Tom: The note is about clarifying how you would do that. The third is about describing it
Kathy: I think the note under 3 is trying to explain what expectation 3 is saying
Tom: But it is clarifying the how to cycle to browser UI in expectation 2
… Cycling to the browser UI is defined through the expectations
Kathy: I read expectation 2 as about the help information
Tom: You need to get to expectation 3 for you to find out what cycle to the browser UI means
Trevor: I would be in favor of either changing from cycle to something else or having cycle somewhere in the definition
<Daniel> +1
Trevor: For me, cycle means just tabbing until I get back around
… Whereas here intermediate steps for you to be able to do that are implicit, and are unclear
Kathy: Are we all in agreement to move note in expectation 3 to expectation 2
Tom: Second sentence is fine
… We have a definition of cycling that can be used in both places
… I would clean it up a bit
… And handle it as part of the PR process
Kathy: Tom's comment about passed 1
Tom: The way the HTML is set up is outside of the trap. Inside of the trap you cannot get to CTRL+M. Screen readers can use reading mode but that is not all users
… Would be good for all of this to be wrapped around the modal
Kathy: I don't see an expectation that the help information needs to be available within the trap
Tom: That's what the first one says, yes, never mind. Weird implementation but it's fine
Kathy: Tom also says: Good to have an inapplicable example with a modal that can be exitted with escape
Kathy: I like that
Kathy: Ready to publish?
Tom: No, some clean-up is needed
Focusable element has no keyboard trap (Composite)
Kathy: A lot of work needs to happen in the atomic rules anyway
… Some restructuring according to Format updates
Kathy: Katherine flags 1589
Kathy: Second passed -- The description has been expanded
Tom: Do we need to add roles to that or it's OK for it to be "bad code"?
Kathy: We generally want everything to pass in all scenarios
Tom: At a minimum a role="button" would be required
Kathy: This is not ready to publish since the atomic rules are not ready
… We need to find a liaison
Tom: I could take these two together
… I can take the composite too
9:40 with CG: Label in Name Understanding update and Related ACT changes
<kathy> https://
Kathy: AG is trying to update the understanding for label in name
… They have asked ACT to review this PR and I need to submit our comments
… They've created some additional guidance for mathematical expressions, and for text in parenthesis
<kathy> act-rules/
Kathy: I just added a question, is it possible to add some outliers to this? U.S. puts area codes are in parenthesis
Kathy: Also, this is work from the CG on how to evaluate this if the above PR is merged
Kathy: The CG has some updates on their PR to handle these changes from AGWG Understanding documents
… AGWG has asked for ACT feedback. I'd like for us to discuss these changes together
… CG PR is 2075
… It seems Dan that when you looked through this they were in alignment with your algorithm
Kathy: We will start with the mathematical expressions section. Any concerns with what they are suggesting here?
Mark: Voice Control on the mac transformed punctuation into spaces in my tested. That is an issue with mathematical expressions
Kathy: How would you like to phrase that?
Mark: My question is can Voice recognition distinguish between mathematical expressions where punctuation is important andd other strings where they are not as important?
… That seems difficult to do in software. In the rules, it's just about how AT does that
Mark: Someone who uses these AT for real may have a better handle at it
… Also, there are several similar looking characters that are difficult to distinguish just by looking at them on screen. Minus signs, dashes, hyphens, etc
Jean-Yves: If you use x for multiplication in your label there might be a mismatch
… If you use the x in the label use it in the name as well and people will figure it out
Mark: If you say "click a x b" the speech recognition software may find it hard to match it
Dan: I think that is true. My PR skips around this for the reason Jean-Yves just mentioned
… My algorithm filters these out. We may have false negatives but we can deal with that
Tom: Is there any concern with modern technologies (mainly AI)?
Dan: WCAG does well in opening the door to AI as long as AI is able to tell the difference
… These scenarios could be improved with better implementations that better handle AI
Kathy: Are we OK relying on AT as long as name and label use the same characters?
Jean-Yves: This PR is not changing anything of that. The text is the same
Carlos: Agree
Kathy: Text in parenthesis won't be required to be part of the accessible name
Dan: I tend to write phone numbers in parenthesis, but that is not what everyone seems to do these days
Tom: In some phones, phone numbers are automatically converted into space format as you type them
… and add the brackets
Jean-Yves: I think this level of detail is OK for WCAG, not so for us. Generally we should probably discard text in brackets even though it generates some false negative
Carlos: Agree with Jean-Yves on this. For phone numbers, I suppose that is probably most relevant in the U.S.
Jean-Yves: We used them in France when we had just 8 digits. No more since we changed to 10 digits 20 years ago
… Maybe other countries outside the U.S. and Europe do use them
Kathy: Area code is compulsory now, used to be optional in the past
Tom: You can suppress the area code if you are calling the same area
Kathy: We are all OK with this, right?
[[Everybody agrees]]