Caveats: I suck at accessibility, so I am probably wrong on a lot of things.
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.
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.
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.
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.
Now my rambling incoherent thoughts (Orde I got the reference before the parenthesis - go me?):
First I second what Orde.
If this needs a solution I think that the preferable solution out of all the proposed ones that I've come across are Pointer Events, which are now a candidate recommendation W3C specification. Specifically the new -touch-action CSS property.
Setting it to none in CSS prevents default user agent behaviour – such as pinch & double-tap zoom – from being triggered. As it's CSS you can target only the specific elements for which you might want to avoid any delay.
It doesn't depend on the viewport meta tag and doesn't relegate double-tap to second class citizen hidden away in a settings menu.
I'd rather developers get behind that instead of just hoping that other browser vendors follow Chrome's lead.
Yes it can be abused by setting touch-action: none to the body tag, but as we are all too aware this is pretty much unavoidable.
Tying back to what Orde said, the 300ms is a small fry issue compared to all the other delays imposed on users due to forcing them to download a load of gubbins that they don't really need. The first focus should be doing everything we actually can to make performance as good as possible, then maybe we can start worrying about user agent behaviours.
Final point, as I understand it – so possibly incorrect – the 300ms delay issue came about due to frustrations with actions/functionality dependent on click events being slowed down by the browser behaviour. Maybe web dev efforts would be better spent in auditing that all those click event dependencies are actually necessary, and where they are coming up with an alternative