300ms, Fast Click & Accessibility

accessiblity.md

Thoughts

Caveats: I suck at accessibility, so I am probably wrong on a lot of things.

The debate

Chrome 32 on Android removes the 300ms delay on touch events for responsive sites. This disables double-tap zoom, leaving pinch to zoom the only way to zoom content. This is an accessibility concern, as for some users double tap zoom may have been the only way they were able to zoom web pages.

Why did they do it?

For unimpaired users, a 300ms delay on link clicks/interactions with sites provides no benefit, and creates a sluggish UI. Many website owners, aware of the impacts of slow UIs, and trying to compete with native apps, used tools like FastClick to override this behaviour by removing the delay. Removing the delay at the browser level negates the need for tools like fastclick, makes chrome feel faster (competitive win for chrome I guess), and improves performance overall as fastclick has scroll performance implications.

What's the impact?

A portion of users, who find pinch-to-zoom difficult, will now potentially be left out of the web. While businesses might not be bothered in the short term, this is clearly not a long term good for the web/society.

But might it actually be better (gasp)?

Chrome 30 on android has an option to force allow zooming on all sites as an accessibility option. If this still exists in Chrome 32, I'd argue this may actually be a step forewards for accessibility. Why?:

• Currently, "dumb" website owners use fast click to disable the 300ms delay: which even with "force allow zooming" enabled breaks double tap zoom.
• As the 300ms delay goes away, website owners can remove fast click, as it will be redundant, which, assuming chrome keeps "force allow zooming" will mean that double tap zoom works again.

Now, the above means that impaired users have to enable an accessibility setting to be able to use their browser, which is a bummer, but at least it puts them back in control if we get rid of hacks like fast click.

All thoughts welcome!

@jakearchibald Thanks for that - I do appreciate you taking the time to contribute.

However, whilst you are saying that the approach to accessibility is handwavey because it's rules not tools I've never actually seen anything other than rules for the 300ms delay being slow. Yes, 300ms is objectively longer than 0ms - what we're talking about is subjectively is it too slow, and - in particular - is it sufficiently subjectively slow that it provides a noticeable barrier to user engagement.

I know Ilya has shared some great data about how interaction on google.com drops off as you add artificial delays into the page to demonstrate how page speed affects user engagement - can you share anything similar for the 300ms delay?

@jakearchibald No offence Jake, but all the others in this thread know me personally, so it would be worth considering that as the context in which I'm saying stuff like that (not that you'd know this, but you do now!). Of course I'm more open minded than that (which these guys know already) - I meant that @latentflip has a much stronger view swinging the other way, as expressed in the thread, and I will simply trying to point out that I'm not thinking from the same standpoint so it's not a debate I would expect a clear outcome from - particularly as all these things need to be held in tension for the best for users.

Thanks for the feedback - it's good to have insight from your / the Chrome team's perspective. I do think phrasing such as "snake oil hand-wavey approach to accessibility" isn't that helpful, given that any concern about accessibility is better than the sweet FA most developers seem to give (or not) - and some of us don't have the luxury of as extensive a dev experience that you or others do, so a bit of a gentler tone might not go amiss. Then again, I've seen you give talks several times - so I also know it comes from a good place!

Is the likelihood that a user with disabilities (particularly, in the case of needing double-tap) would have these Android features turned on simply to use the device? It sounds like that kind of OS-level support means that it's a far less severe issue - though I'm still intrigued as to whether the other browser vendors follow suit or whether Chrome ends up the only browser vendor without that as a gesture.

@decadecity Did you see the videos in my comment? Can you see a difference?

Those studies around drop-off apply here. When Amazon say they see a 1% increase in revenue with every 100ms saved, it doesn't matter where that 100ms comes from, be it DNS, proxies, response construction or simply the device waiting to decide if that really was a "click".

Also see http://theixdlibrary.com/pdf/Miller1968.pdf (warning, pdf), a 1968 study on response times, where <= 100ms "feels instant" comes from.

