Meeting minutes
Agenda and Next Meeting
Mike: Next BTT meeting is oct 9
mk: is btt meet8ing in Nov?
maybe we should have a one-off meeting in Nov.
b/c of veterns day holiday
should we have a one-off on nov 4?
mike: good with that.
Decision: Matt create one-off for nov 4
TPAC Debrief
Mike: we broght 2 issues to TPAC.
1 for how we support intents and wheter capability pattern is OK.
second for the text input intent.
BTT didn't think that overhead of capabilities pattern is worth while.
Instead, it should be sufficient for implementations to publish out-of-band documentation of what they support.
mk: is graceful error handling when an intent is not supported sufficient?
Chris: remember that was part of rationale.
mike: Clients could potentially fail gracefully such that a test can fail with an error instead of a test fail.
Group decision: supporting capabilities for intents is not necessary at this time. Save for later versions.
<jugglinmike> github: w3c/
TPAC Debrief part 2
This is for the issue about text input API -- sendtext
Mike: For cases where HID access is not supported.
virtual cursor and document focus are not always aligned.
Web driver element.sendkeys can't work without knowing the element.
mk: A screen reader has to set focus before keys can be provided to an element.
so the document.activeElement must be set before the screen reader user can send keys to an element.
Chris: thinking it might have been an edge case where activelement and VC were not aligned.
Maybe it is an AT bug.
Mike: it seems like BTT conclusion is that webdriver sendkeys should be adequate.
[discussion around the behavior of the virtual cursor--in "reading" mode, in "interaction" mode, and generally in mode-less screen readers]
mk: Screen reader users can "activate the element" under the virtual cursor. This essentially simulates a mouse click in the browser and causes a mode switch in screen readers which support modes
mk: We should extend AT Driver with a new intent named "Activate Element" which causes this to happen
mk: This should be sufficient for the "Send text" use case because after performing the "Activate Element" intent, users of the protocol can switch to WebDriver to retrieve the document's activeElement and then use the WebDriver "Element.sendKeys" command to simulate typing
mk: Because we recognize that common use cases will require clients to coordinate messages sent on two protocols (AT Driver and WebDriver), we should also consider how to incorporate non-normative text which explains this pattern