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.