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