Great article! As a visually impaired person I started noticing this last year in some sites but the number of sites that do this has been increasing exponentially of late and it’s REALLY problematic for me.
Sure, you can use the accessibility full screen zoom feature to get around this - kind of - but now you’re struggling wth trying to zoom in to the part of the content you want to read without rendering the touch UI unusable - it’s a nightmare.
I particularly love the fact that the problematic tags are identified specifically so web devs know what to watch out for.
Why, exactly? Sure, it’s tricky to implement them correctly, especially taking screen reader accessibility into account, but the gotchas are now well-documented, so it’s not that bad.
Just ask your users of your interface whether they really want a modal dialog or are they instantly looking for the way to dismiss the damn thing and get it out of their face?
And even if it’s useful… how often do they curse it because to fill it in they need info that is now suddenly inaccessible to them!?
I know this isn’t the same thing but my favorite Mac feature for years is Zoom.
SysPrefs -> Accessibility -> Zoom
✔️Use scroll gesture with modifier keys to zoom: ^ Control
It works in every app. Hold control, use the mousewheel. Great for pixel-peeping or bringing attention to something when pairing in person. I wish it somehow worked over screenshare.
At some point I started to conduct webinars and online trainings, and zoom over screen sharing became absolutely essential. I’m glad most programs I show other people do have their own zoom that does work over screen sharing, including Wireshark.
No. Just because there’s an option to enable it, that doesn’t mean disabling it should be encouraged. Not everyone knows about the option, for one thing.
You’ve identified a web browser UI design problem, which can be solved by the probably-less-than-double-digits number of teams developing popular web browsers, rather than by asking tens of millions of web content creators to change their behavior.
Perhaps browser makers can treat it like a potentially undesirable thing. Similar to “(site) wants to know your location. Allow/Block” or “(site) tried to open a pop up. [Open it]”
So: “(site) is trying to disable zooming. [Agree to Disable] [Never agree]” or similar.
I think the better question is why can you disable this in the first place. It shouldn’t be possible to disable accessibility features, as website authors have time and time again proven to make the wrong decisions when given such capabilities.
I mean, what’s an accessibility feature? Everything, roughly, is an accessibility feature for someone. CSS lets you set a font for your document. People with dyslexia may prefer to use a system font that is set as Dyslexie. Should it not be ok to provide a stylesheet that will override system preferences (unless the proper settings are chosen on the client)?
Slippery slope fallacies aren’t really productive. There’s a pretty clear definition of the usual accessibility features, such as being able to zoom in or meta data to aid screen readers. Developers should only be able to aid such features, not outright disable them.
I think this is a misunderstanding of what “accessibility” means. It’s not about making things usable for a specific set of abilities and disabilities. It’s about making things usable for ALL users. Color, font, size, audio or visual modality, language, whatever. It’s all accessibility.
“Based on some quick tests by me and friendly people on Twitter, Safari seems to ignore maximum-scale=1 and user-scalable=no, which is great”
I think what the author is asking for is already accomplished on Safari. If it isn’t, then the author has not made a clear ask to the millions of people they are speaking to.
I am a web dev dilettante / newbie, so I will take your word for it. I just know that more and more web pages make browsing them with my crazy pants busted eyes are becoming nearly impossible to view on mobile, or wildly difficult enough so as to be equivalent to impossible in any case :)
And that is a huge accessibility problem. This zoom setting is a huge accessibility problem.
My point is that the solution to this accessibility problem (and almost all accessibility problems) is to make the browser ignore this setting, not to ask tens of millions of fallible humans to update literally trillions of web pages.
As another partially blind person, I fully agree with you. Expecting millions of developers and designers to be fully responsible for accessibility is just unrealistic; the platforms and development tools should be doing more to automatically take care of this. Maybe if the web wasn’t such a “wild west” environment where lots of developers roll their own implementations of things that should be standardized, then this wouldn’t be such a problem.
Agreed. Front end development is only 50% coding. The rest is design, encompassing UX, encompassing human factors, encompassing accessibility. You can’t apply an “I’m just a programmer” or “works on my machine” mindset when your code is running on someone else’s computer.
Developers and designers do have to be responsible for accessibility. I’m not suggesting that we aren’t.
But very often, the accessibility ask is either “Hey, Millions of people, don’t do this” or “Hey, three people, let me ignore it when millions of people do this”. And you’re much better off lobbying the three people that control the web browsers to either always, or via setting, ignore the problem.
Great article! As a visually impaired person I started noticing this last year in some sites but the number of sites that do this has been increasing exponentially of late and it’s REALLY problematic for me.
Sure, you can use the accessibility full screen zoom feature to get around this - kind of - but now you’re struggling wth trying to zoom in to the part of the content you want to read without rendering the touch UI unusable - it’s a nightmare.
I particularly love the fact that the problematic tags are identified specifically so web devs know what to watch out for.
Thanks!
Now if I can just find a way to slap all and everyone who designs modal dialogs…..
Why, exactly? Sure, it’s tricky to implement them correctly, especially taking screen reader accessibility into account, but the gotchas are now well-documented, so it’s not that bad.
Here is a fairly reasonable reply…. https://www.nngroup.com/articles/modal-nonmodal-dialog/
…but I’d be far more assertive than that.
Just ask your users of your interface whether they really want a modal dialog or are they instantly looking for the way to dismiss the damn thing and get it out of their face?
And even if it’s useful… how often do they curse it because to fill it in they need info that is now suddenly inaccessible to them!?
I know this isn’t the same thing but my favorite Mac feature for years is Zoom.
It works in every app. Hold control, use the mousewheel. Great for pixel-peeping or bringing attention to something when pairing in person. I wish it somehow worked over screenshare.
At some point I started to conduct webinars and online trainings, and zoom over screen sharing became absolutely essential. I’m glad most programs I show other people do have their own zoom that does work over screen sharing, including Wireshark.
Don’t you disable zoom to prevent mobile browsers from auto-zooming into field elements?
Whatever the excuse, it’s an impediment to accessibility on the web.
You don’t need to do that though. Mobile browsers zoom in to field elements to make the effective font size of the input field big enough. For example, iOS won’t zoom in if you set the form font size to 16px or larger.
“ As a user, you can force allow zooming”
Isn’t this problem solved, then?
No. Just because there’s an option to enable it, that doesn’t mean disabling it should be encouraged. Not everyone knows about the option, for one thing.
You’ve identified a web browser UI design problem, which can be solved by the probably-less-than-double-digits number of teams developing popular web browsers, rather than by asking tens of millions of web content creators to change their behavior.
Perhaps browser makers can treat it like a potentially undesirable thing. Similar to “(site) wants to know your location. Allow/Block” or “(site) tried to open a pop up. [Open it]”
So: “(site) is trying to disable zooming. [Agree to Disable] [Never agree]” or similar.
I think the better question is why can you disable this in the first place. It shouldn’t be possible to disable accessibility features, as website authors have time and time again proven to make the wrong decisions when given such capabilities.
I mean, what’s an accessibility feature? Everything, roughly, is an accessibility feature for someone. CSS lets you set a font for your document. People with dyslexia may prefer to use a system font that is set as Dyslexie. Should it not be ok to provide a stylesheet that will override system preferences (unless the proper settings are chosen on the client)?
Slippery slope fallacies aren’t really productive. There’s a pretty clear definition of the usual accessibility features, such as being able to zoom in or meta data to aid screen readers. Developers should only be able to aid such features, not outright disable them.
I think this is a misunderstanding of what “accessibility” means. It’s not about making things usable for a specific set of abilities and disabilities. It’s about making things usable for ALL users. Color, font, size, audio or visual modality, language, whatever. It’s all accessibility.
https://xkcd.com/1172/
(That said, I don’t understand why browsers let sites disable zoom at all.)
Hi. Partially blind user here - I, for one, can’t figure out how to do this in Safari on IOS.
“Based on some quick tests by me and friendly people on Twitter, Safari seems to ignore maximum-scale=1 and user-scalable=no, which is great”
I think what the author is asking for is already accomplished on Safari. If it isn’t, then the author has not made a clear ask to the millions of people they are speaking to.
I am a web dev dilettante / newbie, so I will take your word for it. I just know that more and more web pages make browsing them with my crazy pants busted eyes are becoming nearly impossible to view on mobile, or wildly difficult enough so as to be equivalent to impossible in any case :)
And that is a huge accessibility problem. This zoom setting is a huge accessibility problem.
My point is that the solution to this accessibility problem (and almost all accessibility problems) is to make the browser ignore this setting, not to ask tens of millions of fallible humans to update literally trillions of web pages.
As another partially blind person, I fully agree with you. Expecting millions of developers and designers to be fully responsible for accessibility is just unrealistic; the platforms and development tools should be doing more to automatically take care of this. Maybe if the web wasn’t such a “wild west” environment where lots of developers roll their own implementations of things that should be standardized, then this wouldn’t be such a problem.
Agreed. Front end development is only 50% coding. The rest is design, encompassing UX, encompassing human factors, encompassing accessibility. You can’t apply an “I’m just a programmer” or “works on my machine” mindset when your code is running on someone else’s computer.
Developers and designers do have to be responsible for accessibility. I’m not suggesting that we aren’t.
But very often, the accessibility ask is either “Hey, Millions of people, don’t do this” or “Hey, three people, let me ignore it when millions of people do this”. And you’re much better off lobbying the three people that control the web browsers to either always, or via setting, ignore the problem.