<Will_C> zoom is being difficult

<scribe> scribe: daniel-montalvo

ACT Standup

Wilco: Busy coordinating WCAG 4.1.1 with AG. CFC to remove it from 2.0 and 2.1. Not going so well, lots of objections

Chris: Talked to Helen on the manual rule work that she is doing
... Heading has non-empty accessible name tracking

Helen: Planned to following up with Chris on his reply
... Went through the document that Kathy and Will are working on about GitHub

Chris: Mary Jo is more than happy to share the videos she created

Helen: They'll give more direction

Kathy: Chirs is absolutely welcome to help. Coments are welcome, still lots of work to do on that
... Worked on my agenda item

Tom: Not too much, a bit on parsing for 2.0 and 2.1

Daniel: Not much, took another look at the GitHub document

Trevor: ACT state stuff, and also hoping to get to my other open issues

Will: Commenting on the GitHub document

Reminder - no March 16th TF call

Wilco: No call next week.

Helen: Lots of celebrations and conferences next week

Label in name rule, discussion

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

Kathy: The current rule has many open issues. We figured out we could work on some of this examples
... This is about whether abbreviations should be accepted
... There is an example where the accessible name has "Avenue" in it
... An another iwth "inc" and "incident"
... And then a couple more that I added
... ST, U.S.A., DR. ...
... Just wanted to have your opinions on whether these should pass

Helen: I worry about this ones, sometimes the screen reader tries to be intelligent. I never know for sure
... ST Saint example may result in that not being found if you are using verbal input

Will: This is very difficult. In the US ther are so many hyphenated places. I think the closer to the visual text the better
... IF it is not exactly the same how we guarantee that the AT is going to get it right

Helen: This is more for the voice recognition

Will: Yes, AT (assistive technologies)

Helen: AAA is that it matches exactly

Tom: Assuming the screen recognition software knows what the abbreviation corresponds to, it could work

Helen: We can never assume the understanding, location, or assistive technology
... We should advocate for expanding the visual text as well

Wilco: We all seem to leaning towards failing these three examples
... I think it would be good to have a couple pof examples in the rule that abbreviating the textg and then expanding it on the accessible name is a failure

Chris: Not sure if we want to include the abbreviation element in the rule as a way to expand the term

Wilco: We could have a passing example with the title

Kathy: I thought this was not very supported by assistive technologies

Helen: Yes, nice on desktop web but not so on mobile

Kathy: Another issue is symbolic text

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

Kathy: From what I understand from the understanding document, this SC would not apply to symbolic text

Helen: Sometimes "*" to mean required is in the label

<ChrisLoiselle> Perhaps worth including per what I mentioned, https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-located.html. As Helen and Kathy mentioned may not fully supported.

Kathy: Should the SC and the rule be applicable to text used with symbolic purposes?
... In the rule background we explain that it is "characters expressing non-text content". This means the rule would apply, given that there is a passed example 5 with and X meaning "Close"
... I am just trying to get consensus that this particular pass example is a pass or it should be inapplicable

Helen: Best practice is to use an icon instead of the letter X

Wilco: WCAG SC are not inapplicable. They are either satisfied or not satisfied. Rules can be inapplicable.
... Both of these, if they were inapplicable, we would say that further tested is needed
... This would mean pretty much the same
... We don't know how to define in an objective way what symbolic text is, this is why we considered it a pass
... This is currently handled by the expectations

Chris: I get what you say. IF we were to make the rule where the aria label needs to match what is present visually, I think the X close would be against our previous decision

Kathy: I understand that difficulty, but it is currently not aligned very well with the SC

Chris: How you are defining the X and whether or not we can determine the symbolic text, I think there needs to be a definition for the rule to be able to pass this

Wilco: We don't know how to do this at the moment.

Kathy: Then in the meantime I would support not having this as passed
... This could mean that the aria label is "close", or "x", etc

Wilco: I would not want to remove this example
... We could flip around the rule a little bit
... We could focus more on items that have an accessible lable that is different from the visible text
... The only time the rule would pass is if the text content is symbolic text

Kathy: Let's talk more about this.

Wilco: I'd like to resolve this and I wouldn't want to remove this example
... Having a rule that wouldn't mix this example with other passes could work
... Or we can make a change on the format to allow a subjective applicability if the expectations are objective

Chris: What if we have S for save, or money signs? Would that be symbolic text?

Helen: Isn't there a success criteria that says that if you are using icons they have to be internationally acceptable?

Kathy: The understanding article has examples from a word processor with b for bold, i for italics, etc

Helen: This still assumes some predefined knowledge

Kathy: Thanks, let's discuss later

Better define how rules related to page states

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

Trevor: For the status message rule, we needed to have some way of initiating an action
... I will walked you through some of the things we did and why some of these are bad
... I introduced a sub section to applicability: "Applicability after action"
... After activating the test target from the applicability, something new happens that changes the applicability
... Then the expectation becomes simpler
... First question is that it is getting weird to layer these things together, and it also hides the fact that we are doing state management here
... This applicability is where we start, after that you have to do something to the page, and then we state what you should be looking at after you've done what you need to do on the page
... The applicability would be state 0, and then "applicability after action" would be state 1, and after that we would need to look at the new thing that appears which would be the test target

Chris: Is this pertaining to just text?

Trevor: I think this is specific to visible text

Chris: I would agree

Kathy: I am trying to look at the list of HTML elements. For example for textbox and then we go through activation of the text target, does it mean write something, put the cursor on it?

Trevor: Could be both. We don't want to be very prescriptive though
... This could potentially lead to new status message showing up
... I used "activation" just to leave it open for test procedure writers

Kathy: Could it be reworded to "move focus to"?

Trevor: It could be, but would we be up for that? I think our test cases would be reasonably standard

Wilco: What if we do something like prerequisites? There is the applicability but, before that, these things must have happened

Trevor: Would this mean having a section prior to the applicabilty that some visible text has appeared on the screen, for example?

Wilco: There is an input that some control needs to have been activated, then there is some visible text that appears, applicability is about the text that has appeared,

Trevor: I have no problem with this in practice. Should we make the prerequisite as fleshed out as we dcan?

Wilco: I'd like to see how this looks like

Trevor: If we are going to end up with chains of actions we may want to have some iterative process for those. I'll try to write something for this

Surveys for the Week After

Daniel: Three surveys instead of two for the other week. Please complete

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)

Succeeded: s/zakimk, take up next//
Succeeded: s/SR/screen recognition software/
Default Present: Wilco, Helen, trevor, ToddL, thbrunet, catherine_droege, kathy, Will_C_, Will_C, ChrisLoiselle, Daniel
Present: Wilco, Helen, trevor, ToddL, thbrunet, catherine_droege, kathy, Will_C_, Will_C, ChrisLoiselle, Daniel
Found Scribe: daniel-montalvo
Inferring ScribeNick: daniel-montalvo

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: 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.)