Meeting minutes
<michael_fairchild> https://
Issue 369 - Setup scripts
github topic: https://
js: Want to talk about both how written and used by testers
How will it interact with the apg examples, e.g., scroll an option into view
ideally, want to reuse individual bits of logic when multiple tests use the same bit of logic
This could require modifying apg examples to be controlled by script.
Look at select only combobox as example.
The apg combox scripts looks for all comboboxes on page, but aria-at setup scripts modifies that to look for one.
<rob-fentress> +present
The issues is that the APG JS encapsulates the combobox object, so we can access it from a setup script; it is not global.
Then we can not access that object to select a specific item in the combobox dropdown. the JS from APG has amethod for doing that, but we can't access it.
We want to re-used the methods that has ben developed by APG.
Sina: what is ideal aopproach?
js: Every APG example stores its entry point
or entry points
so a calling script can access that functionality.
Sina: Can we define a global entry point, like an interface, for the examples that that are instantiated as a class
Sina: define a function that you can always call, e.g., driveable,
js: If there was a property on the window object, e.g., APG, and that is the controller for the example code
MK: James, can you create an issue in APG that defines what you need.
mk: This will address avoiding aria-at modification to apg js, but not to html. we should take up automation of apg html as part of apg redesign project.
js: Now, let's discuss how to chain scripts together and how testers run setup scripts
js: on chaining, it's on me to write up that for bocoup and determine how they want to solve
js: For testers, it would seem that we want a button on the page for them to execute the script instead of running it on page load.
this brings up the possible need for a tare down after the test
Say for example, say the test is testing checkbox and the box is not checked
the tester checks it
now it is not in the right starting state.
mf: What if we replace that button with a reset button that reloads the page.
then after reset reloads, the button becomes run setup
sina: +1 to that idea
mf: what happens when the button name changes from run setup to reset? need to avoid scren reader side effects.
js: when we can control that by how we sequence the events in the setup script. we will only change the name of the button, not make a new one. then we will intentionally set focus where we want in the example.
js: what about error handling? what if setup script fails?
mf: could fail in multiple ways. we might not have failures that result in a known state that we can handle.
mk: I think it should be up to humans to understand if tthe setup script didn't do what is supposed to do
Issue 300- track status of a test
js: this is on Bocoup to add a flag to a test
<michael_fairchild> mk: we have to decide whether or not we have the status on the test itself be something distinct from the status of the test results
<michael_fairchild> mk: if you think of our workflow as a single sequence, where we have one deliverable that is the test and results. Alternatively we could say that the test is one deliverable and the results are a different deliverable.
<michael_fairchild> js: should the tests be versioned?
<michael_fairchild> mk: I don't know
<michael_fairchild> js: how would we respond to changes to assistive technologies? For example would there ever be a case where a new version of NVDA invalidates our assertions?
<michael_fairchild> mk: yes, there could, and they would need to raise an issue with us
<michael_fairchild> js: that means we would need to maintain the previous version of that assertions so that we can still publish our previous results.
js: can we do this incrementally, maybe not implement versioning initially?
mk: possibly yes
mk: think it is good idea to know where we would be going in terms of asolution so we get the status on the correct object in the data model