Even if we ignore all that, and say users can't tell that their tap interactions are now 300ms faster, what have we lost? What specifically have we broken?

@benseven Sorry if my tone seems off, I'm going to blame a hangover. The poor quality of accessibility advice is a particular bugbear of mine. Yes, it's good that people are thinking about it, but you can't claim a particular app or site is inaccessible based on the destroyed user experience of someone you invented, because you can do that for anything.

"Is the likelihood that a user with disabilities would have these Android features turned on simply to use the device?" - features like screen readers are a total waste if they don't. But I don't have numbers. However, if we're going to consider the knowledge a user must have to turn on these features, we must also consider the knowledge the user must have to know double-tap is a thing. I mean, it's not a particularly intuitive gesture is it?

"I'm still intrigued as to whether the other browser vendors follow suit or whether Chrome ends up the only browser vendor without that as a gesture"

I'd bet on Firefox doing the same. They dropped the 300ms delay on no-zoom pages as we did.

Apple? Less likely. Even on no-zoom pages, double-tap is a scroll gesture, which is really odd IMO. They don't seem interested in dropping the delay. Maybe [baseless and outrageous conspiracy theory warning] they have a financial interest in the web feeling slow, making developing native apps more appealing.

@sherred Regarding pointer events, the touch-action property isn't a fix. If you set it to none, yes you lose double-tap and zoom, but you also lose scrolling. You'd only use it on elements where you want javascript to have complete say over the touch events, eg a painting canvas.

The pointerup event does what you want, it's like touchend but won't fire if the browser does something with touch events itself (eg, scrolling). However, if we rely on that, developers have to code it in for everything they want to be faster, and that means putting js listeners on things like links, just to speed them up. What we did in Chrome beta sped up large areas of the existing web, which is way more valuable.

That said, pointer events are brilliant. MS did a fantastic job. We're implementing them.

** Is double-tap even useful? **

The double-tap gesture zooms the viewport so the text fits the width of the screen. Another double-tap zooms back.

What do you think double-tap does on a mobile-optimised (width=device-width) site? In the vast majority of cases the text is already at viewport width, so it simply zooms in "a bit". Perhaps this "a bit" is exactly what the user wanted and needed, but probably not. A further double tap zooms back out.

Unless there's evidence to the contrary, that section pretty much seals it for me.

Apologies for the late arrival to the party, and little contribution. At first I was saddened to hear of this, then didn't get round to forming any constructive thoughts... Very quick dump from me, between engagements:

• the fact I'm able to park it with indifference is a telling sign this isn't as big a deal to me as my first reaction :(
• as users and developers we've learned to live with a wide range of implementations over the years; standard specifications for gestures would be pretty neat
• each case should be independent, but sometimes you need to pick the battles... WCAG WG today proposed alternatives to alt attribute, which piques my interest
• unfortunately it's true on the vast majority of implementations width=device-width won't zoom that much. However that assumes device-width is using 1 column displays, you may still have floated columns in there to zoom in on.

I was a bit disappointed to first learn of it, but take some solace in the fact it's available as an option.

(I've had a hard time working out how to say this and had an even harder time deciding whether to post this at all but...)

The exact implementation details of this in one browser aren't a major issue for me but the background to this is - to me - symptomatic of a fairly serious problem I have with our industry as a whole. However, due to the nature of the input from one of the contributors to this thread I'm no longer comfortable discussing it in a public forum.

@cmcp Multicolumn interfaces on width=device-width sites are a concern of mine too. I've been gathering them and showing them as problem-cases internally. If we get enough of those, I can push for change. If you find any, let me know, or post them on the ticket.

In terms of "picking battles", if you think this is still an accessibility concern, tell me how and show me examples. If there turns out to be a real-world issue, we can fix it. That's why we are publicising the feature at it hits beta.

@decadecity What's the serious industry problem? If you're uncomfortable discussing it here, you can email me at [email protected].

Use FastClick and attach it only to the active elements (a, label, input, select, textarea, button). What's the problem?