Meeting minutes
ACT Standup
<dmontalvo> Wilco: Got five new rules published. One of the rules came back, we have this as an upcoming conversation
<dmontalvo> ... Prep for the next AGWG meeting about ACT Rules 1.1
<dmontalvo> Tom: I opened the issue with AG about frames with the same name
<dmontalvo> ... I can't find anything in the SCs that requires a different name
<dmontalvo> ... The rule itself points to a technique but I am not sure how we should handle that
<dmontalvo> Wilco: That was the question. Given it is not explicitly required, would that be?
<dmontalvo> Tom: Sufficient for which purpose? For text requirements there is not a requirement that they are unique
<dmontalvo> Wilco: That is what we need to ask AGWG. There were people on this call saying that two titles have to be unique
<dmontalvo> Tom: I can try writing it up
<dmontalvo> Trevor: Subjective applicability, got to fill in two surveys
<dmontalvo> Daniel: Helped with publication and redirects, also started to update work statement
<dmontalvo> Kathy: Opened a PR, 2101. Related to the definition of matching characters: 2144
<dmontalvo> Katherine: Worked on surveys and reviewed PRs
<dmontalvo> Helen: Did the surveys and updated a discussion which is part of the CG. That's about user testing on how label in name works for people who use speech recognition AT
Backward compatibility to ACT Rules Format 1.0, PR to Identify Rules Format Version
<Wilco> https://
<kathy> https://
<dmontalvo> Kathy: This is an update to the rules format 1.1. This is an addition to have rules identify which version of the rules format they were written for
<dmontalvo> [People review the PR]
<dmontalvo> Wilco: Inserting a section means we have to update the numbers in the glossary
<dmontalvo> Daniel: Not sure if that's a Respec thing
<dmontalvo> Wilco: It's in the appendix where we have to update the section numbers
<dmontalvo> Wilco: Is this saying that each ACT Rules must indicate the version or that each rules written for 1.1 must indicate the version
<dmontalvo> ... Also this requirement does not apply to things written for 1.0
<dmontalvo> Wilco: We'd need to write it in a way that is future proof. I think we can leave it as-is
<Helen> +1
<trevor> +1
<thbrunet> +1
<catherine> +1
<kathy> +1
<dmontalvo> Wilco: Please +1 if you support this getting into our FPWD or -1 if you don't
RESOLUTION: Accept PR 556 for FPWD
Subjective applicability
<trevor> https://
<dmontalvo> [Reading time]
<dmontalvo> Trevor: Let's focus especially on the first section. I tweaked them to be more clear and to better explain what we mean
<dmontalvo> Wilco: I like the direction this is heading, I think this looks good
<dmontalvo> Trevor: I was afraid of the similarity between subjective and ambiguous. I think this clarifies that
<dmontalvo> Tom: I think something subjective is inheritantly ambiguous
<dmontalvo> Katherine: L414, I think you need "in"
<dmontalvo> Kathy: 414 I can see splitting as a good advice but not sure what the bottom line of that is
<dmontalvo> ... 465 is the incorrect example -- Is there a way to split this?
<dmontalvo> Trevor: Not sure. One thing that pops up is this example if a common failure and we are not calling it out inside of the format section
<dmontalvo> ... Maybe it's better to put it as an example instead of within the format
<dmontalvo> Wilco: I think it's better in the text here
<dmontalvo> Trevor: I am fine with that, I just think it's similar to what we are doing with the "don't put the applicability in the expectation" below
<dmontalvo> Wilco: I slightly prefer this approach, not strong opinion anyway
<dmontalvo> Daniel: Advice against the use of "correct" versus "incorrect"
<dmontalvo> Trevor: I think that's good
<dmontalvo> Wilco: A couple of editorial changes
<dmontalvo> ... Not sure if that meets WCAG or not
<dmontalvo> Trevor: I'd wrap it in something that has a name
<dmontalvo> Wilco: I don't think it makes sense anymore if you put an accessible name
<dmontalvo> Trevor: I think if we put a name on it that would be fine
<dmontalvo> Tom: Is an example needed for text emoji
<dmontalvo> Trevor: I like how it makes this strongly how these three are far apart in the spectrum
<dmontalvo> Wilco: I think we should leave it in an put an accessible name
<dmontalvo> Trevor: I'll go with that for now. That should be enough for a FPWD
<dmontalvo> Trevor: How do we feel about element styled as a heading? Is it going in the right direction?
<dmontalvo> Wilco: Sounds reasonable to me
<dmontalvo> Trevor: How do people feel about the second example? I'm strongly considering removing this, it does not add anything that the first didn't have
<dmontalvo> ... This section is getting very lengthy with so many examples
<dmontalvo> Tom: The only argument for it is that it's something that feels less subjective but really is
<dmontalvo> Trevor: Not sure that is enough for keeping it
<dmontalvo> Kathy: Couldn't this go to the list of currently available form field indicators?
<dmontalvo> Wilco: Yes, line 412 where we have a number of example things. That's where I would put it
<dmontalvo> Helen: For some people headings would not be such an obvious example here
<dmontalvo> ... It'd be easier if we have a glossary of examples
<dmontalvo> ... These would help people who may not have a clear idea
<dmontalvo> Trevor: We've talked with Wilco about creating an appendix
<dmontalvo> ... But we don't want to overboard the format
<dmontalvo> ... I'm happy adding examples to this list
<dmontalvo> Helen: It does help readability if you keep the top level as sparse as possible
<dmontalvo> ... It also makes it more accessible in the way we process data
<dmontalvo> Trevor: Agree.
<dmontalvo> Daniel: Idea could be to separate this and put it in another Note
<dmontalvo> Wilco: Can we have this discussion somewhere else? Let's open a new issue for that
<dmontalvo> Trevor: Agree. I can make a few changes based on our discussion and then next week we can make a vote as to put them in the WD
Surveys due next week
<dmontalvo> Wilco: People please complete the surveys by next week