For instance, normally sighted people or even people with "normal" nearsightedness, farsightedness, or presbyopia benefit from adequate contrast.
Text "size" is another thing because people should be able to control it, particularly given the wide range of different devices that are out there.
I think what you just indirectly pointed out is that software is largely written by young, ignorant people who don't appreciate that everyone will get to experience presbyopia, and it happens sooner than you think. Maybe we should require product owners to be at least 40 years old ;-).
The irony is you have to work to get this to not work. HTML by default will render just fine. Developers just can't resist customizing it so it doesn't work.
My web sites use plain HTML as much as possible. They're derided for being "Web 1.0", but they work, load in a flash, can be resized by the user, are legible, etc.
Even Apple went with pages that were light grey text on white with a tiny font. My eyeballs would just hurt trying to read it. This was a few years ago, maybe they fixed it, but I grew to avoid reading Apple's online docs because it was literally painful.
Makes me think of the oxo good grips kitchen utensils. They were designed designed for people with poor dexterity and as a result have become easier for everyone, this has made them extent l extremely popular
Depends on the individual case — I’ve seen entire projects get scrapped because it wouldn’t be feasible to make an “accessible” version. Some things just aren’t work for everyone and that’s okay.
What is SO effing hard about drawing within the screen on web?! I can't tell you the number of times I've seen this issue. Just the other day I saw reddit's sign up form is totally broken on iOS, you have to swap between landscape/portrait multiple times and hope whatever garbage layout engine it uses redraws the button inside the screen.
As soon as you put real data into a website, especially if the website is a CMS that you've handed-off to a _non-technical_ client, it's going to overflow every pretty, grid-based box.
I expect it's fairly rare for the employer of a web designer to give a shit what the site looks like on a phone, which means the designers don't give a shit either.
But, as you've noticed, with more complex UI (especially modals and toolbars fixed to the screen) it becomes more important that things are built to fit horizontally and vertically. It's not necessarily hard but it does take more thought to work out how things will shrink, grow, scroll, etc.
It’s because the web’s layout primitives don’t compose well. There’s no easy way to say “this is a full-width container and nothing inside it can go off screen.” As an obvious example, any descendant of that container can use fixed positioning and do whatever it wants. But there are subtler examples that are easier to fall victim to. The way to fix this is to built your own higher-level layout primitives and have conventions or tooling to enforce that you compose them only in approved ways.
Which makes the table content inaccessible. It _is_ an accessibility issue.
Here's the definition I prefer, that does not focus on "disabilities" (which many people equate "accessibility" with):
> When we say a site is accessible, we mean that the site's content is available, and its functionality can be operated, by literally anyone.
But it frustrates me to no end that a browser is no longer a "User" Agent and is now just seen as a... virtual machine for apps?
One tip: Don't try to install too many general filtering extensions (uMatrix, Privacy Badger, uBlock Origin, etc...) at the same time because they will end up fighting.
Even better, one chrome issue/bug report, had google devs on the tracker explaining how it's fine, and how each website should just fix things.
They were blathering on about how websites are broken, should be fixed, utter absurd.
The sheer, unmitigated gall, of saying "screw users" is beyond comprehension.
Google: unless you want another series of Professor Farnsworth posters around HQ, fix it!
For example if you're making a WebGL app, or if you're making a map zooming widget that needs to progressively load more local detail as the user zooms in on an area.
If you don't disable zoom, the OS and your zoom logic will be fighting over the pinch gesture.
iOS Firefox does have pinch-to-zoom, but having to use it every time I navigate to a page is tiresome.
iOS Firefox is a small niche choice and not the same codebase as desktop Firefox because Apple requires that you use their rendering engine. So I'm not sure it makes sense for Mozilla to dedicate the kind of resources to it to implement all the features I might want, and I don't have a lot of gripes. But as a datapoint in this thread, zoom is really important to me, and I miss it when it's not available. I shake my head every time I visit Google search results on my iPad because the text is so tiny.
As a user, you can force allow zooming:
In Firefox find the settings, select “Accessibility” and activate “Zoom on all website”
In Chrome find the settings, select “Accessibility” and check “Force enable zoom”
Without zoom disabled 5 people putting their fingers on a screen looks a lot like a pinch gesture. Disabling the default event handlers only works some of the time.
This is a common problem with the web, we can't have nice things because people use them poorly.
I've never been able to zoom on mobile apps.
Anyone can find the secret override setting if they're motivated, but that's not a solution to the problem.
I know web developers don't care, but they're still the ones that can actually solve the problem. It's possible that like many other abused web features, Google will eventually change the setting for this feature from "override website zoom settings" to "respect website preferences for zooming" with "off" as a default.
The entire article barely scratches 250 words. I don't think anything can be considered 'buried' in what is basically a medium-sized paragraph.
In lieu of that, maybe consider having an "accessibility options" cta on first interaction.
For not disabling zoom the header does not even help because developers blindly copy pasting the <meta name="viewport" ...> line so that broken by default mobile browsers won't fuck up their responsive design are not going to handle that header.
Like many accessibility issues, zoom is not something that only benefits a subset of the popultaion. The solution is to no disable zoom for anyone except the 0.01% of pages (only very specific web apps really) where zoom does not make any sense AND interferes with some other behavior (e.g. multi touch).
Then pretty much everyone copied from these guides, and here we are. I remember I had used HTML5 skeleton templates for a while before I learned that the "maximum-scale=1, user-scalable=no" they came with is not a good idea.
I get why it's there, if you're building a PWA that is supposed to mimick a mobile app, you have to enable that to override some annoying mobile browser behaviors like zooming on an input.
The problem is that the above scenario is about the only time you would want to set the viewport in that way. Yet because the line gets included in boilerplates to make it easier to make PWA's, it ends up in a ton of stuff that definitely is not a PWA and should not have that.
<meta name="viewport" content="width=device-width, initial-scale=1">
Do you have links to examples of the major templates?
Yep, I've seen some people disable zoom in their webpages specifically to prevent Safari from auto-zooming all over the place as the user moves from this to that input. It gets really annoying if you have anything but the simplest form. And what webpage doesn't have at least one form on it, even just the search box?
I fully agree with OP that disabling zoom is wrong. I also think it's wrong for browsers to mess with the zoom level without the user's instruction.
Almost every weird workaround we still have today in webdev was originally written to compensate for inconsistent browser implementation of some standard. In the past, IE was the one that always did something weird. Now it's Safari. Until browsers stop trying to pretend that they know better than both the developer and the user, somebody somewhere will keep writing these workarounds that then stick around in boilerplates and tutorials for years.
Copy-pasting a template and just not being aware of accessibility and functionality requirements is most likely explanation here. Or devs being given 4k UHD monitors and never looking at their work on a small laptop.
One of the worst offenses for me is when the website dynamically resizes everything so that zoom “works” but a split second later everything goes back the way it was. I would also like browsers to have a quick/accessible workaround for that behavior too.
Would these people want to be able to zoom in native apps as well? Or is there a reason it's fine in native apps but not on the web?
There are very legitimate and valid reasons to disable page zooming: it can break layout, it can be triggered accidentally causing usability issues because content then overflows, and it is a poor solution to increase text readability as you often then have to scroll to read a full line of text.
Not allowing to do it is not the solution.
To use your book analogy - the web is no longer a bunch of books on a shelf, it's an AR device that shoots lasers into your eye. The net effect may be the same in many use-cases, but not necessarily, and malicious actors now have far more flexibility and power because we've all become accustomed to running random code we download off the internet with a single click.
I am, obviously, not a huge fan of this shift and think a large majority of sites could operate perfectly well under the "markup document" model without needing actual code-execution privileges, or more than a minimal set of code-execution privileges for those actual simple document-related use-cases. Go back to being mostly just a book, basically.
Almost all of the use-cases that javascript gets used for in a document context could really be replaced by navigation between sets of linked, static pages (perhaps embedded where needed) - boy, what an idea. If you delivered a site "as a gzip" then there should barely be any noticeable size difference from that anyway, especially compared to downloading mountains of JS embeds.
The amount of things that truly, truly need interactivity is pretty low - things like chat clients come to mind, but does your bank need to be running javascript on your end? Probably not.
How much choice do you have in the typesetting of any book you've ever bought?
You could still use a magnifying glass on your monitor, as some Russian General was photographed doing recently... .
.
Obviously I think the choice to disable zoom, etc, is daft, but ultimately that is the creator's right to call, advisedly or otherwise.
For whatever reason, my Firefox was already ignoring these artificial restrictions intended by the creators, and I was able to zoom as normal. Does that affect the creators of these websites in any way whatsoever?
Disabling or otherwise inhibiting user behavior is not a creator's right.
Problem: Very tiny.
Solution: Scale to viewport in integer increments.
Result: https://anaminus.github.io/
This disables zoom. In fact, it actively fights the zoom level to always fit the viewport. Have I committed a great sin?
To be honest, It makes me recall painful WAP[1] browsing on an old Nokia phone.
---
[1] https://en.wikipedia.org/wiki/Wireless_Application_Protocol
Yes. Scaling to the screen size is fine, overriding the users's attempt at zooming in is not.
In the same vein, if you use images on your responsive website, consider linking to the full size version.
95% of the time this is a complete non-issue for me, since my monitor (for home and work) is a 50" 4k TV and I just abuse the zoom-in feature in Firefox and I'm good, but when the site actively disables zooming, it feels like an almost directed attack towards people like me: Tombert need not read this website.
Can you tell me what you think of the font sizes? Is it readable enough? Is there room for improvement?
I would buy this if they downscaled everything before storing it; that would actually make sense. But it seems like they just want to "curate" your "experience"?
In Firefox, Shift-right always presents the browser context menu. It's one of the few distinguishing features they haven't screwed up yet.
I really want an internet where servers provide structured content, but where I control my user experience.
Because the most popular web browsers ARE created by some of the largest server owners (i.e. Google).
To address this, make sure your site works with simple browsers, like Links and lynx.
Because server owners have the freedom to publish whatever they like (within the bounds of the law) and design their sites however they wish. An internet on which servers are only allowed to provide "structured content" would be significantly less free and open.
You may be interested in the Gemini Protocol[0], on which sites are built according to that general principle.
1. There must be a meta tag of type viewport 2. The viewport must be defined to have width=device-width 3. The content must be at a scale of 1
Edit: Having just tried the sites in the Safari ... they zoom in just fine with that set, so .. Im a bit confused
* Some number of people are sensitive to latency
* Some people are unable to read my website
You're gambling that there are more people who would walk away due to latency, than there are who would walk away due to being unable to interact with your site at all.
Personally I suspect that to be a poor tradeoff.
Heck, back when I bought my mother her first iPad, this was the whole reason. She was getting eye surgery and wouldn't be able to see well, and would be stuck face-down for a couple weeks. I figured an iPad would be good, because she could pinch-zoom so the letters were two inches tall if necessary. It was a roaring success, but zoom=false defeats that.
Mobile Safari does ignore this setting. You have to go out of your way with stopping touch events on mobile safari to prevent zooming.
Sometimes this is problematic for sites using "small" (< 16px) fonts for input fields because that will cause mobile safari to zoom in to show the input field whether you want it to or not.
Is there a good way to get lightning-fast response times to tap events without disabling zoom in 2022?
a, button, .etc { touch-action: manipulation; }Latency matters a lot and everyone taps, not everyone zooms.
document.querySelectorAll('meta[name="viewport"][content*="user-scalable=no"]').forEach(tag => tag.remove())
While it's not ideal to have to use a snippet or an extension, you could fix this for yourself (or individual web users) in a way that 'fixed' literally every site on the internet for that person. So I wonder if that's a viable route to a solution!
Reading the article I was surprised to hear of the issue and could not replicate. I am capable of finding the relevant setting in Android I'm sure, but many older and tech illiterate people in my life (who are more likely to need zoom) I think would struggle.
Had a chuckle.
Me: "ABSOLUTLEY!"
Note: I can't test this right now because I don't have any sites that do this particular bad thing
I would never pull someone down to sit down to my eye level if in a wheelchair, never.
I would never pull someone closer to me so I can read lips better.
And certainly I would never remotely pull them to something that I want, as in this case, digital remote camera.
However, it is a courtesy to ask them to adjust for your sake. And only a courtesy.
This OP dude needs a proverbial slap across the face.
Just ask, curtly and nicely.
Would you mind explaining what you mean by asking others to adjust for your sake in the context of mobile web accessibility? I'm having trouble connecting it to the content of the article. I'm not the writer, but would love to better understand your point of view here.
I had thought it was about allowing other people to play with the gimbal and focus and that kind of “zoom” … of a remote camera variety. My bad.
Still, asking others to adjust is a nice thing. Demanding to do things on their end, not so much.
In all cases, I can zoom all elements (text, images, the works) just fine, up to 500%.
Firefox 100 on Windows. Is this just another one of those "Safari on IOS is broken, so the Web is broken" things, or is there more to it?
Browser scrolling works fine. You don't need to try to re-implement smooth scrolling, it never works and makes my scrolling bounce around like mad.
One website override my scrolling speed entirely. I like it so that 1 click = 2 lines of scrolling. That site changed it to that 1 click = 1/2 line, but for some reason the web dev thought they knew better than my preferences.
As per theories in this thread why this meta tag is so popular. I know a few UX designers who explicitly asked the web developers (also me) to disable zoom so that there precious design could not be broken by users. I simply refuse to do so.
Doing God's work.
USB Power Delivery Rev. 1.0 (V. 1.0) 2012-07-05 100 W (20 V, 5 A) USB Power Delivery Rev. 1.0 (V. 1.3) 2014-03-11 100 W (20 V, 5 A) USB Power Delivery Rev. 2.0 (V. 1.0) 2014-08-11 100 W (20 V, 5 A) USB Power Delivery Rev. 2.0 (V. 1.1) 2015-05-07 100 W (20 V, 5 A) USB Power Delivery Rev. 2.0 (V. 1.2) 2016-03-25 100 W (20 V, 5 A) USB Power Delivery Rev. 2.0 (V. 1.3) 2017-01-12 100 W (20 V, 5 A) USB Power Delivery Rev. 3.0 (V. 1.1) 2017-01-12 100 W (20 V, 5 A) USB Power Delivery Rev. 3.0 (V. 1.2) 2018-06-21 100 W (20 V, 5 A) USB Power Delivery Rev. 3.0 (V. 2.0) 2019-08-29 100 W (20 V, 5 A) USB Power Delivery Rev. 3.1 (V. 1.0) 2021-05-24 240 W (48 V, 5 A) USB Power Delivery Rev. 3.1 (V. 1.1) 2021-07-06 240 W (48 V, 5 A) USB Power Delivery Rev. 3.1 (V. 1.2) 2021-10-26 240 W (48 V, 5 A)
Some corporate training long ago had "I can't see videos" and "I can't hear things" toggles that were not mutually exclusive.
If you set it to "Hellen Keller mode", you could just read the training at your own pace. It was glorious.
Thank you, accessiblity advocates!
On an unrelated note, why is HN text so small? I understand if it were a hunting site, where you're naturally supposed to use a scope, but for an IT forum that's unusual, given half of us wear glasses!
The bigger problem is when posts are printed with a 50% grey font on top of a 25% grey background. Like it's such an obvious usability issue that I have no idea why the developer who set it up didn't have a little laugh at their own expense for the mistake the first time they saw it and then immediately went back and fixed it. Why it it still like this in 2022?
I posted this 11 years ago: https://tech.bluesmoon.info/2011/01/device-width-and-how-not...
It's not a trend, it's been around as long as it's been possible. Site owners dislike letting their users have control.
Understandably, back in the days (and maybe still the case now) the default behavior for web browsers on mobile were to load the same desktop site but zoomed out -- it wasn't a great experience, so devs looked for a way to avoid it.
I think it's fine to build a mobile responsive site with "width=device-width, initial-scale=1" (that gives you a default view that is built for mobile) but there is little reasons to have "user-scalable=no".
here's a very simple SPA like page
https://decisive-spiral-blue.glitch.me
It's just an upper and lower vertical flexbox. fixed size toolbar on top, the rest is a textarea. Click in the text area. type "A"<enter>, "B"<enter>, "C"<enter> etc... and watch the cursor disappear below the virtual keyboard. WTF!
I've seen other issues where the browser auto-zooms when clicking in a textarea and while they are trying to be helpful they actually make the site practically unusable. Both because info the user needed is now offscreen and because finishing the input doesn't auto-unzoom so the user is left having to manually adjust to see the page again.
And then, there are random rules (like if the text is larger than 16px it might not auto-zoom). Might. AFAIK there is no spec that says "hey, don't auto-zoom" so your left with random hacks to try to make the site usable. (of course if the user wants to zoom that's fine)
The point is, the mobile browsing experience sucks by default and devs do the best they can to try to work around how much it sucks. They choose wrong but they wouldn't be reaching for solutions if the default experience wasn't so bad in the first place.
I'd personally like to be able to opt in to a mode where when the virtual keyboard appears the browser's size changes and I can fix my layout for the new available size via CSS media queries.
This is somewhat ironic because, if memory serves, the original reason people started adding this to their HTML was because of some dubious scaling behaviour on iOS Safari (I think, if you didn't disable zooming, Safari responded to rotation by zooming the page to fill the new width, rather than laying out the page again).
In the end, it's nobody's business but their own whether they zoom or not, so why would I disable it?
We re-enabled zoom.
I agree I have fat fingers but 8 our of 10 times, I end up opening up the ad. :(
Absolutely everything that isn't default browser zoom is broken. It's the wrong speed, or cuts at the wrong place. Basically it's always surprising in an annoying way.
Then there's the "frustratingly slow scroll to navigate". E.g. go to https://cloud.google.com/compute/all-pricing and click on the last nav on the left.
AND of course it doesn't support zoom because almost no native apps support zoom. (Why do they get a pass?)
I guess the issue now is it has become part of the cargo cult with people including these meta tags in their base templates without knowing what it does and failing to implement a suitable layout for all mobile device screen sizes and DPIs.
https://github.com/h5bp/html5-boilerplate/blob/main/src/inde...
After installing this, I’ve had a much better experience with the web on iPhone and iPad. And I less often have to switch to a laptop to get around some user-hostile site.
[0] https://apps.apple.com/us/app/stopthemadness-mobile/id158308...
I taught him the nearly universal ctrl mouse wheel hotkey combo so that he can scale things, and then proceeded to adjust about a half dozen different areas in the various applications he uses for managing jobs and ordering parts.
I used to get into terrible arguments with a business partner about every web page I made. He'd say "the text is too big" or "the text is too small" and I'd point out that you shouldn't ever complain about that because you can use Ctrl + and Ctrl -.
I am thinking about UIs that work across desktop and mobile and would love to make peace with the scaling issues once and for all.
But if I remember correctly the correct way to prevent this was to set the font-size of the input field to at least 16px.
EDIT: More infos: https://stackoverflow.com/questions/2989263/disable-auto-zoo...
I disable it because there are bugs on mobile browsers where inputs can automatically hijack zoom and the default behavior really messes up the workflow. But yea you have to reimplement or replace it with a flow for your use case.
It's just one click to remove it for form-based websites (a few steps to whitelist if you're going to use that web form a lot), but the readability for the vast majority of websites is drastically improved.
One of my other pet peeves is web sites that shrink the default text size. Why??? I set my browser and OS to a text size that is useable for me, please defer to me, your user.
Thanks muchly.
>In Firefox find the settings, select “Accessibility” and activate “Zoom on all website” >In Chrome find the settings, select “Accessibility” and check “Force enable zoom”
OMFG, thank you.
Then I realized on iOS since about 6 years ago disabling zoom via meta tags takes no effect and you can still zoom; please, stop being lazy and not do your research before complaining.
Finally I realize on android and desktop this is still an issue but maybe those sites have valid reasons like they want the page look exactly as they intended for aesthetics or even in some cases functional reasons; please, stop assuming developers are just lazy and obviously want to annoy people with disabilities.
With no scrollbars it's hard to tell if something is zoomed in or not and you might be missing parts of the UI without noticing. Native apps don't zoom and neither should mobile sites pretending to be apps. Build accessibility into the UI.
I'm otherwise with the article, and also for old IT updating their terms.
There's another angle here, which is that being pro-browser zoom is anti-web application, and implicitly preferring native applications.
This is actually playing into Apple's hands of enforcing their walled garden and the Apple tax. They are neutering web apps intentionally.