Meeting minutes
Test planning - issue 385
https://
james: we are rapidly through the patterns we decided on last time and some have changes coming.
we'd like a progress update b/c we may need to change the plan
just to keep momentum going.
Spin button toolbar, and sliders
which ones need updating in APG.
jg? we are working on sliders now
mk: we merged horizontal slider last week
James: what about other sliders
mk: the thermostat slider coming next week
jg: updates are done and ready for reivew
James: that leaves tree
mk: nav tree is stable, the other 2 trees we are still planning what to do
james: ok, we can check back on that in a couple weeks and then decide if we need to update plan
Tracking status of tests -- issue 300
https://
James: we started this discussion last week, matt riased issue that this may not be as simple as keeping track of a binary state
mk: what is the life cycle of a test plan. When we first merge, we can mark draft
Discussion of AT release timing and versions and how that can impact the process.
mk: process is something like cg makes draft test, then agrees read for AT dev review, then test is reviewed and agreed as ready to be mark final
mk: stages could be: draft, ready for wide review, final
james: thsi raises question of what happens when AT vendor disagrees with a test during the wide review window
mk: the wide review window proposal is 120 days
james: let's say that near end of wide review window, sr developtells about several problems, what do we do?
Sina: maybe first 60 days of wide review is for raising issues, then 60 days emain for fixing issues
james: so we always have at least 60 days to fix issues
hadi: How do we have regular conversation with AT vendors to include them in the process and give us real time feedback instead of batching it all up. Are they onboard?
mk: We have been keeping them up to date, but have not had a lot of content for them to chew on.
James: we can have it in real time, but having deadlines is important to keep the project moving.
James: are we going to target during test runs for every public release of an AT
next step: work out what needs to change in working mode and james will post in comment in issue 300.
Revisiting command sequences - issue 363
https://
James: we d3ecided we do not want open-ended sequences. we will always have exact number of key presses.
Worked out syntax in the issue.
we did not talk about commands that need to be done in a certain time frame, like typeahead in a combobox
e.g., type :"ap" to get to apple in the combobox listbox
These two letters would need to be typed quickly.
That could be like testing the example, not the assistive tech.
Sina: that could depend on where the ARIA plays a role in the experience
It doesn't seem like this is an AT function, it is an function of the example being tested
mk: maybe punt
sina: +1, we can do this later
mk: Propose that this would be a single "type string" command, e.g., "type("ap");\