Activation point or sub-element click target (maybe aria-hitpoint?)

[cookiecrook]

ARIA needs the ability to specify a positional activation point (tap/click target) for a larger interactive control. For example, the activation point of a slider is the center point of the slider thumb.

This allows AT like VoiceOver to simulate touch events at the proper location. With native sliders on iOS, a VO user can double-tap and hold (sending a pass-through touch) and then drag (changing the slider value) and hear the fine tuned updates in real time. ARIA sliders already have the ability to do the real-time updates (by changing aria-valuenow and optionally aria-valuetext) but they have no way to specify where the touch-drag or click-drag should start.

Typically, experienced developers implement this by making the visible slider thumb element the one with role=slider but this has negative impacts:

• makes the control harder to use for lowviz screen reader users (e.g. Zoom+VoiceOver on Mac, or ZoomText users on Windows
• it's impossible or difficult to use this technique on elements with custom drawn views (e.g. canvas)

I think we need two APIs:

1. Required: ability to specify a coordinate property [x,y(,z?)] as the activation point in CSS pixels from the upper left of the control using the ARIA role. The spec should require UAs translate pixels if the view is manipulated with CSS transforms.
2. Optional but easier for most developers: ability to specify a descendant element as the indicator of the activation point. The spec should require UAs translate the activation point to the center of this descendant element and account for any transformed views.

The spec should allow (RFC-2119 MAY) for users agents to fuzz the center point by a few pixels. The goal being to make it more difficult or impossible for web sites to know the difference between a sighted touch user and an AT user of screen reader or switch software.

iOS has had a similar API since iOS 5 (seven years at the time of this filing) https://developer.apple.com/documentation/objectivec/nsobject/1615179-accessibilityactivationpoint

[scottaohara]

possibly related issue #1319

[jnurthen]

Dec 9, 2021 - Deep Dive

[cookiecrook]

Another use case from iOS that is often mimicked in web UI. A "switch cell"... Rather than expose these as separate, redundant navigation elements, an iOS VoiceOver user will hear the table row label and the switch as a single element, effectively one "Tab" stop.

In Web UI, you can make this accessible by either making the entire row clickable (not always desirable in mainstream UI) or by hiding the text label and making only the switch accessible... This second solution is fine for keyboard navigation or other linear navigation (like swipe to next/previous), but it breaks touch-based exploration common in modern touch-based AT. The benefit to allowing the full row to be the bounds is that a user can drag their finger around the screen to find which elements are represented by that area...

[cookiecrook]

The easiest, but potentially incomplete solution discussed this morning was an element-based one.

<div role="slider" id="slider1" aria-label="Speaking Rate" [other attributes trimmed]>
  <div role="thumb" aria-controls="slider1"><!-- thumb is a bikeshed name too specific to sliders-->
</div>

But this element-based solution may not handle the single-control-rendered-as-<canvas> case which is becoming more common with shadow DOM custom elements.

[cookiecrook]

We could also make a more-specific variant of aria-controls:

<div aria-hitpoint="IDREF">

thumbElement.ariaHitPointElement = sliderElement;

Updated Musings:

• Not sure if the direction (controls vs controlled-by) is clear. Maybe hitpointat or hitpointfor?
• Is "hitpoint" too associated with RPG damage points?
• multiple common spellings ("hitpoint" vs "hit point") means there would be ambiguity in the DOM property capitalization: ariaHitPointElement or ariaHitpointElement?

[cookiecrook]

Working group participants (Dec 16, 2021 meeting) discussed for ~5m, and agreed this should be an attribute, not a new role. Beyond that, no specific decisions were made.