Meeting minutes
Update on sprint 8
Seth: Howard and Alex are both in the co-design workshop day 2.
We didn't get logistics coordinated to get w3c and non-w3c people together at same time.
We will try this again to get that part coordinated better.
Current workshop we are learning a lot, but no significant design decisions will be made.
We'll have a topic on this in CG meeting later in the month.
About the sprint progress ...
Progress on fixing merges of test prs
Merged the new git attributes PR.
Merged a PR with some tests, and that worked, but there were problems with a script was running on Windows.
So, we reverted and started working a fix to that script.
<s3ththompson> https://
Discussed support for windows in scripts.
<s3ththompson> https://
We think the PR is now ready; waiting on review from James.
Howard can help with some of the merging.
mk: other sprint 8 updates?
seth: working on test queue
The conversion to graphQL will for test queue components is starting. Plan to complete by end of sprint.
We have also tackled the permission issues so we can move away from the github team for testrs.
We will be able to use our own allow list.
Open question is how to build the allow list process. where should it live? who should edit, etc?
Sprint 9 planning
Seth: Question is w3c moving away from travis?
We will work on this in sprint 9.
Work on changing test run pages to the new graphQL componentry.
Only user visible change will be using native formrather than iFrames.
Test Writing Community Group Agenda Starts Here
Construction of test titles and instruction text -- issue 364
https://
Test title tends to consist of action direction subject and mode.
How much detail do we want to include in the title?
James: some of these get very long
we're trying to be more concise and not necessarily describe everything about the subject
so, for example, don't have to say the slider is horizontal
mk: need to be sure the title is unique within a plan and is sufficient to help people reading reports
James: but not necessarily across plans
mk: yes
mk: need to be consistent in our wording, especially the actions
James: other aspect is instruction text
sometimes seems superfluous
Often what is in the instructions is conveyed in the title.
This makes the instructions seem not that helpful.
mk: in a sense, the insturctions are not just there for testers but also to document what testers have done.
mk: In future, we may have some test-specific configuration instructions.
mk: do we have a separate issue for the wording of a test
James: yes, issue 413, we decided to wait to discuss that later.
Add ability to distinguish between property, role, and state metadata
https://
james: in test format we havea references file where each row is a role, state, or property
Then, we use those references in a test.
There can be multiple spec references for a test.
This system does not allow us to distinguish between multiple values of a state.
For instance, true or false for expanded.
Then, you can't search for data related to a given state value.
mf: I think it is important to distingusish between the values
mk: I want to understand use case for data
James: When reporting coverage, we need to make sure we cover all values of a property. Just saying we tested aria-live is ambiguous.
Same for HTML, for instance, which input types have we tested?
Need to be able to answer these kinds of questions.
mf: we also need to ensure we report on coverage of value change events
jes: There was request in last iteration of reports page to be able to facilitate sorting
James: should we have seprate issue for coverage maps generation
mk: yes
James: after we have covered all APG, then we can see what the gaps in coverage are.
by using a coverage map.
mk: what is the decision we need to make now?
James: The implementation decision is either multiple values per row or one row per value
James: how would you spec this for aria-label?
mk: do not need to specify value for all properties.
we would skip for aria-label.
mk: should be only for booleans and tokens
Group decision: we want to do this, it is now a matter of deciding implementation. James will make separate issue for that.