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!

"...on touch events for responsive sites"

For the sake of clarity / pedantry, on any site that sets a viewport of width=device-width, AFAIK. This is also potentially standalone mobile / tablet experiences that are not technically responsive (i.e. the detection is on viewport mode rather than fluid layout).

"...and creates a sluggish UI."

Devil's avocado: While I agree, to an extent (losing it makes UI perceptibly faster), 300ms is barely anything. If you asked a user, it's unlikely they'd be able to put a finger on this specific delay (ba-doom-tishhhh). Sluggish is a bit strong, in my opinion.

Everyone is right

Your points stand - and perceptibly faster UI is important to close the gap with Native.

But, the fundamental issue for me, here, is that we're taking an established, cross-platform gesture already in use by impaired users, and taking it away. Combined with the potential that the user is on an OS where the application auto-updates, you end up with a pretty bad situation where one day, any site trying to serve an optimised layout suddenly can't be tap-zoomed by these users (or any users - this is not just a gesture used by less able folks). The resulting option is tucked away in a menu - how do these users know that? Not everyone tinkers in the way that we do.

At the end of the day, my issue is dicking with established patterns. There's no other browser doing this currently, and while I think the delay issue needs addressed, that shouldn't be at the expense of any user group, never mind one of the more vulnerable groups. I don't like that the Chrome team are seemingly prioritising the quick UI 'needs' of authors over the common tools available to users.

Caveats: Most of us suck at accessibility, and this is pretty much my fixed opinion shared - I'm unlikely to be swayed by further debate but I think it's an important conversation to be having, and this is far better than Twitter.

300ms is barely anything.

http://www.nngroup.com/articles/response-times-3-important-limits/ It may seem small, but it's above the 100ms "don't worry about it" level.

But, the fundamental issue for me, here, is that we're taking an established, cross-platform gesture already in use by impaired users, and taking it away.

But many sites are already taking it away with fast click, for better or worse.

At the end of the day, my issue is dicking with established patterns... I don't like that the Chrome team are seemingly prioritising the quick UI 'needs' of authors over the common tools available to users.

IMO one of the most important things for the web is that it can compete with native, particularly on mobile. Yes, they are dicking with an established pattern, but if that pattern stops us competing with native, then we'll lose mindshare to native, which I might add rarely has any zooming capabilityt at all.

The resulting option is tucked away in a menu - how do these users know that?

It's "tucked away" in the only menu under a heading of accessibility.

It may seem small, but it's above the 100ms "don't worry about it" level.

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.

But many sites are already taking it away with fast click, for better or worse.

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.

IMO one of the most important things for the web is that it can compete with native, particularly on mobile.

We agree on this.

which I might add rarely has any zooming capabilityt at all.

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.

It's "tucked away" in the only menu under a heading of accessibility.

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... ^_^

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.

Fair point. As the rest of the web on mobile speeds up, that 300ms is only going to get proportionally more annoying though.

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.

Also an excellent point.

I guess our fundamental, and probably not reconcilable, differences boil down to:

• You would prefer to preserve "backwards compatibility", at the expense of future improvements.
• I would rather push the web forward faster to make it better for everyone, and break a few things along the way at the expense of inconvenience for a percentage of users (like a douche).

I guess what I'm hoping for is a better solution - a way to preserve double-tap without the delay.

It's also a little black and white to suggest I'm for the old ways and you're for the new. I want to see the web move forward, but the web is the most inclusive tool we've created - and keeping it that way is about being smarter about how we solve this kind of issue.

I haven't had a close look at Tappy by Filament Group - https://github.com/filamentgroup/tappy - but I wonder if it also breaks double-tap zoom... it looks more involved, but I would always rather include a small lib to solve these issues while the browsers work out a better way (and with that in mind, maybe the competitive edge you identified for Chrome might drive other browser vendors to find their own, better way around this).

I guess what I'm hoping for is a better solution - a way to preserve double-tap without the delay.

Yeah, I guess I would be pretty happy with that too, if it's possible. Though I don't see how it is. The best you could hope for would be allowing a delay for double tap, unless they click on a "link" like element. But that sounds like it would be potentially just as confusing.

It's also a little black and white to suggest I'm for the old ways and you're for the new. I want to see the web move forward, but the web is the most inclusive tool we've created - and keeping it that way is about being smarter about how we solve this kind of issue.

Sorry, yes, on reflection that sounds harsher than my intention.

