Intent to Experiment: aria-touchpassthrough

Skip to first unread message

Dominic Mazzoni

May 19, 2021, 7:58:14 PM5/19/21
to blink-dev

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

Explainer / Specification

Just a bug thread so far:


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


TAG review



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)?


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?


Flag name


Tracking bug

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Mike West

May 20, 2021, 3:27:27 PM5/20/21
to Dominic Mazzoni, blink-dev
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?


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
To view this discussion on the web visit

Dominic Mazzoni

May 20, 2021, 4:04:50 PM5/20/21
to Mike West, blink-dev
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

May 21, 2021, 6:44:46 AM5/21/21
to Dominic Mazzoni, blink-dev
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.


Dominic Mazzoni

May 21, 2021, 12:12:00 PM5/21/21
to Mike West, blink-dev
Thank you. That timeline will work out great.

- Dominic
Reply all
Reply to author
0 new messages