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!

(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 jakearchibald@google.com.

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