Revisiting user-scalable=no

Question

Previously, to achieve the effect of resizing for mobile, I have only ever used width=device-width, initial-scale=1 which worked no problem.

I recently discovered user-scalable=no as an option for the meta viewport. At first I thought it was a short-cut for setting maximum-width=1, minimum-width=1, however it comes with, in my opinion, one huge advantage:

This allows them [the web browser] to get rid of the dreaded 300ms delay on touch events that the browser takes to wait and see if your single touch will end up being a double touch.

Brilliant, I thought. Some basic testing on mine and some colleagues phones does indeed seem to remove the 300ms delay and makes for a much faster feel.

Reading into user-scalable some more rings some alarm bells. The general consensus appears to be that it, along with maximum/minimum-width, is "harmful" for accessibility. Some snippets from articles or posts written this year:

"And while initial-scale=1 is pretty useful, maximum-scale is bad news for accessibility."

"More often than not, there is absolutely no need for these harmful declarations: maximum-scale=1, user-scalable=no"

What interests me is both these references link to articles written two and three years old respectively, and the arguments in each:

http://a11yproject.com/posts/never-use-maximum-scale/

By setting maximum-scale=1.0, you are disabling the functionality to use pinch zoom on mobile devices, and forcing users to view your page a certain way.

http://blog.javierusobiaga.com/stop-using-the-viewport-tag-until-you-know-ho

[...] but there are lots of cases when the user might need to zoom: small body font (at least, for the user’s needs), checking some details in a photograph, etc

and

This parameter removes the ability to zoom in or zoom out, and it’s even worse than maximum-scale. If there’s a really special reason to use it (e.g., you are coding a web app and need to avoid zooming in form inputs)

Whilst I understand some of the concerns raised, I wonder if some of the arguments are about things which aren't, or shouldn't be, problems.

For example, stating that it removes the ability to zoom on input fields, one could argue that if a user is required to zoom in on form fields on a mobile optimised site there is a different issue entirely which should be fixed by not requiring users to zoom-in in the first place.

Font size I can accept is a problem, although a workaround could be to include font size controls (used to see them a lot, possibly not so much any more).

With that in mind is possible that user-scalable=no (or max/min width) isn't quite as horrific as it sounds, and with some thought/planning with regards to accessibility it could be safe to use and benefit from the advantages it brings?

For a fair argument and a small confession, I am probably thinking a lot more about mobile phone sizes than tablet sizes. With mobile phones I feel stuff is often zoomed in sufficiently (most things just set to 100% width), the same cannot always be said for tablets I'll admit. Also, I don't suffer from anything which affects my accessibility so I am probably naive to some of the problems other people face.

Answer 1

Stop using "user-scalable=no". Period. In the last 6 years, I cannot count the times that I've had to put away the iPhone and go to a desktop computer to examine something on a website because it simply wasn't visible and there was no way to increase its size because of this particular meta-tag. This is far and away the most useless tag. I wish it had never been created.

Answer 2

Do not prevent the user from zooming using user-scalable=no or maximum-width=1, minimum-width=1, unless your entire page is an interactive app with its own zoom mechanic overriding default pinch-zoom gestures, like Google Maps (but even then, consider disabling zoom more selectively, e.g. via event handlers on the inner widget container, allowing normal interactions on text containers like info boxes or search widgets).

• There's no longer any benefit, to touch response times or anything else. The question mentions that this option used to be abused as a hack to remove the 300ms delay before touch events triggered clicks while the browser waited to see if it was a double-tap to zoom in on an old-fashioned non-responsive wide page. However, major browsers dropped this in 2014 on all pages that aren't wider than the viewport, including mobile versions of Chrome, Firefox, IE/Edge and Apple iOS.

  To remove the 300-350ms tap delay, all you need is the following in the <head> of your page:

     <meta name="viewport" content="width=device-width">
  

• You should never prevent the user from doing something they can normally do unless absolutely necessary.

• You should never prevent the user from doing something they can normally do unless absolutely necessary. It's worth repeating this.

• There are many cases where preventing zooming can cause your users problems:

  • It prevents users zooming on a detail in an image. If you don't have images users might want to zoom in on right now outside of clunky slideshow widgets, don't assume a site won't in future
  • It prevents a user with poor eyesight zooming in on some text they're finding difficult to read.
  • It prevents a user with co-ordination problems, arthritis, fat fingers, etc etc from zooming in to make it easier for themselves to touch the correct link, button or input.
  • Even people with slim fingers and perfect co-ordination often want to zoom in while trying to select some specific text to copy or search on using touch.
  • It prevents someone zooming so something specific they want to show someone else, reference, or write down is large, clear and centred on the screen. For example, a phone number, reference code, name of a person or thing...
  • It's just needlessly annoying

But of course, even if you were unable to think of a single reason why a user might want to zoom in, you still shouldn't disable it, because you should never prevent the user from doing something they can normally do unless absolutely necessary.

Answer 3

Why zoom can be important

My parents are in their 70s and are sophisticated users for their age (mom plays video games!).

They have large mobile phones (mom has an iPhone 6 plus and dad has a Galaxy Note phablet).

Even then, they often need to zoom in to sites to read text or examine details.

Now, as a designer I'm faced with a choice.

• I could use ultra large fonts on my site to ensure maximal coverage for all user demographics including the elderly and sight challenged. But that may mean hurting the aesthetics of the site or severely limiting the amount of information I can just just to please a small minority of challenged users.

• I could just ignore the sight challenged and just design for the majority or "pareto" case.

• Or I could design for the vast majority of people and retain zoom (at the cost of some pinch gesture delay) to help the sight challenged.

I may choose to ignore the sight-challenged minority, use the "least-common-denominator" large font, or just allow zoom.

Very often, sites will choose the 3rd option as a reasoned tradeoff, but I'm just delivering information you can use to make the best educated decision for your own site.

Answer 4

"user-scalable=no" is overused. It is causing unpleasant user experience, ranging from discomfort to torture. It is part of a mindset that needs field-stripped from every programmer: the software knows best.

Humans are wondrous, amazing creatures, with far more sophisticated and faster audio and video real-time pattern recognition capability than any AI, capable of creativity and feeling, aware of their environment in a way no computer program could possibly be, but somehow, you believe your program knows better than the user if the user should be zooming in or out, or you believe scrolling and/or scrollbars should be disabled. You're not there. Humans attract one thing to themselves more than any other: exceptions. There are trillions of possibilities every second in this universe, and you think your software has accounted for them all? You want to delay shutting down, but don't know about the building being on fire? You want to reject an email address, because you didn't know about subdomains and it doesn't match your understanding of an email address pattern? You want to make a window or screen un-resizable or un-zoomable? Let me be clear: You are torturing users - knock it off! Software exists to serve the user, not the other way around.

Answer 5

There are very strong opinions against using user-scalable=no, but those are overlooking specific use cases where a site might actually be designed to be usable without the need to zoom, and zooming would be harmful to the experience. Let's keep that in mind. Just because people have abused a feature or used it incorrectly doesn't mean the feature itself is bad.