Add "activate element" user intent

[jugglinmike]

Include the rationale for this intent as a non-normative note.

---

I originally envisioned the "activate element" user intent as being tightly integrated with web platform infrastructure. However, such an integration would rely on fundamental concepts such as the session and browsing contexts, and AT Driver lacks those. We might consider introducing the "plumbing" necessary to explain all of this in terms of the web, but I'm not convinced doing so would be in the long-term interest of the project.

It's true that the text I've proposed is far less precise than what can be achieved within the web platform, but the resulting genericness has the advantage of being meaningful outside of web contexts. Since we hope this protocol might one day become useful for testing applications beyond the web, I think the benefit of the genericness outweighs the disadvantage of vagueness.

Resolves gh-81.

---

Preview | Diff

[jugglinmike]

/cc @ChrisC

[css-meeting-bot]

The ARIA-AT Community Group just discussed The 'ActivateElement' user intent in AT Driver.

The full IRC log of that discussion

<ChrisCuellar> Topic: The 'ActivateElement' user intent in AT Driver
<ChrisCuellar> https://github.com//pull/82
<ChrisCuellar> github: https://github.com//pull/82
<ChrisCuellar> jugglinmike: the idea for this PR was largely hammered out at TPAC. We wanted a way to activate a focused element under the current virtual cursor. We wanted to facilitate use cases where the user needs to interact with form fields without sending arbitrary key presses. So with Activate Element, we can move the virtual cursor to the desired element, and then use webdriver to interact with the element.
<ChrisCuellar> I initially wanted to use a lot of the web platform concepts to talk about focus and element, but when I started editing the spec, I realized that only makes sense for Webdriver but not for AT Driver. It doesn't have concepts of browsers or browsing sessions. Webdriver knows about the DOM and browsing contexts. Do we want that in AT Driver or not?
<ChrisCuellar> I didn't want to go down that route because it involves a lot more spec writing. I also think it's not quite appropriate for the AT context.
<ChrisCuellar> mattking: Are we stuck on Mac development without this?
<ChrisCuellar> jugglinmike: Not exactly. If Apple won't implement 'Send Keys', we're still stuck.
<ChrisCuellar> mattking: I thought that this would allow us to use Webdriver for 'Send Keys'
<ChrisCuellar> jugglinmike: Yes, but not for the interesting part in terms of AT Driver.
<ChrisCuellar> mattking: In the current MacOS implementation, doesn't applescript give you a way to activate an element? We're doing it right now.
<ChrisCuellar> jugglinmike: Yes, but it's not recognized at a protocol level.
<ChrisCuellar> mattking: so we don't have a concept of session or a document. What would the workarounds be?
<ChrisCuellar> jugglinmike: Right now, what the PR does is that the algorithm just instructs the implementor to perform the default action for the virtual cursor.
<ChrisCuellar> mattking: we should use a different term
<ChrisCuellar> jugglinmike: are we on the right direction?
<ChrisCuellar> Beyond the directional sense, is this a good thing that the PR is so agnostic about the browsing context? It could be useful, because it could be equally viable in other contexts, like native apps.
<ChrisCuellar> mattking: But "default action" is not enough. Did we have the discussion about "Activate Element" versus "Focus Element". Moving the Screen Reader Point of Regard does not necessarily activate the element. For instance, it doesn't click a button, but we might need to just move focus to the button.
<ChrisCuellar> jugglinmike: The motivating use case here is mostly for form fields, not buttons.
<ChrisCuellar> mattking: If you want to test the NVDA response for reading the current element for example, but doing it in NVDA focus mode and not browsing mode, do we have a way to get focus for the desired element in NVDA? In ARIA-AT, we have scripts that move focus and reading cursor around.
<ChrisCuellar> jugglinmike: I don't know
<ChrisCuellar> mattking: so right now in ARIA-AT, we rely on scripts to set up the test conditions. But if someone was walking through a workflow with AT-Driver, then they might need focus-setting user intents.
<ChrisCuellar> jugglinmike: With moving focus, is that just basically using TAB?
<ChrisCuellar> mattking: it can be using TAB or arrow keys
<ChrisCuellar> jugglinmike: I think we should have an intent for anything a user might do, so yes we would have intents for focus movement
<ChrisCuellar> mattking: so where is "Default Action" defined?
<ChrisCuellar> jugglinmike: It's currently not defined. I'm not as familiar with AAM. Is that something we need to define ourselves? Is there something we can normatively reference here?
<ChrisCuellar> mattking: I know there are API's that have method names like `performDefaultAction`, but I can't answer that definitively now. The concept of default action is understood, but I'm not sure how it's defined or if it's defined anywhere
<ChrisCuellar> jugglinmike: I can take this an action item for myself to get more understanding here. I can bring this to Valerie from Igalia, who is an editor of Core-AAM
<ChrisCuellar> mattking: So webdriver doesn't have anything like "Default Action" in it?
<ChrisCuellar> We might have to normatively define it in Webdriver terms.
<ChrisCuellar> jugglinmike: As much as I want to leverage existing work and familiarity with web concepts, I'm not sure we can do that without dragging in a concept of a browsing session again.
<ChrisCuellar> mattking: It seems like it's hard to define this without bringing the concept of a browsing context.
<ChrisCuellar> jugglinmike: It seems like the only way to make this less hand-wavey is to bring in a lot of web platform concepts. I'm not sure these concepts will be helpful to a screen reader implementor.
<ChrisCuellar> mattking: I think we need the screen reader implementors to weigh in here.
<ChrisCuellar> jugglinmike: Is this something I should push on ahead of the February meeting?
<ChrisCuellar> mattking: It's going to be hard to move things along in the BTT meeting without some earlier discussions. I think some other things you can do in the near term is to use "Reading Cursor" or "Screen Reader Point of Regard" instead of "item in Virtual Cursor". We also need some definition of "Default Action". That word "item" in the AT's point of regard needs to have meaning. We need to make sure we're not writing this in a way that's too
<ChrisCuellar> specific to screen readers.
<ChrisCuellar> Zakim. end meeting
<ChrisCuellar> Zakim, end meeting