ARIA and Assistive Technologies Community Group

18 March 2021


aflennik, jesdaigle, Matt_King, s3ththompson
James Schoels

Meeting minutes

Plan for code sprints for supporting aria-at issues

James: What is plan for issues like the setup test script changes

Seth: Bocoup hasn't started planning sprints yet. Still working on the test format deep dive.

If you have issues for us ready, we can track and comment.

Might want a label that is helpful for tracking these.

mk: do you mean a label like ready for implementation because design is specified.

Seth: Yes, and specifically if it is something that should be owned by bocoup

James: Maybe the label means that the CG has reached consensus on what implementation should loook like

Need a way to surface via github that it is now moving from bucket of ready for discussion vs ready for bocoup

Seth: forgot we have some status labels. this could fit right in.

mk: how about a label "requirements complete"

mk: or "requirements specified"

mk: James, can you label the issues tha need that?

james: yes

Document APG Example Modification Process


james: We modify the examples when we pull them into aria-at from apg.

We want consensus on what we are doing. Want to make sure the modification process does not cause problems.

And, we want a wiki page that describes this as part of the test writing process.

This would define the standard that the PAC team needs to meet in terms of process.

James: in some cases we have multiple examples

mk: we only have a few where the examples are different

james: sometimes we have two radio groups that are ame features, we test only one

mk: like a menubar with multiple pulldowns, we test only one; reduendant to test all

mk: eventually we want to make this unnecessary with the apg redesing by enabling embedding

Jes: we do this all over the web with test262

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

have to be careful that the apg example does not change after the test is written.

seth: This is kind of lik a lock file that specs dependencies. Your src is tied to a specific version of the downstream dpeendency.

You might also want to think about need to see how much divergence you have from the dependency.

could think of APG as another dependency package.

james: a higher level concept is that APG is not going to be the only source of content.

We could have code that pulls in content, it would define what is needed in a dependency

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.

autocomplete assertions (issue 383)


james: This relates to editable combobox with both list and inline autocomplete.

Michael asked if we have any opion about asserting the specific value of autocomplete, e.g., list vs both.

If we have different assertions for different values, then we are getting at making up what we think screen reader behavior should be.

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.

james: I tend to lean toward the idea that boolean is all we need. HTML is boolean in this sense.

If we had different ones, they would have to be optional, but then we would need multiple assertions.

hadi: wonder if aria descriptionscan be used to help users understand the different behaviors

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.

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).


Maybe present: hadi, James, Jes, mk, Seth