haven't had a close look at Tappy by Filament Group - https://github.com/filamentgroup/tappy - but I wonder if it also breaks double-tap zoom...

It looks like it work like i mentioned above. If you tapped on a "tappy" bound element, DTZ would be broken, if you tap elsewhere it'd work.

Sorry, haven't had much time to add to this as I'm currently sacrificing what little remains of my cognitive facilities at the alter of browser versions (this is just for Android Browser: http://decadecity.net/blog/2013/11/21/android-browser-versions ). Apologies in advance if I sound ranty, it's ont personal - just that I haven't had time to think the edges off my opinions :-)

The issue here isn't just fastclick and it's ilk - there's a much bigger issue with disabling zoom in the viewport.

My main (half formed) issue here is that in order to solve a (minor UI?) problem for an unknown number of users (but a lot of developers - not users, I'd like to see some RUM data for this issue), the received wisdom in the twitter echo chamber of the "web celbs"* is to use something that one of them cooked up and the others proclaimed as unicorn shit good but has more serious problems for a another unknown number of users. the intersection between the people "fixing" the first problem and the people impacted by the side effects of their "fix" is ~0. the other issue is that for the people hit by the side effects it can make the difference between using the web or not whereas the "fix" makes it a tiny bit better for people who already have no difficulty using the web. because the high (trigger warning: sexism) priests of the echo chamber proclaimed it as "best practice" it's now been cargo culted so much that the major mobile operating system vendor has had to include a fix for the fix as a setting in their flag ship browser.

We can't keep breaking the web this badly as a side effect of "correcting" browsers' default behavior that we don't agree with - with power comes responsibility and we're behaving too irresponsibly to be trusted with the power we have.

OK, back to the mountains of browser analytics madness. (That's a Cuthulu reference not a mental health joke: https://en.wikipedia.org/wiki/At_the_Mountains_of_Madness )

• Nobody in particular, but the phenomenon in general. And it's not just restricted to web - seems to be part of the more general human condition.

"Priests of the echo chamber" is my new band name.

Good braindump :)

/me wonders if this debate has reached it's inconclusive end

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

@latentflip The end of this debate will be inconclsuive but I don't think we're there yet :-)

Hey, so I work at Google and pushed heavily for the 300ms delay to be dropped in this case.

"300ms is barely anything"

I have to call complete bullshit on this, sorry. Compare http://www.youtube.com/watch?v=BHsVVMCr39Y to http://www.youtube.com/watch?v=i74FAsNNEPQ. The 300ms delay is a huge contributor to the perception that the web on mobile is "slow".

"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"

We need to get away from this snake oil hand-wavey approach to accessibility. It's not constructive to invent people with particular disabilities who's experience is now broken. Let's look at the evidence:

Zooming is not disabled

I think everyone here knows this, but I want to make it clear. In older versions of Chrome you could get rid of the 300ms delay by disabling zooming using the meta viewport tag. People did this because of the performance benefit. It's also bad, because zooming is a great feature and relevant to most sites.

In Chrome 32, currently in beta, we've removed the double-tap feature on sites with width=device-width in order to remove the 300ms delay. However, you can still pinch-zoom. Does this create an accessibility issue? First…

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.

Android has native screen zooming

Android has a whole range of accessibility features, one of which is screen zooming. This works not only in the browser, but across the whole operating system. This feature can also be activated with a single finger, using a triple tap.

Double-tap on mobile optimised pages doesn't do anything particularly useful and in my opinion it's worth dropping to save 300ms per interaction. The reason we make beta releases available is to get feedback on these features, but "what if"s don't cut it. If the removal of double-tap has broken a site for you or someone you know, tell us, file a bug or say something at https://code.google.com/p/chromium/issues/detail?id=169642. We want feedback, but with evidence, not hand-waving.

You may be interested in the discussion at https://twitter.com/stevefaulkner/status/399177271421837312, but more is good.

On the performance team at Chrome we say "Use tools, not rules" because we see a lot of performance "rules" that never worked, or improved performance a number of years ago but now hurt it. A better way is to test and see what actually happens. I feel that accessibility is stuck in "rules" land, and when I did some actual user testing with people with a range of disabilities I was astounded by how badly "rules" had served me in this regard. Part of the reason there's a ton of poor accessibility advice is because we don't have the tools to verify/debunk them. We need better tools, I don't know what those tools are, but we need them.

@benseven "I'm unlikely to be swayed by further debate" - this is the worst. You should always be prepared to change your viewpoint as you learn more or things change.

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

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