IRC log of aria-at on 2021-03-18

Timestamps are in UTC.

18:47:04 [RRSAgent]
RRSAgent has joined #aria-at
18:47:04 [RRSAgent]
logging to https://www.w3.org/2021/03/18-aria-at-irc
18:47:13 [Zakim]
Zakim has joined #aria-at
18:47:56 [Matt_King]
MEETING: ARIA and Assistive Technologies Community Group
18:48:08 [Matt_King]
CHAIR: James Schoels
18:48:22 [Matt_King]
rrsagent, make log public
18:48:38 [Matt_King]
present+
18:48:56 [Matt_King]
rrsagent, make minutes
18:48:56 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/03/18-aria-at-minutes.html Matt_King
18:49:04 [Matt_King]
zakim, clear agenda
18:49:04 [Zakim]
agenda cleared
19:05:35 [Matt_King]
scribe: matt_king
19:07:41 [Matt_King]
TOPIC: Plan for code sprints for supporting aria-at issues
19:07:54 [jesdaigle]
jesdaigle has joined #aria-at
19:08:45 [Matt_King]
James: What is plan for issues like the setup test script changes
19:09:14 [Matt_King]
Seth: Bocoup hasn't started planning sprints yet. Still working on the test format deep dive.
19:09:33 [Matt_King]
If you have issues for us ready, we can track and comment.
19:09:49 [Matt_King]
Might want a label that is helpful for tracking these.
19:10:23 [Matt_King]
mk: do you mean a label like ready for implementation because design is specified.
19:10:50 [Matt_King]
Seth: Yes, and specifically if it is something that should be owned by bocoup
19:11:17 [Matt_King]
James: Maybe the label means that the CG has reached consensus on what implementation should loook like
19:11:53 [Matt_King]
Need a way to surface via github that it is now moving from bucket of ready for discussion vs ready for bocoup
19:12:14 [Matt_King]
Seth: forgot we have some status labels. this could fit right in.
19:12:56 [Matt_King]
mk: how about a label "requirements complete"
19:13:09 [s3ththompson]
present+
19:13:33 [jesdaigle]
present+
19:13:35 [Matt_King]
mk: or "requirements specified"
19:13:55 [aflennik]
present+
19:14:10 [Matt_King]
mk: James, can you label the issues tha need that?
19:14:14 [Matt_King]
james: yes
19:15:07 [Matt_King]
TOPIC: Document APG Example Modification Process
19:15:09 [Matt_King]
https://github.com/w3c/aria-at/issues/394
19:16:29 [Matt_King]
james: We modify the examples when we pull them into aria-at from apg.
19:17:02 [Matt_King]
We want consensus on what we are doing. Want to make sure the modification process does not cause problems.
19:17:28 [Matt_King]
And, we want a wiki page that describes this as part of the test writing process.
19:17:48 [Matt_King]
This would define the standard that the PAC team needs to meet in terms of process.
19:21:43 [Matt_King]
James: in some cases we have multiple examples
19:21:55 [Matt_King]
mk: we only have a few where the examples are different
19:22:57 [Matt_King]
james: sometimes we have two radio groups that are ame features, we test only one
19:23:13 [Matt_King]
mk: like a menubar with multiple pulldowns, we test only one; reduendant to test all
19:25:07 [Matt_King]
mk: eventually we want to make this unnecessary with the apg redesing by enabling embedding
19:30:41 [Matt_King]
Jes: we do this all over the web with test262
19:31:16 [Matt_King]
james: is it pulled in every time runs the test page, or is it a script that pulls it in once when the test is created
19:31:40 [Matt_King]
have to be careful that the apg example does not change after the test is written.
19:32:19 [Matt_King]
seth: This is kind of lik a lock file that specs dependencies. Your src is tied to a specific version of the downstream dpeendency.
19:32:47 [Matt_King]
You might also want to think about need to see how much divergence you have from the dependency.
19:33:36 [Matt_King]
could think of APG as another dependency package.
19:34:06 [Matt_King]
james: a higher level concept is that APG is not going to be the only source of content.
19:35:35 [Matt_King]
We could have code that pulls in content, it would define what is needed in a dependency
19:36:49 [Matt_King]
mk: I think next step is to document what you are doing. then we can use that to shape reqs for code that pulls in content for tests.
19:38:46 [Matt_King]
TOPIC: autocomplete assertions (issue 383)
19:38:51 [Matt_King]
https://github.com/w3c/aria-at/issues/383
19:39:36 [Matt_King]
james: This relates to editable combobox with both list and inline autocomplete.
19:40:13 [Matt_King]
Michael asked if we have any opion about asserting the specific value of autocomplete, e.g., list vs both.
19:40:50 [Matt_King]
If we have different assertions for different values, then we are getting at making up what we think screen reader behavior should be.
19:44:45 [Matt_King]
mk: we could go either way, autocomplete should be boolean. Or, we could try to use different values to push SRs to a better future with optionalassertions.
19:45:11 [Matt_King]
james: I tend to lean toward the idea that boolean is all we need. HTML is boolean in this sense.
19:45:50 [Matt_King]
If we had different ones, they would have to be optional, but then we would need multiple assertions.
20:01:50 [Matt_King]
hadi: wonder if aria descriptionscan be used to help users understand the different behaviors
20:04:32 [Matt_King]
james: we may have to revisit this next time. How does this match with html, which is boolean. The screen reader may not be able to distinguish between the two.
20:04:36 [Matt_King]
rrsagent, make minutes
20:04:36 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/03/18-aria-at-minutes.html Matt_King
23:56:17 [Zakim]
Zakim has left #aria-at