The issue:
..mobile browsers will wait approximately 300ms from the time that you tap the button to fire the click event. The reason for this is that the browser is waiting to see if you are actually performing a double tap.
(from a new defunct https://developers.google.com/mobile/articles/fast_buttons article)
touch-action
CSS property can be used to disable this behaviour.
touch-action: manipulation
The user agent may consider touches that begin on the element only for the purposes of scrolling and continuous zooming. Any additional behaviors supported by auto are out of scope for this specification.
– https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action#Values
touch-action
is now supported by all major mobile browsers.
Note that iOS 9.3 has not been released yet. (2016 02 13)
In ./webpack.js I am first detecting if the touch-action
property is supported. If it is, I am using it to set the style of document.body
. If it is not, then I am using webpack require.ensure
to download FastClick polyfill to fix the issue.
@dylanb I'd take the WCAG guidelines with a pinch of salt.
For example, the guidelines haven't considered a web outside of the scroll container. You see scrolling is no longer the only way to consume media on touch capable devices. You can also flip pages like a book. This is relevant because it usually gets hard to scroll down a 5000 words essay on a mobile. The post thins down into a thick never-ending scroll, almost like billing paper, and people then struggle between scrolling-down carefully and zooming-in until they give up halfway. The same post is usually a short/flat scroll that is just 3 pages long on the desktop.
I think WCAG should reconsider these ideas ground up for they are only porting old ideas from the old web at the moment. We have a web that doesn't rely on pointing devices!
Another case for the point: WG hasn't considered the idea that typography could be scaled responsively and exactly with
viewport units
. Without developers needing to maintain and construct layouts with complicated break-points using @media-queries. How many break-points will make it good to suit all the screens out there? Handling it with unscalable typography (em/pt/px/% whatever) with 3/4 break-points itself is expensive, unmaintainable and messy. It is in this context allowing zoom to scale is also a totally useless idea. Because the text can be scaled legibly withvw units
alone; and far better than it has been agreed upon by the WCAG (range 0<zoom<200%). And have the page-scroll remaining "taut" on the mobile screen (which is why people disable zoom in the first place).In my opinion accessibility/standards need to revisit these ideas keeping distance from the desktop-only web of the 90s. Avoid pushing that monoculture and messy unmaintainable definitions that no longer hold good. Just a thought.