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.
It's also significantly below the 1.0s "limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay" - like I said, "sluggish" is a bit strong.
I don't want to be the 'citation needed' guy, but without data to back this up, neither of us can argue that there is a statistically significant portion of sites using or not using fast click. My gut says it's not measure in percentage points of the entire web, but like I said, data.
We agree on this.
Most native platforms have UI guidelines that state appropriate sizes for text, and typically ways to address the size of this text through a universal accessibility menu when setting up the device, AFAIK. You have a point, but neither of us are able to claim much knowledge of accessibility for native applications, so its relevance to behaviour in a web browser is difficult to work into the discussion.
See, this is the issue. We're seasoned veterans of poking at stuff. It might be under a menu. That menu might be easy to reach. It might be categorised under accessibility. But before it was an ingrained browser behaviour that has now been displaced and may not be discovered or considered as an option that can be re-enabled by a typical user. As I alluded to last night, as long as you're happy enough to go tell all the impaired users of Chrome that this is the case, I'm good with it too... ^_^