Meeting minutes
Update on the API Standard
<mzgoddard> +present
zcorpan: have been working on AT driver spec. there are 4 PRs open
<zcorpan> https://
two new PRs since last time: capture output and simulate keypresses
zcorpan: simulate keypresses adds two different types of events "keypress" which is a high-level command and "keyup" and "keydown" which is a lower-level command
James Scholes: what if implementation only supports keypress level of granularity
zcorpan: i guess the idea would be to require the low-level access for better fidelity of simulation by the user... but if it's not implementable than obviously we will have to work around or revisit that idea
James Scholes: we were hoping to use the built-in NVDA support for simulating keypresses which don't break things down like that...
mzgoddard: what types of use cases do we need to consider? do ATs respond to keys being held down for X seconds? do they respond to key being pressed in quick succession? How do ATs respond to one key being held down while other keys are also pressed
James Scholes: i'm not sure about the first, but the second and third use cases are definitely common
James Scholes: there is also a 4th category used by JAWS (but not NVDA) which is pressing JAWS key with space + the next key you press is handled by JAWS. a way to prevent that next key from being sent to the application
James Scholes: i can look at the code to see if we have other options here, but basically you construct a "gesture" and then call a "send" method on it
zcorpan: webdriver uses sendkeys, a command that takes an "element" parameter. it's intended to only work for elements that accept text input in a browser (something that's content editable)
James Scholes: overall, it will be extremely common to need to type keyboard shortcuts
jugglinmike: the other thing that sendkeys abstracts away is the specific duration between key presses.
mzgoddard: maybe we instead approach this by making sure we can extend it in the future if needed
jugglinmike: in terms of future proofing, having just keypress doesn't preclude dropping down to keyup / keydown later
James Scholes: for us, if we need to support keyup / keydown we can definitely investigate that path
James Scholes: in the future we will probably need touch gestures and eventually braille displays... i
James Scholes: for now though, we will need a way to send multiple keystrokes in succession. we can't rely on the network to deliver two keystrokes in succession
James Scholes: can we have the ability to send multiple keystrokes together to make sure that successive keystrokes are interpreted together before a timeout period?
zcorpan: i think in webdriver, "pause" is an action, so you can send "keydown", "pause for 1 second", and then "keyup"
James Scholes: at a minimum, we're saying we want a "pause" action, and definitely a "keypress" action, that supports modifier keys
zcorpan: if we need "keyup" / "keydown" in the future, we'll just add them then
s3ththompson: so the "keypress" action needs to handle one or more keys?
James Scholes: but with the additional stipulation that JAWS / NVDA have special modifier keys called the JAWS key or the NVDA key
jugglinmike / James Scholes: discussion about the internals of NVDA key simulation (the low-level code is part of one method that they would like to use, rather than rewrite or breakup)
michael_fairchild: does the spec prescribe how keypresses are simulated?
zcorpan: there isn't anything spec'd on the remote end side
michael_fairchild: do we need to call out that we can pass through keys? that essentially with these apis, you could also drive the browser, etc.
mzgoddard: perhaps how we pass them through is defined by the AT...
Start of agend for Community Group Meeting
Meeting next weeks\
<zcorpan> RRSAgent: make minutes
<Matt_King> MK: Should we meet on july 14 and/or july 21
<Matt_King> Next community group meeting will be July 28
Unblocking progress on first 8 plans to be sent to vispero and apple
<Matt_King> James: as we know we are working on a new experience in the app for sr devs
<Matt_King> for now plan is to create an issue for a vendor's review of a given plan, e.g., apple review of toggle button.
<Matt_King> James will send email to each vendor telling them bout the plans ready for review with links to review issues and plans.
<Matt_King> They will get a link to the report page for a test plan
<Matt_King> One problem is that we can't publish in a candidate state
<Matt_King> That means we have to mark a plan as finalized to give it to the vendor.
Matt_King: so James, i think there might be some confusion on wording. that button is called finalize, but actually what we're publishing is something with a warning label. it's not actually finalized. (we didn't call it candidate but we called it that inside of the description).
Matt: All the data on the reports page has a warning that says it is from candidate test plans, not from recommended test plans.
Unfortunately, the button labeled finalize is not labeled the way we would like. It was labeled before the 2021 working mode updates.
So, pressing finalize and publishing actually puts a candidate test plan report on to the reports page.
That will have to change soon. The UI in teh app needs to catch up with the 2021 working mode changes.
Knowing this, does that unblock progress with the first 8 plans and enable ou to send them to the screen reader devs?
James: OK, we can move forward with that.
Weare letting them know that this is not the final UI; it is a work in progress and we will support them through the process.
Seth: We didn't know the process would be moving forward without the new screen reader UX.
AALL: Discussion of how to keep the working mode process moving while developing the new review experience.
There have been some misunderstandings about time table and dependencies.
Plans for new candidate review experience
Isaac is working on additional changes to design that should be ready by end of next week.
Bocoup is not working on this project during week of July 18 due to all-hands meetings that week.
Community group members can provide feedback on Isaac's design during the week of July 18 via GitHub.
We believe the design is mature enough that async feedback and discussion will likely suffice.
Build could start during week of July 25.
Discussed building only a presentation experience that walks users through the test plan in much the same way as the test runner.
Then, after building the presentation and getting feedback on it, adding the buttons for actions, such as raising issues and marking approval.
App performance
Updates that significantly improve performance re launched, but these do not yet get perf to what the eng team considers acceptable.
Seth is still working on plans for additional perf improvement and will share next week.
This is a apriority for the team.