Core AAM: Clarify expectations regarding implementation of IAccessible::accSelect()

[jnurthen]

From @joanmarie on July 25, 2017 10:46

The Core AAM currently states the following for objects which have selection amongst their properties (e.g. grid):

Implement Methods IAccessible::accSelect() and IAccessible::get_accSelection()

The problem (imho) with that statement is with the first method to be implemented. According to the documentation I've found:

The IAccessible::accSelect method modifies the selection or moves the keyboard focus of the specified object. All objects that support selection or receive the keyboard focus must support this method.

But we've not stated how to implement it. And how to do so is not (necessarily) as obvious as implementing the getter methods of an interface:

1. If the user agent modifies the value of aria-selected in response to a call to IAccessible::accSelect():
   1. It will not reliably modify the selection as expected because the author of the ARIA 1.x web app has no obligation to be watching for property changes made by the user agent and updating the web app's selection accordingly. That is anticipated to change in ARIA 2.x with the addition of support for setting properties via platform accessibility APIs, but that is not currently in place.
   2. It may result in the platform AT reporting invalid information to the user. For instance, a reasonable way to implement support for the platform's accessibility API to get the current selection would be to return the elements for which the value of aria-selected is true. If the user agent has modified the value of that property, the results returned would not jive with the web app's state.
2. Because focus can be independent of selection, we don't want user agents implementing support via grabbing focus on the element(s) in question.

Looking at the aforementioned documentation, it says the following about the return value:

Type: HRESULT
If successful, returns S_OK.
If not successful, returns one of the values in the table that follows, or another standard COM error code.

S_FALSE: The specified object is not selected.

E_INVALIDARG: An argument is not valid. This return value means that the specified SELFLAG combination is not valid, or that the SELFLAG value does not make sense for the specified object. For example, the following flags are not allowed on a single-selection list box: SELFLAG_EXTENDSELECTION, SELFLAG_ADDSELECTION, and SELFLAG_REMOVESELECTION.

DISP_E_MEMBERNOTFOUND: The object does not support this method.

Given those choices, I would think the desired return value would be S_FALSE. I don't think it makes much sense to ask user agents to sanity check arguments for validity given the expected implementation is (currently) a no-op. And the third value could be interpreted to mean that the grid (or whatever) element in the web app doesn't support selection, which isn't the case: What is not (currently) supported is changing the selection via IAccessible::accSelect().

If everyone agrees, then perhaps what is called for is a note similar to what we have for ATK:

ATK:

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents must return false for all Selection methods that provide a means to modify the selection.

Proposal for MSAA/IA2:

Because WAI-ARIA does not support modifying the selection via the accessibility API, user agents must return S_FALSE for IAccessible::accSelect()

Comments?

Copied from original issue: w3c/aria#612

[jnurthen]

From @asurkov on July 25, 2017 13:51

I'd say that ARIA author should be capable to design common UIs, so if it is a reasonable expectation that UI selection may be changed via accessibility API, then ARIA shall support that. If there are reasons why ARIA cannot do that, then DISP_E_MEMBERNOTFOUND seems appropriate. Otherwise, S_FALSE as you said.

Also, there's one consequence from abovesaid: ARIA should stay in sync with HTML, otherwise, we may run into collision problems, when, for example, the will be denied for a selection change.

[jnurthen]

From @joanmarie on September 13, 2017 23:14

Given @asurkov's comments, combined with the fact that this issue is nothing new to ARIA 1.1 (just another instance of me wanting Core AAM to be thorough and precise 😄 ), I think we should postpone this to ARIA 1.2.