Intent to Experiment: aria-touchpassthrough

[Dominic Mazzoni]

High-level summary: this is a proposed ARIA attribute for touch accessibility. There's good support for the general idea that this is needed/useful, but no consensus on the syntax. It's implemented behind a flag now. I've got one website that would like to try a short experiment with this on Android; it will be a good opportunity for people to try out one real-world use-case and hopefully help drive the discussion towards consensus on the spec details.

Contact emails

dmaz...@chromium.org

Explainer / Specification

Just a bug thread so far:

https://github.com/w3c/aria/issues/1215

Summary

Screen readers with touch screen support typically include a "touch exploration" mode where you can tap or slowly drag around the screen and listen to feedback on what you're touching, before it activates. Setting aria-touchpassthrough on an HTML element indicates to a screen reader that touch events targeted at this element should be passed through directly, instead.

Blink component

Blink>Accessibility

TAG review

None

Risks

Interoperability and Compatibility

Gecko: No signal
WebKit: No signal
Web developers: No signals

The bug thread has broad consensus that something like this is needed, including from Apple/WebKit and from web developers. There's little consensus on the proper name or syntax for this feature.

Goals for experimentation

Test aria-touchpassthrough on a real-world mobile site that enables direct interaction with touch, but is potentially accessible to visually-impaired users.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

This feature is only needed on platforms with a screen reader for visually-impaired users that has touch support. This initial origin trial will only be for Android.

Is this feature fully tested by web-platform-tests?

No

Flag name

AccessibilityAriaTouchPassthrough

Tracking bug

https://crbug.com/1169823

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5169564486729728

This intent message was generated by Chrome Platform Status.

[Mike West]

Hey Dominic!

We talked about this in the API owners meeting this evening, and it wasn't clear to us whether an origin trial was actually necessary. Testing the mechanism behind a flag seems like it might give you the ability to experiment locally with various syntax options without going through the effort of running a trial with users out there in the wild.

Do you need to run this in a live experiment with users that can't set flags? Or would you get enough insight from a flagged experiment to make decisions about the API's shape?

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFz-FYxPTKrM4pYaw2HrEmKiodu1DwEHPPdB8eLxjNPKOPSFtg%40mail.gmail.com.

[Dominic Mazzoni]

Hi Mike,

Good question. We have a partner website that's planning to demo a feature shortly that's a particularly compelling fit for this ARIA attribute. It seems like a great opportunity to get some real-world engagement and feedback for a short time, without risk of breakage if the API changes because this is just a demo.

Happy to share more details in private.

- Dominic

[Mike West]

Thanks, Dominic. It sounds like there's active interest from a partner, and also that we can cap the length of the OT at something like M92-M93 to give you enough time to experiment with this spelling of the mechanism, and to inform the conversation around a spelling we can agree upon.

If that short timeline works for you, it LGTM.

-mike

[Dominic Mazzoni]

Thank you. That timeline will work out great.

- Dominic