Open jugglinmike opened 2 days ago
Here's a quick rundown of the relevant functionality in a few implementations:
AT | feature | Desktop key | Laptop key |
---|---|---|---|
NVDA | Move System focus or caret to current review position | NVDA+shift+numpadMinus | NVDA+shift+backspace |
JAWS | Route JAWS Cursor to PC Cursor | INSERT+NUM PAD PLUS | CAPS LOCK+APOSTROPHE |
VoiceOver | n/a (document focus is expected to follow virtual cursor) | n/a | n/a |
Notably, NVDA also supports a motion it calls "Activate current navigator object." That motion certainly sounds more similar to the "user intent" proposed by this issue. However, despite the apparent similarity, I believe "activate current navigator object" is actually a different semantic. The description reads as follows:
Activates the current navigator object (similar to clicking with the mouse or pressing space when it has the system focus)
My understanding is that the "activate element" user intent in AT Driver ought to only give DOM focus to the element under the virtual cursor (thus updating the value of document.activeElement
) without interacting with the element any further.
The ARIA-AT Community Group just discussed "Activate element" user intent
.
The "pressKeys" interaction currently defined in AT Driver enables the simulation of HID-level keyboard events. However, because such a capability undermines the security model of some platforms, it isn't a generally-viable solution.
In recognition of this state of affairs, we anticipate addressing most automation needs without relying on keyboard simulation. We intend to do this by specifying a collection of purpose-built "user intents" that model user interactions at a higher level (e.g. "move to next heading"). Although such a collection could be expanded to allow for the automation of most kinds of interaction with a given assistive technology, it would not be able to address one critical scenario: the filling of form fields.
In order to allow clients to interact with form fields without a means to simulate HID-level keyboard events, we envision a new user intent which causes the focus of the AT's "virtual cursor" to become the active element of the document to which it belongs. Clients wishing to fill form fields could use an API like that in conjunction with WebDriver's "element send keys" command (or the equivalent in WebDriver BiDi) to accomplish their goal.
(For more context on this design, see gh-79 and the discussions referenced there.)
Add a user intent that instructs the screen reader to induce the browser to make the virtual cursor the "activeElement" of its containing document. Explore ways to discuss the intended use-case via additional non-normative text.