Re: Apple disabling “maximum-scale” behavior on responsive websites in iOS10
I was having a bit of discussion on Twitter about Apple’s recent change in iOS to start ignoring the maximum-scale setting on websites.
My initial tweet was:
I was quoting this tweet revealing the news about the meta tag
I wanted to respond to Ethan Marcotte’s (or whoever is behind the RWD account) claim that my perspective is “rather gross an ableist”.
As a web designer for five years and now a user interface designer for five years I’ve spent quite some time dissecting accessibility issues on a level that I’ve seen few colleagues do it, so I don’t like to see myself called having an “ableist” view on accessibility.
Checking my websites with Apple’s Voiceover and getting websites AnySurfer (Belgian accessibility label, see their website) ready was part of my day job for quite some time.
What I am talking about here is that if you try to release a web app as a URL, i.e. the only experience of that app being a website, in many cases will inevitably make a worse app than when you wrap it in a native container (think Phonegap).
This is because I believe Apple constrains you in subtle ways to be able to do what is needed to make an app as good as a native app using web technology.
In this post I don’t really want to talk about the politics behind things (obviously Apple wants people to release their stuff on the App Store), but really about what’s happening for the end user and what that means for designers/developers making choices surrounding these things.
Over the years, with every release of iOS, Apple has never really embraced the idea of application on the web.
Adding a site to the homescreen and running it fullscreen is a broken experience plagued by new bugs every single iOS release.
It’s just not a reliable way to make an app, with problems ranging from caching issues to problematic behavior on poor connections to plain visual bugs that only occur when an app is added to the homescreen.
You’d be forgiven to think that Apple is effectively sabotaging the experience of adding an application to your home screen via a URL.
Back to the topic at hand — Apple starting to ignore the web developer’s preference to either zoom or not zoom in iOS 10.
For those who don’t know, you can make a website responsive using the following code in the `<head>` tag:
<meta name=”viewport” content=”width=device-width, initial-scale=1">Combine this with fluid grids and media queries (or clever CSS that doesn’t depend on fixed widths) and you have yourself a responsive website.
Ethan Marcotte himself coined this with the initial ALA article on responsive web design and it’s a topic near and dear to my heart.
Anyway, using this meta tag, the browser starts responding to the width of the device instead of a set size. If you don’t do anything, iOS will render a website at approx. 980px and as a user you’re probably going to want to zoom in to be able to read anything.
Historically this has been the way that you have been able to browse non-responsive sites easily on a device .
When iOS came out, websites weren’t responsive at all, and up to this day a lot of websites still aren’t. This is fine because we have browser zoom.
(Note: I am talking about iOS mostly but most of this also applies to Chrome on Android, other mobile browsers etc.)
For example, if we look at one of my favorite websites “A List Of Fallacious Arguments” on an iPhone you will see that it needs some zooming to be able to be read.
This is a website that was made before responsive design, and it’s not really legible on a phone without some zooming and panning. The author would do well to add the responsive meta tag and using the existing code the site would instantly be responsive.
Now, you can disable the fact that a users can zoom in their browser by adding “maximum-scale=1” to the meta tag.
<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1">If you would do this on the aforementioned “A list of fallacious arguments website”, that would be truly bad, because nobody would be able to read it.
I argued that the change that Apple applied — effectively disabling maximum-scale=”1" usage — is better for accessibility but worse for most users.
The reason that it’s better for accessibility is relatively obvious — because even if a web developer adds maximum-scale=”1" to the code anyone will always be able to zoom websites.
In the past there’s been some frameworks who added this by default, not everyone know about it, and we ended up with websites that weren’t browsable on mobile devices.
But I would argue that when you add maximum-scale=”1" to a proper responsive website, the user experience actually improves for those with good eyesight.
To explain why is a bit complicated, because it requires a bit of knowledge about iOS and it’s zoom behavior, but I’ll try and have a go at it.
In my experience, when people enter a form on a responsive website they are constantly being zoomed in and out.
If you take a really basic form like this one:
http://codepen.io/wolfr/pen/ezZoMQ
And you look at it on a phone, the default iOS behaviour is to zoom in when you tap a field.
When we add some real basic CSS to that, the browser still zooms in.
Now when we add “16px” to the input, the browser stops zooming in.
This is the experience we want, that feels right to me.
Now, adding that 16px to inputs to me feels like kind of a hack. The fact that inputs are 16 pixels has little to do with what we are trying to achieve here.
The way to achieve what we want to achieve is the “maximum-scale” on the viewport. Which Apple is now ignoring on purpose.
Now, let’s make things just a bit more complicated by adding a radio button to the form.
http://codepen.io/wolfr/pen/MeyRzP?editors=1100
When you enter this form you have to be smart on where to tap or you will mistap.
Many application experiences are way more complicated than this; if even a simple form becomes a bit confusing because of zooming in and out, what if you are in a more complex application context?
I am all for being able to zoom documents to be able to read them.
Documents should be able to be zoomed. People like my friend Roel Van Gils who don’t have perfect eyesight need to be able to zoom web pages so they can read them.
But when you are doing heavy interactions on a touch screen, you don’t want to be bounced around zooming in and out all the time. You need a reliable way to navigate between screens.
This counts for websites, but where it really counts is when want to achieve that app-like experience using web technology.
I bet some of you web persons reading this far have at least been following some of the discussions surrounding progressive web apps.
If not, the fastest way to bring you up to speed is that the discussion is about how to bring what makes apps great to website without losing what is great about the web.
I don’t want “able” users to be able to zoom in accidentally in an app-like experience, because it effectively breaks that experience.
I do want visual impaired users to be able to zoom in, because obviously, if they can’t read what’s on the screen they can’t use the app.
But let’s repeat my argument: by allowing visually impaired users to zoom in (by not disabling zooming) we are effectively making the experience worse for able users.
To me this is just true; it has nothing to do with being “ableist”.
Ideally I want the best of both worlds, but the problem is that it doesn’t work this way. An app context is vastly different from a document context.
When you are in an app context you are typically looking at a division of panes that can be manipulated individually. There are fixed panes and scrollable panes.
When I make (web) applications that have fixed headers and footers containing the app controls, I am effectively simulating the look of a native app.
Native apps don’t allow you to zoom at all.
This is an accessibility issue, but I would argue that when you don’t need zoom, it’s better, because you will never inadvertently zoom causing weird interface states where you as a user don’t know what’s going on anymore.
[Native apps also don’t allow you to select text, something which sometimes really bothers me if I’m trying to make sense of what my Japanese friends are saying — hey, accessibility matters for me too)]
Th way that native apps improve accessibility for visually impaired users is in 2 main ways:
- features like dynamic type scaling (see http://useyourloaf.com/blog/supporting-dynamic-type/ )
- the OS-wide zoom (see https://support.apple.com/en-us/HT204390 )
Now, within the browser context I imagine that as a visually impaired user you know where Safari’s controls are by memory and you want to be zooming the content on a web page.
But in an unknown app you probably want to zoom in to different parts to be able to see what is going on. Since an app is based on a pane system, it’s not realistic to zoom certain parts individually, and a global zoom such as the OS-wide zoom makes sense.
As a user you have a limited amount of gestures available to you on a touch device. There is tapping, there pinching in and out, there is swiping.
Within the context of a browser, Apple uses pinching for zooming in and out, swiping from the left edge to return to the previous page.
As a web app developer, if you take your app native you are effectively making sure that you have more control over what users can and cannot do in terms of gestures, which might make your app a lot better if it has parts that require heavy interaction — for example, dragging and dropping a calendar event.
Web tech is popular these days as the way to design and develop custom interfaces. Instagram’s feed is a web view. Slack, the popular chat application, is just an Electron shell.
Why is this the case? Mostly because developing custom user interfaces in a traditional environment (think native Mac apps) is hell, and the last few years CSS has become so powerful that it’s almost the ultimate technology to develop user interfaces.
Smart CSS properties like flexbox can do layout things that are nigh impossible to code in a native environment.
(Not to mention people like to use web technology because it’s open, it’s multi platform, it doesn’t have to be inside Apple’s walled garden etc.)
When I see the demo of Affinity Photo on an iPad Pro I want to be able to make that using web technology.
As a designer/developer I want the control over gestures, zooming and pinching.
I think Apple should leave the choice of whether you can zoom in or out on a website (or Webview for that matter) to the developers.
So this change doesn’t feel right to me, and to get back to my initial thought — it’s once again a subtle way for Apple to ensure that if you really care about the end quality of the experience you’re probably going to have to pass by Apple’s store.
