Does 2.5.6 Concurrent Input Mechanisms apply to platform accessibility APIs?

[WestonThayer]

Here is an example of a button who's functionality works with keyboard, mouse, touch, and pen — but not platform accessibility APIs when run in Firefox or Safari:

<button id="btn">Click me by focusing with the keyboard and using SPACE or ENTER</button>
<p id="output"></p>

const btn = document.getElementById("btn");
const output = document.getElementById("output");

btn.addEventListener("keyup", (e) => {  
  if (e.key === " " || e.key === "Enter") {
    output.innerText = "Clicked via 'keyup'";
  }
});

btn.addEventListener("pointerup", (e) => {
  output.innerText = "Clicked via 'pointerup'";
});

If you run this code in Firefox or Safari and attempt to invoke it via a platform accessibility API, like UIA or IA2 on Windows, it does not work because the keyup and pointerup events never fire (https://accessibilityinsights.io/docs/windows/overview/ is a quick way to try UIA's API, and XCode Accessibility Inspector is the analogous choice for MacOS. You could also use NVDA in browse mode or VoiceOver's VO+SPACE shortcut).

Behind the scenes, this is because browsers receive the platform accessibility API invocation call, but do not have an equivalent DOM event to fire. Instead, they perform some emulation, usually firing synthetic mousedown, mouseup, and click events (this example works in Chromium because that browser also fires a synthetic pointerup). In this case, the code is relying on pointerup and does not have a click handler, so the interaction is missed.

---

I'm trying to understand if this scenario violates any WCAG 2.1 SCs.

2.1.1 Keyboard Accessible seems inappropriate given that keyboard interface is defined as "interface used by software to obtain keystroke input". The platform accessibility API's invoke method does not generate any keystroke input.

4.1.2 Name, Role, Value says "...and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies." Invoking a button doesn't normally meet my understanding of setting a value. There is no notification of changes because the change was never able to be effected.

That led me to 2.5.6 Concurrent Input Mechanisms. I think the intent was probably to define input mechanisms as mouse/keyboard/touch/pen, but the term is not specifically defined.

So my question: does this scenario fail 2.5.6 because the platform accessibility API's invoke method can be seen as an input mechanism? Does it fail any other SC?

[patrickhlauke]

my take is no, pure platform API calls are not what the SC attempts to cover. only different actual input modalities.

incidentally, at least on Windows, SRs generally also send faked key/mouse events exactly to make sure that controls that may have been coded with mouseup etc events do get fired

[WestonThayer]

Thanks, dang! Is there any SC this would fail then? These scenarios seem rare in the wild, but end up either creating a poor UX for AT users by forcing them to discover a workaround, or potentially blocking (ex: macOS Voice Control attempts to use this API for a command like "click button name", which would have no effect).

incidentally, at least on Windows, SRs generally also send faked key/mouse events exactly to make sure that controls that may have been coded with mouseup etc events do get fired

The SR does? I tested with both NVDA on Firefox and macOS VoiceOver with Safari. In both cases, the behavior was no different than using the accessibility API directly. That convinced me that it was actually the browser faking the events.

[patrickhlauke]

FWIW just testing with Firefox/NVDA, the above works - it fires keyup. Chrome/NVDA fires pointerup.

[WestonThayer]

Do you have NVDA in browse mode?

[WestonThayer]

I did a brief screencast to demonstrate the behavior I'm seeing with NVDA + Firefox and VoiceOver + Safari. FYI GitHub mutes videos by default.

Screen.Recording.2023-06-30.at.3.11.43.PM.mp4

[JAWS-test]

The example can be modified to not work with screen readers like JAWS:

• any keyevent on the button itself
• any mouseevent only on a child element of the button

Then the following happens:

• keyboard users can operate the button with keyevent
• mouse users can operate the button because of mouseevent
• JAWS users cannot operate the button because JAWS, in its default configuration, converts keyboard input to a mouseevent, but the mouseevent is not on the button.

This is not a contrived example, I have experienced this in testing.

It is clearly a violation for me. You are right though that no SC really covers this.

[WestonThayer]

I’m coming around to the idea that 4.1.2 is a good fit and intended to apply to this situation.

states, properties, and values that can be set by the user can be programmatically set

If my example instead featured an expand/collapse button or accordion pattern, there’s clearly a “state” that must be programmatically settable, it’s even given as an example in the states definition:

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

I think my simple button example fails 4.1.2 because there’s no programmatic way to trigger the button’s pressed state.