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