It’s not just accessibility. I’ve last track of the number of times I’ve seen a mobile website with a table that extends past the right side of the viewport and zoom disabled. You can’t scroll, and you can’t zoom, so you can’t read the table.
What mobile browser? On iOS Safari, all the example websites mentioned by the OP allowed me to zoom. I guess Safari doesn’t allow zoom to be disabled by websites? Maybe all browsers should work this way?
I use iOS Firefox, because I love desktop Firefox and I have Firefo set up with account sync across all my devices. But there's a feature of desktop Firefox which isn't available on the iOS version: remember zoom setting for a domain.
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.
> Unfortunately people see accessibility as a burden that a small minority puts on the rest of us, but really it is something that benefits everyone
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.
A flip side is that any bureaucratic mandate is a "free pass" to reject anything that's hard to find another justification for rejecting... In terms of institutional requirements it is a gift as much as a burden.
Accessibility is like performance, and security, and portability: You don't create the product, and then "spoon a little security in" right before shipping. You build it from the start as secure, with security as a first-class goal, and gate features on whether or not they are secure. Same for accessibility. You don't try to take an existing inaccessible project and wave a magic accessibility wand around it late in the game. It should be a first class design principle. If you are hiring a UI designer or interaction designer, pay attention to how seriously they take accessibility in their designs. If they're good, their designs are accessible by default, because as a Cousin Comment said, accessibility is not just "usable by the disabled" it's "usable by everyone".
I would argue that "usable by everyone" is an unreasonable goal which tends to result in catering to the lowest common denominator.
For example, take buildings -- they typically have stairways, often as a fire escape route. However, stairways are not usable by everyone. Should we ensure that buildings have no stairways at all because there exist some people who can't use them?
To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
> I would argue that "usable by everyone" is an unreasonable goal which tends to result in catering to the lowest common denominator.
Extremes are always unreasonable, the goal should be to support everyone that you reasonably can. Nobody is telling anyone to make their tools work for the blind deaf and mute quadruple amputee - but that does not mean that it should be acceptable to completely ignore the variations in capability of people wanting to use your product.
> To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Blindly following guidelines leads to problems, yes. But you can achieve the goal of making the spreadsheed usable for someone who has trouble with small click targets: For a desktop program you should consider adding efficient and discoverable keyboard navigation so that noone needs to click anything. This will help power users as well as those with fine motion problems. In general, a program, unlike a physical staircase, is also something that can dynamically adapt to the needs of the user. For example you could make your spreadsheet zoomable. For a desktop program it could be OK to rely on third-party (or platform-provided) zoom utilities - just don't write your program in a way that makes those impossible to use.
For buildings such dynamic adaption is not as feasible and so we make compromises that require some people to rely on others for help in incommon situations. But even there we should do what we resonably can - for in many parts of the world public buildings do have wheelchair-accessible entrances these days, even if the emergency exit is a stair.
When building new commercial buildings (in the US,) accessibility is a non-negotiable requirement. And for good reason. If an accessible version wasn’t feasible in software, then it’s likely the project should have been scrapped just as a commercial building would never be built without accessibility as part of the core design. There shouldn’t be an “accessible version,” accessibility should be the default. Accessibility should be integral to everything built — especially software.
A staircase isn't accessible, but still allowed. The accessibility is in an alternate implementation provided for those who need it.
A phone call is an accessible alternative to a website. US law says that the phone call must be offered at the same price as the website, for those who need it.
> A staircase isn't accessible, but still allowed. The accessibility is in an alternate implementation provided for those who need it.
Exactly this -- some things just aren't going to be for everyone. If we truly wanted to make buildings "accessible", all stairways, and even printed signage would have to be banned, as there exists someone who cannot benefit from it.
No, accessibility does not mean that everyone is knocked down to the same level. The staircase is not the feature, getting to different floors is - so it is acceptable to have a staircase for those that can and want to use it and an elevator for those that can't. Visual signage is acceptable as long as their a also navigation aids for the blind. And yes, whe do require these for many places.
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 ;-).
I don't think this is reality. There might be some truth to it, but in my opinion the real problem is the platform itself. I'm going to blame it on browsers and web standards.
The web was not designed with accessibility as default. Instead it is a significant amount of work to make things accessible. Every project incurs huge cost in order to achieve it. I truly believe from an accessibility standpoint the web is simply broken. So sure, blame it on young programmers. But that's a poor excuse for where we are at today in my humble opinion.
> The web was not designed with accessibility as default. Instead it is a significant amount of work to make things accessible. Every project incurs huge cost in order to achieve it.
This has got to be satire right? HTML is accessible by default, it's your horrible JS SPA frameworks that break thid. See [0]
For my day job I put a lot of effort into making an SPA accessible but it is absolutely important to the business because our customers demand it.
I haven't perceived maintaining accessibility to be a big burden in the long term.
Interestingly the accessibility project forced me to raise my game on CSS/HTML, graphic design, etc. and probably had a bigger impact on my side projects than it did on my work.
I put in this work as well. It's not about "burden" but cost. Clearly there is a cost here (your time). I don't mind spending the time, but that doesn't mean it costs nothing.
Now multiply this times every web app in existence and the cost is quite large. A lot of this could be avoided with a better platform.
It seems to me the web is accessible by default. Write a plain old HTML page and everybody should be able to read it (assuming they have a computer to open it or a printed version).
People go out of their ways to mess this up by using fancy colors, fancy web fonts, messed up JS (frameworks), non standard components because it's cooler, disabling outlines, and so on.
Do you have examples where the Web is not accessible by default, apart from the by default unlimited line width which is easily fixable with one line of CSS?
Sure you need to use the right markup for the right things (and, no, <div> is usually not the right element for building a button or writing a paragraph, there are dedicated tags for those) but I can't see a way to avoid this.
Yeah I agree. A plain old web page is rarely a problem. Ctrl-plus-plus-plus-plus however many times I need it, and I'm good. It's always 'modern' web pages that insist on fighting me.
We need to admit that "modern" web pages are a thing. If we keep ignoring most of the web because "they are doing it wrong" then accessibility will never be solved.
It seems to me you can build quite complex things that will be accessible by default with the web platform.
IF don't fight it and if you respect semantics and progressive enhancement / beautiful degradation. You get so much by default: legible colors and font sizes, tabbed page navigation, alt texts, clickable labels, zoomable interface...
When you embrace the platform and its spirit, you get accessible results quite easily. But not a lot of people seem to embrace it. Many people seem to think "what to do for what I want to see" instead of "what to do for what I want to mean", and you lose if you do this. You need to get your meaning right and then decorate it carefully. You should not paint first. But that's probably not a web-specific issue.
What's more, building accessible things may make you gain time, by having a robust basis. It's not always a cost.
I'm just trying to step back and look at things objectively. Instead of saying "arg developers are just stupid" I'm trying to analyze why these mistakes are made so frequently (even at big corporations with lots of funding).
There are native UI frameworks where this is not nearly as big of an issue.
Too much freedom perhaps? Should you even be able to give a div an onclick handler?
What about inputs? Why do developers have to make custom inputs because the core ones are severely lacking? That's where accessibility goes wrong. Because core functionality is terrible and needs to be augmented with richer functionality (but terrible from an accessibility perspective).
There is something fundamental about this platform that does not naturally encourage good behavior. All you have to do is look at the evidence.
As an dumb little example, it's not even obvious that making a div a button is bad unless you know that it is. The platform doesn't guide you at all. It has an onClick handler the same as a button. Little attempt is made to differentiate the two from an API perspective.
I could give countless other examples, but I think I have demonstrated what I am getting at.
> Because core functionality is terrible and needs to be augmented with richer functionality
Well, yes, I agree with both of these points. I think I get your point in the end, and your examples are convincing.
I'd say the web platform is accessible by default but this is easy to break inadvertently and maybe not the ideal platform to build applications because despite its strong accessibility features, it's lacking for what we want to do with it today.
HTML being a format to write documents first and not applications probably does not help neither.
Yep. Just write in HTML, and the browser will render everything for you. It's almost as if the browser treated HTML as if, I dunno, it was some kind of markup language, you know, with hypertext, and stuff, and could automatically render it. /s
I remember back in the late 90's, and we decided to create a static website for internal use on a project. Everything was supposed to be quick and simple. We weren't after anything fancy, just something that worked.
We used Microsoft's whatever-it-was-called at the time for writing webpages. It turned out that the html produced required some special Microsoft fonts for the web.
Hells bells. The whole point of the Internet is interoperability. But no. We can't have that, can we Microsoft? We need special fonts. Interoperability? Screw that!
About the same time Java on webpages was a thing. We never used them, but I had seen sites that had. So the site had to download some Java craplet, whatever it was called, you had to enable it, plus of course you had to have Java.
Even when the web was still young, people had some really dumb ideas.
Then there was a fad that sites had to have some kind of animated intro on the front page. I remember seeing one for my bank and a recruitment site. No doubt that cost them a pretty penny.
Those early internet fads have died out, but today's websites are no better.
Why does my browser have to download fonts? I already have fonts! Just use one of those!
Anyway, that's me done. I'm off to shout at some clouds. Not the virtual clouds, actual real ones.
>We used Microsoft's whatever-it-was-called at the time for writing webpages.
Frontpage, I'm going to bet. :)
I was an early user of Frontpage, shortly after Vermeer released it. A few months later, it was bought by Microsoft. Looks like Frontpage was absorbed and discontinued (https://en.wikipedia.org/wiki/Microsoft_FrontPage).
It was handy but I was just messing around with a very simple personal website and most of the time I'd just use Notepad or something like that.
>About the same time Java on webpages was a thing.
Guilty... I wrote a simple java applet to draw a polar plot of antenna radiation patterns. Later I added a calculator applet - after all, how handy would a simple calculator only a website away be?? I should have gone with the trends and converted both to javascript... but I did not.
>Then there was a fad that sites had to have some kind of animated intro on the front page
I remember the omni-present "site under construction" animated gif. As in, > 50% of websites had them somewhere.
For years my optometrist told me I would eventually get presbyopia and then finally I reached the point where I need two pairs of glasses.
It is on my mind because one of my hobbies is a cyberphysical artsystem that has a small book of design rules and presbyopia is what sets the limits on feature size. (You can't just tell people "hold the card closer")
and is made of 8″x8″ cards. That's the first constellation I made, most of the output is either stand alone 4″x6″ cards or constellations. I'm working now on my third constellation from images published by Ukraine's MoD.
I've been dragging on my feet about blogging a manifesto for the three-sided cards, first because the system was changing by the day (it was a big thing for me to realize I could eliminate paper jams by printing the back side first) and then because I found hugo is good for anything except things that involve quantitative thinking or artistic sensibilities. I am still looking for a static site generator that's the equal of the subjects I want to blog about.
And they're using the very latest macbook pro with a fast and reliable internet connection, on which the site/app seems to work just fine and must therefore be ok.
Circa 2008 I was working on a Silverlight RIA in a company that had MSDN subscriptions for everyone.
It worked just fine over the LAN off the server in our Ithaca office but when we demoed it for the people at the office in Rochester it took the application 40 minutes to boot because of all the round tripping.
That won me all the arguments I'd been having about excessive round tripping, getting that 40 minutes down to 40 seconds wasn't hard once those questions were resolved.
I've become "that guy" in presentations who constantly tells people "fonts too small", "can't read cause the contrast isn't enough", etc... My hope over time is that I stop being invited to meetings or people actually take the time to fix their presentations before it is presented to a wider audience.
I had the old MS Surface Pro 2 (11" screen, I think) as my daily driver for awhile, and found that designing PowerPoints and conference sessions - including code demos - to be legible on that screen led to better presentations.
For presentations, I've observed that constraints on number of slides encourage people to try to stuff a bunch of information at small font sizes on a single slide, often big blocks of text. And they are laying it out on a high dpi screen that ultimately gets scaled down when presenting (especially with screen sharing). They'll have two data points in a small font and massive amount of empty space on the slide. Very few people know how to use presentation tools effectively and most are terrible at information design.
I went through a phase of making sales presentations aimed at C-levels at big co's and was trained to pack the information on two slides into one slide and then consolidate two of those slides into one slide... And do it all without big blocks of texts or small fonts but rather well-planned complex diagrams that would draw people in and provide a great foil for spoken explanation, answering questions, etc.
In the hands of a lot of people though Powerpoint is a tool for insulting the intelligence of the whole room.
If you know what the presentation is about from reading the slides then those are bad slides. Slides exist to support a presentation and should not make sense without someone explaining it.
If you want to understand without attending a presentation then what you want is a paper, or book. Those are very different formats.
This is true if the slides are for a presentation, but unfortunately, many people in business (coughconsultantscough) use the deck as their deliverable and cram all the information in there. A memo or report would be better in most cases, but the culture is what it is, and at the end of the day, if the CEO expects a deck, the CEO is going to get a deck.
I've given many presentations where I has to provide the slides, which were then repeatedly emailed as samizdat. Easy 10x as many people only read the slides, but a document would not have reached them at all.
Do not confuse documents written in power point with slides written in power point. Power point is a tool, it is often abused to write documents even though that isn't why the tool exists it does work. Many people prefer power point documents because it makes you think about bulleted lists which is what they want to see, but those are documents not slides.
My first PPT presentation was a single graph on a slide with large axis titles and labels. It summarized the output of a model we were building.
Manager wanted to add a ton of content that they felt would be helpful. I said sure, and added it to an appendix with arrows, callouts, additional definitions, etc.
I then presented it to the CxO group -- we only discussed that first slide. I emailed the deck, and got comments back saying that the appendix was confusing but they loved how simple and clear the single non-appendix slide was.
I've always tried to follow the 4x4 rule: no more than 4 lines, and no more than 4 words per line. I've found icons and occasionally diagrams can be helpful in explaining more abstract concepts. Also, slide notes are used liberally.
One place I worked was veeery similar to what you describe here. PPT was considered docs of record since no one wanted to make formal memos and have those enter the control system. My approach had friction, since I would be extremely concise and direct people to the slide notes if they had questions. In this org, people were notorious for lifting slides from others decks for their own presentations (hence I would distribute as PDF to discourage this) since people would not field questions those slides might raise.
This doesn't make much sense to me. I have coworkers who are 50+ years old, so are you saying everything should be size 50 font? That seems pretty ridiculous and kind of like mocking them.
Websites have that ability, both in CSS with types that are defined relative to the users set font size, and to detect it in JS. The platforms capability is not the problem here.
Hmm really? How do you do that? The `rem` and `em` CSS units do not reflect iOS font-size settings if this is what you mean (I don't know about Android).
1 rem is supposed to be the font size of the root element. 1 em is the font size of the parent. If a browser isn't implementing those in such a manner then it seems like it would be a bug.
It's true that mobile Safari seems to lack a setting for default font size or what Mac Safari has, a minimum font size setting.
It does have a default Page Zoom setting and it will remember Page Zoom changes per-domain (e.g. I have this site set to 115%).
There is a way for web sites to make use of iOS's Dynamic Type setting [0] to make text larger, but it's up to each site's author to include the requisite values in their CSS.
Even native apps are often broken when you enable "large fonts". I've used large fonts since forever and even now are using 1440p on 32" screen (I'm not wearing glasses or anything).
My presentations use the defaults on Impact - big fonts, black on white, no border, no decoration.
From time to time people complain and say I need to "get with it", but not a single person has complained they couldn't read them from the back of the room!
> normally sighted people or even people with "normal" nearsightedness, farsightedness, or presbyopia benefit from adequate contrast.
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
I have the default font size boosted slightly. A large percentage of web sites and applications don't work with it, the text is cut off. Even ones from Microsoft.
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.
I have Dark Reader installed, adding to that, I actually changed my browser's (Firefox) base font colours to light text on dark background to prevent white flashing issues in pages that ignore dark stylesheets.
I know exactly what you're talking about. A lot of times those tables are sized exactly for a horizontal view, so always try tilting your phone 90 degrees and it may work.
This is a constant issue for me (Chrome on Android) on GMail's Web UI (yes, I insist on using the Web UI...). So many emails are entirely unreadable since they go right off the right side, and you can't zoom.
It's just constant. I know I am an oddball but I use firefox, which at this point is basically unsupported online. Pages just _dont_ work right. Of course my 600 extensions, from tridactyl(vim kb) to no script tend to break even more.
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?
As a fellow Firefox user this is not my experience at all. Most stuff works fine once I allow the necessary subset in uMatrix. Some things are a pain in the ass, like embedded video widgets that need to load in dozens of scripts from all over the web before they'll finally get to the actual video frames, but I can pretty much always get stuff to work.
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.
Same here..I don't even have another browser installed on my main machine. Never have the need for it, FF works great. I think the OP has too many plugins :)
now some apps grab keys from the browser like "control-F" won't give me a native search modal dialog - instead providing their own search widget. Things like this break experience of the web for me. Combine that with tridactyl which i prefer to use to navigate around and it's even worse.
My addon list isnt that big either... it's just that I disable a lot of things as well, like webGL and other stuff. Suprising number of sites needlessly use these things.
Another maddening thing are tiny fonts on mobile devices and pinch zoom does not reflow text. So you can't read without zooming in, and you can't see the whole page when you do, so you need to put your phone in landscape mode and drag left and right to read each and every row.
This is mostly due to the broken by default rendering of mobile browsers that emulate a larger desktop browser window unless the website specifically opts into the sane responsive behavior via the <meta name="viewport" content="width=device-width, initial-scale=1"> tag. This is especially idiotic since mobile browsers now have an explicit desktop mode that forces this behavior.
Maybe this is a good place to ask since there's a lot of web devs here:
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.
I think it's because almost all web design happens on computer screens, not mobile devices. More important, all web designers show their bosses their creations on a big computer screen in a conference room--the bigger the better so everybody can go "oooh!" and "aaaah!" and the designer can get a big fat raise.
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.
Then they complain that people in that demographic don't use their product. Because it turns out that people in that demographic exist and they're trapped in a bubble where anyone who is using an old device is a child, elderly person or homeless.
Yep. My favourite was somebody said a device was crap and nobody worth pursuing as customer would be using it ... and it was the same phone our CEO was using.
You don't need a collection of devices to test layout issues - just use e.g. Firefox's Responsive Design Mode [0] or another browser's equivalent and resize the viewport to whatever. Same applies for native applications - make your window resizable (it should be resizable anyway) and drag the corner around. Does the content behave and look how you'd expect it to? Good. Otherwise, fix it.
I see this "we can't afford to test on different resolutions" excuse with games that completely break for anything that is not 16:9 a lot. Don't target a fixed size. Don't target a fixed aspect ratio. Don't target a set of aspect ratios. Make your application responsive - you don't need different devices to test that responsiveness.
It starts with the fact that designs, and the development that uses them, usually think in terms of fixed rectangles. You've got a 1920x1080 desktop rectangle and a 375x812 mobile rectangle and rarely is much thought put in to what happens when your viewport is a different size. And what thought that is put in goes toward horizontal differences, since the assumption is that things will just scroll vertically.
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.
> What is SO effing hard about drawing within the screen on web?!
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.
> There’s no easy way to say “this is a full-width container and nothing inside it can go off screen.”
overflow: auto;
> As an obvious example, any descendant of that container can use fixed positioning and do whatever it wants.
Fixed positioning is you explicitly opting out of composability.
> 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.
No, the way to fix it is to look at your DOM and CSS instead of adding more abstractions with broken edge cases on top of your abstractions.
It's because designers work with placeholder data. I worked full-time as a dev and saw this over and over and over again. The good designers would adapt, but some never learned.
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.
Sometimes you need to prevent zoom in order to implement your own zoom though.
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.
maximum-scale and user-scalable=no seem like browser mis-features. Perhaps the OP would have more success appealing to browser developers to follow Apple and Samsung’s lead, and get browsers to ignore them?
It's definitely always a mis-feature for websites. It can make sense for webapps in rare cases [0]. Well, disabling the pinch gesture makes sense for those, ideally the browser would still provide another way to change the zoom.
No. Sometimes it's good to disable zoom (e. g. in web apps that function as a big canvas, like Figma). Pages should use the feature correctly. People shouldn't have to fiddle with browser settings just because someone can't CSS properly.
I think this is where I have to point out that 50% of people who CSS are worse than average at CSS, depending upon exactly how you define "average". You're absolutely right: pages should use the feature correctly, but some won't (because of my previous point or, much less frequently, out of sheer stubbornness/malice/whatever), so I'm extremely glad that browsers offer a workaround via settings for situations where that's the case.
I agree with the grandparent. While I believe it’s irresponsible for web developers to inappropriately lock zoom…I also believe it’s grossly irresponsible for the browser to not provide an override for this.
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.
Figma does it correctly, that's the point (they have custom zooming logic) - if user has to fiddle with their zoom-lock settings because of other pages, then pages like Figma which use the feature correctly and for the intended purpose will stop working.
I am convinced. I wish per-site zoom controls would show up as a setting somewhere in the browser chrome because I think that would make this a non-issue, but the differentiation is valuable since some sites should block zoom. Okay.
To be fair, if those attributes had never been standardised it wouldn't need to be a user agent concern. But I agree, all browsers should follow Safari's lead and ignore them.
Unfortunately this also disables it on sites where it makes sense. For example I have a simple tool to pick a random person or split people into groups https://playerone.kevincox.ca/
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.
That tool is a gem! I didn't have many situations where I could have used this during the past two years, but things seem to become a little better now.
Thanks for the kind words. The same for me, I used to use this at least weekly, but now I'm lucky if I open it in a month (although regular board games are coming back to my life).
Yep, exactly this. I have that setting enabled myself due to e.g. Blogspot inappropriately blocking zoom in its default mobile template — but on the other hand it does unfortunately mean that e.g. on openstreetmap.org I occasionally end up zooming the page instead of zooming the map…
I kind of wish the author had lead with this instead of burying it at the bottom. For whatever reach the article gets, this is the part that's going to offer value to readers (it seems unlikely this article will sway a significant number of web developers to change their habits).
I dunno. This article is like a 2 minute read. Starting with a solution nobody asked for sounds like an unreasonable request, while I did like hearing about these options after realizing how big the problem is.
The goal isn't to help the readers though, it's to convince web developers to fix their websites.
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 goal isn't to help the readers though, it's to convince web developers to fix their websites.
It seems like that battle is already lost, this isn't some default setting that they are just accepting, web developers are doing it because they think they have a good reason, some random blog post isn't going to change their minds.
I'm willing to bet that most developers just copy/pasted the line of code that disables zoom from a framework or tool. The goal of most people who add these lines is to make the page fill the screen right on mobile devices. I'm sure some are user-hostile enough to disable zoom, but most probably don't have strong feelings one way or the other.
Bringing this to developers' attention might very well be enough to get tons of people to remove the zoom block from their websites.
For those of us with disabilities, this is every situation of our lives all the time.
The disadvantage of being disabled doesn’t come from the way that disability limits us as much as it comes from the countless ways it makes all the normal things people do slightly harder.
Advocates fight to change these things not because it’s easy to do but because eliminating at least some of the hurdles in life makes our overall experience a little easier.
I think it cultivates a healthy mindset though: At an early age, you learn that all assymetric tools were designed by idiots, so by kindergarten, you're already questioning everything.
I suspect this is why lefties are drastically overrepresented in leadership positions, NASA, etc.
One could say that being left-handed a disability that requires a low level of support.
I really like this line of thinking because I think abled people are often overwhelmed by the prospect of disability. I bet left-handedness is the sort of impairment that people can get their head around as a starting point.
I’ve tried using my vision impairment (which requires a low to moderate level of support) to describe the same thing, but peoples’ eyes tend to glaze over as soon as I say “amblyopia”. :-P
> At an early age, you learn that all assymetric tools were designed by idiots
Then you have learned the wrong lession. Assymetric tools might not be inclusive, but they are generally designed that way because it brings some kind of advantage.
Try explaining that to a five-year-old whose faith in humanity hasn't yet been crushed by an endless stream of corporate design-by-committee compromises.
Yup but it seems to me like the default behavior should be reversed. It should be accessible by default, and for the few special cases sites where zoom interferes with their functionality, then the setting could be toggle to disable it.
Additional headers on every request should only be considered if there really is no other option.
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).
But then the website might not look like the designer's glistening perfect vision, that only ever worked properly in their browser on their desktop in the first place.
The reason this is done is to get rid of extra latency when processing user input. I guess detecting zoom gestures needs some time to distinguish them from normal clicks?
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.
In the old days you needed to disable zoom in order to get click events immediately, rather than delayed a bit so it can tell whether it's really going to be a zoom operation. Is that still true?
Yea, still a 2-300ms delay, which is why I guess a lot of devs just disable zoom - that way they get that "instant native app" feel without actually having to think about it :)
Edit: Having just tried the sites in the Safari ... they zoom in just fine with that set, so .. Im a bit confused
Would it be better to editorialize and say "Please, stop disabling pinch-to-zoom" instead? Or would that be too specific? I still thought it had to do with the Zoom product even with the case change.
Yes! I have good eyesight but still frequently zoom for various reasons. The main one is small images and diagrams on responsive websites. Another is clicking small clustered links.
In the same vein, if you use images on your responsive website, consider linking to the full size version.
What's really weird is how some sites go out of their way to do this. IG for example, even on desktop, presents a fixed size image and prevents right-click operations on the image. Meanwhile, the full resolution image is actually available if you know how your browser works. Another example is video controls like scrub and speed being unavailable.
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"?
I have decent eyesight post-LASIK, but I have a lot of trouble reading small text. I almost always read books in large-print if it's available, and the Kindle has been a godsend for this particular reason. I've been tested for dyslexia and I don't have it, I just have a weird brain that has trouble with small text.
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.
Hey, this is an issue I'd like to work on. My eyesight is good but not as good as before, and it made me reconsider my font and contrast choices on allaboutberlin.com. I find myself zooming a lot more too.
Can you tell me what you think of the font sizes? Is it readable enough? Is there room for improvement?
My pet theory: I'm pretty sure this is because when HTML5 became a thing, some major tech blog showed us what an HTML5 page would look like (simplified doctype, meta charset) and they included the viewport settings that disabled zoom.
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.
Almost all major template for JS frameworks these days include that line. And there are tons of guides that specify adding that in.
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.
I assume it's something some "website builder" site like wix.com does. For instance, wix.com itself shows "user-scalable=no" in the viewport meta tag if your user-agent is from an iPhone.
> override some annoying mobile browser behaviors like zooming on an input.
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.
Safari only zooms if your input text is too small (less than 16px). The answer to defeating autozoom is to not make inputs that many people would need to zoom manually.
Developers are usually not the ones who are making decisions like this.
The manager doesn't want that annoying autozoom. The designer doesn't want to change the font size or page layout. There are also edge cases where something that was supposed to be 16px ends up being slightly smaller because of unit conversion and Safari zooms anyway. The developer, tired of this bullshit, googles a solution to satisfy everyone.
Fortunately, there's yet another workaround for developers stuck in this situation. Drop "maximum-scale=1", but keep "user-scalable=no" in the meta viewport tag. Safari will ignore the directive and allow the user to zoom freely, but this somehow disables zooming on inputs. Makes sense, huh?
One browser implementing a non-standard feature that doesn't even work consistently eventually hurts everyone, including the developer and the user. Just blaming the developer misses the larger problem.
Fun fact: the reason why browsers sometimes zoom in on an input is because the input's font size is too small, less than 16px, which is considered not accessible. So it's ironic that to counter that behaviour some people make the page even less accessible by disabling use zoom.
To be fair, I don't think the current implementation of auto-zoom, at least in mobile Firefox, actually makes things more accessible. The zoom it choose is ridiculous so you lose all context (and often can't even see the whole input element) and the screen constantly jumps around when filling out a form.
Classic Hanlon's razor "never attribute to malice that which is adequately explained by ignorance"
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.
In the late 90s and early 2000s every second bank round these parts decided to do their entire website in Flash. Not just some animations and videos, but I mean the actual entire content of the site was Flash, no HTML. As well as being basically unusable search engines wouldn't index it either so you couldn't find anything.
Also fun was being deep in one of those "rewrite the web browser in Flash" pages and realizing you made a mistake so you hit the back button and lose all of your progress as the whole page is unloaded. Sometimes I look at web frameworks and think that these developers are nostalgic for the days of Flash.
I can confirm that theory. I wrote my own HTML5 template for my blog when HTML5 was pretty fresh. I don't recall where I exactly got the boilerplate from. I thought it might have been html5boilerplate.com, but I just checked the v1.0 tag and that doesn't prevent zooming in. But I definitely took the tag from someone and just applied it without knowing what it does.
100% agree. I'd like to be able to tell mobile Safari to just ignore that setting. Maybe there's a way and I missed it. Wouldn't be surprised, these old eyeballs aren't what they used to be and that exactly why I want zoom to always work. Some of us actually need it.
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.
> I'd like to be able to tell mobile Safari to just ignore that setting
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.
There's got to be some theory to balance aesthetics and readability.
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.
I once had a meeting were 3 coworkers and the CEO were all advocating for disabling zoom because, "other sites do it". I argued that it doesn't hurt anything to leave it enabled and refused to disable it. 3 months later Apple removed disabling zoom from Safari and I felt validated.
FWIW, I can zoom on all of the listed example sites using the pinch action on an iPad. (My eyesight is poor, and this is something I do often to read small text.) Is this something that’s dependent on the browser?
My mother-in-law has severe eye problems and MS type symptoms. 16 years ago, I showed her how ctrl shift +/- could make her fonts huge. This one tip that is not obvious to most folks improved and continue to improve her quality of life _drastically_.
Thank you! As a visually impaired user, disabling zoom is just incredibly stupid, except for a few edge cases such as games.
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.
While we are at it: please stop changing the right mouse button in my browser. I‘m looking at you MS Teams. If you want to have context menus in your app, that’s ok, but please don’t put them in the browser. You break important use cases for me and other people.
Firefox has an override for that, shift+right mouse should ignore the click handlers and show the browser context menu. This is something I really miss in other browsers, especially the ones that decide that they know better than me about how things like copy/paste are supposed to work.
This website [1] (actually, its codepen [2]) has a demo and even describes all the user-hostile reasons why developers might want to disable the right click menu.
There are some other accessibility tricks that Firefox advertises [3] like ignoring website font and color choices.
Firefox also has native support for overriding website CSS [5] but "modern" websites often come with impossible to understand DOM and CSS structures (if they even use CSS and not just forcefully insert style into the DOM directly because separation of concerns is for losers I guess).
Then there are websites like Github and some shitty forum software that insist on hijacking keyboard shortcuts like Ctrl+F and Ctrl+K. You can go into about:config and set permissions.default.shortcuts to 2 (Services.perms.DENY_ACTION) to block websites from overriding shortcut settings by default. You can go into the site settings and manually enable them again by going to page info (ctrl+i), then tabbing over to permissions, and changing the value for "override keyboard shortcuts" from "default" to "allow". Or, you could simply block the websites that offend you from that screen without changing the default.
We used to disable zoom, out of a sense of "our site doesn't need you to zoom", and partially because of cargo culting. Everybody just pasted the same meta tag everywhere.
In the end, it's nobody's business but their own whether they zoom or not, so why would I disable it?
I don't understand why the functionality exists for websites to dictate how users can and cannot view a page in the first place. This is like if you were reading a book that detected if you were trying to use a magnifying glass and immediately caused a glare to appear to prevent you from being able to read it. It is fucked up.
It is the creator's right to dictate the original presentation, but it is not the creator's right to dictate a user's behavior. Just like it is a filmmaker's right to set the default framerate and playback speed for a film, but you can rewind or fastforward, or play the film at X speed if you so wish in your media player.
Disabling or otherwise inhibiting user behavior is not a creator's right.
> I'm not sure why people believe they have a right to dictate how someone else's content is created.
I do not believe anyone here is at all believing that they have a right to dictate how someone else's content is created. The argument is about modification, not creation. People should absolutely have the ability to modify their local version of the content to make it readable to them.
The choice to allow zoom, or scrolling, or window resizing, or even fonts and colors... basically anything that affects my web browsing experience, should belong to me as the user, not some web site developer 1,000 miles away from me. Browsers have taken way too much control from the user (or hidden it in Settings menus) and handed the controls over to web designers. Browsers have a setting to take back this zoom control, but really it shouldn't be a setting--it should be the default. The web developer should not have the ability to disable a feature of my browser any more than he should be able to reboot my machine.
I don't understand this argument. Leaving aside the fact that the examples provided in the link are hardly works of art, the "creator" has already created something the way they wanted to, as has every other website designer. And just like there would be no good reason for an editor to stop me from using a magnifying glass on a book that I bought, nor from writing notes in the pages or highlight parts of the text (advisedly or not), neither does anything justify disabling zoom.
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?
There was a fundamental shift about 15 years ago where webpages ceased to be markup documents (perhaps with some active elements for convenience) and became javascript applications that ran in your web browser.
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.
I figured this would happen. I've also committed the even greater sin of testing in only one environment (my own). I guess we don't quite live in the future yet.
308 comments
[ 2.9 ms ] story [ 220 ms ] threadiOS 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.
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.
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.
For example, take buildings -- they typically have stairways, often as a fire escape route. However, stairways are not usable by everyone. Should we ensure that buildings have no stairways at all because there exist some people who can't use them?
To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Extremes are always unreasonable, the goal should be to support everyone that you reasonably can. Nobody is telling anyone to make their tools work for the blind deaf and mute quadruple amputee - but that does not mean that it should be acceptable to completely ignore the variations in capability of people wanting to use your product.
> To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Blindly following guidelines leads to problems, yes. But you can achieve the goal of making the spreadsheed usable for someone who has trouble with small click targets: For a desktop program you should consider adding efficient and discoverable keyboard navigation so that noone needs to click anything. This will help power users as well as those with fine motion problems. In general, a program, unlike a physical staircase, is also something that can dynamically adapt to the needs of the user. For example you could make your spreadsheet zoomable. For a desktop program it could be OK to rely on third-party (or platform-provided) zoom utilities - just don't write your program in a way that makes those impossible to use.
For buildings such dynamic adaption is not as feasible and so we make compromises that require some people to rely on others for help in incommon situations. But even there we should do what we resonably can - for in many parts of the world public buildings do have wheelchair-accessible entrances these days, even if the emergency exit is a stair.
A staircase isn't accessible, but still allowed. The accessibility is in an alternate implementation provided for those who need it.
A phone call is an accessible alternative to a website. US law says that the phone call must be offered at the same price as the website, for those who need it.
Exactly this -- some things just aren't going to be for everyone. If we truly wanted to make buildings "accessible", all stairways, and even printed signage would have to be banned, as there exists someone who cannot benefit from it.
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 web was not designed with accessibility as default. Instead it is a significant amount of work to make things accessible. Every project incurs huge cost in order to achieve it. I truly believe from an accessibility standpoint the web is simply broken. So sure, blame it on young programmers. But that's a poor excuse for where we are at today in my humble opinion.
This has got to be satire right? HTML is accessible by default, it's your horrible JS SPA frameworks that break thid. See [0]
[0]: https://motherfuckingwebsite.com/
I haven't perceived maintaining accessibility to be a big burden in the long term.
Interestingly the accessibility project forced me to raise my game on CSS/HTML, graphic design, etc. and probably had a bigger impact on my side projects than it did on my work.
Now multiply this times every web app in existence and the cost is quite large. A lot of this could be avoided with a better platform.
It seems to me the web is accessible by default. Write a plain old HTML page and everybody should be able to read it (assuming they have a computer to open it or a printed version).
People go out of their ways to mess this up by using fancy colors, fancy web fonts, messed up JS (frameworks), non standard components because it's cooler, disabling outlines, and so on.
Do you have examples where the Web is not accessible by default, apart from the by default unlimited line width which is easily fixable with one line of CSS?
Sure you need to use the right markup for the right things (and, no, <div> is usually not the right element for building a button or writing a paragraph, there are dedicated tags for those) but I can't see a way to avoid this.
IF don't fight it and if you respect semantics and progressive enhancement / beautiful degradation. You get so much by default: legible colors and font sizes, tabbed page navigation, alt texts, clickable labels, zoomable interface...
When you embrace the platform and its spirit, you get accessible results quite easily. But not a lot of people seem to embrace it. Many people seem to think "what to do for what I want to see" instead of "what to do for what I want to mean", and you lose if you do this. You need to get your meaning right and then decorate it carefully. You should not paint first. But that's probably not a web-specific issue.
What's more, building accessible things may make you gain time, by having a robust basis. It's not always a cost.
There are native UI frameworks where this is not nearly as big of an issue.
Too much freedom perhaps? Should you even be able to give a div an onclick handler?
What about inputs? Why do developers have to make custom inputs because the core ones are severely lacking? That's where accessibility goes wrong. Because core functionality is terrible and needs to be augmented with richer functionality (but terrible from an accessibility perspective).
There is something fundamental about this platform that does not naturally encourage good behavior. All you have to do is look at the evidence.
As an dumb little example, it's not even obvious that making a div a button is bad unless you know that it is. The platform doesn't guide you at all. It has an onClick handler the same as a button. Little attempt is made to differentiate the two from an API perspective.
I could give countless other examples, but I think I have demonstrated what I am getting at.
> Because core functionality is terrible and needs to be augmented with richer functionality
Well, yes, I agree with both of these points. I think I get your point in the end, and your examples are convincing.
I'd say the web platform is accessible by default but this is easy to break inadvertently and maybe not the ideal platform to build applications because despite its strong accessibility features, it's lacking for what we want to do with it today.
HTML being a format to write documents first and not applications probably does not help neither.
I remember back in the late 90's, and we decided to create a static website for internal use on a project. Everything was supposed to be quick and simple. We weren't after anything fancy, just something that worked.
We used Microsoft's whatever-it-was-called at the time for writing webpages. It turned out that the html produced required some special Microsoft fonts for the web.
Hells bells. The whole point of the Internet is interoperability. But no. We can't have that, can we Microsoft? We need special fonts. Interoperability? Screw that!
About the same time Java on webpages was a thing. We never used them, but I had seen sites that had. So the site had to download some Java craplet, whatever it was called, you had to enable it, plus of course you had to have Java.
Even when the web was still young, people had some really dumb ideas.
Then there was a fad that sites had to have some kind of animated intro on the front page. I remember seeing one for my bank and a recruitment site. No doubt that cost them a pretty penny.
Those early internet fads have died out, but today's websites are no better.
Why does my browser have to download fonts? I already have fonts! Just use one of those!
Anyway, that's me done. I'm off to shout at some clouds. Not the virtual clouds, actual real ones.
Frontpage, I'm going to bet. :)
I was an early user of Frontpage, shortly after Vermeer released it. A few months later, it was bought by Microsoft. Looks like Frontpage was absorbed and discontinued (https://en.wikipedia.org/wiki/Microsoft_FrontPage).
It was handy but I was just messing around with a very simple personal website and most of the time I'd just use Notepad or something like that.
>About the same time Java on webpages was a thing.
Guilty... I wrote a simple java applet to draw a polar plot of antenna radiation patterns. Later I added a calculator applet - after all, how handy would a simple calculator only a website away be?? I should have gone with the trends and converted both to javascript... but I did not.
>Then there was a fad that sites had to have some kind of animated intro on the front page
I remember the omni-present "site under construction" animated gif. As in, > 50% of websites had them somewhere.
Follow the link in this article (https://www.vice.com/en/article/9akenz/this-guy-compiled-eve...) for an eye-bleeding collection. Haha!
Yes. That sounds right.
It is on my mind because one of my hobbies is a cyberphysical artsystem that has a small book of design rules and presbyopia is what sets the limits on feature size. (You can't just tell people "hold the card closer")
https://gen5.info/$/XQ*42RXF-TLY:$B.8/
and is made of 8″x8″ cards. That's the first constellation I made, most of the output is either stand alone 4″x6″ cards or constellations. I'm working now on my third constellation from images published by Ukraine's MoD.
I've been dragging on my feet about blogging a manifesto for the three-sided cards, first because the system was changing by the day (it was a big thing for me to realize I could eliminate paper jams by printing the back side first) and then because I found hugo is good for anything except things that involve quantitative thinking or artistic sensibilities. I am still looking for a static site generator that's the equal of the subjects I want to blog about.
Circa 2008 I was working on a Silverlight RIA in a company that had MSDN subscriptions for everyone.
It worked just fine over the LAN off the server in our Ithaca office but when we demoed it for the people at the office in Rochester it took the application 40 minutes to boot because of all the round tripping.
That won me all the arguments I'd been having about excessive round tripping, getting that 40 minutes down to 40 seconds wasn't hard once those questions were resolved.
In the hands of a lot of people though Powerpoint is a tool for insulting the intelligence of the whole room.
If you want to understand without attending a presentation then what you want is a paper, or book. Those are very different formats.
I've given many presentations where I has to provide the slides, which were then repeatedly emailed as samizdat. Easy 10x as many people only read the slides, but a document would not have reached them at all.
It all depends on your audience.
Manager wanted to add a ton of content that they felt would be helpful. I said sure, and added it to an appendix with arrows, callouts, additional definitions, etc.
I then presented it to the CxO group -- we only discussed that first slide. I emailed the deck, and got comments back saying that the appendix was confusing but they loved how simple and clear the single non-appendix slide was.
I've always tried to follow the 4x4 rule: no more than 4 lines, and no more than 4 words per line. I've found icons and occasionally diagrams can be helpful in explaining more abstract concepts. Also, slide notes are used liberally.
One place I worked was veeery similar to what you describe here. PPT was considered docs of record since no one wanted to make formal memos and have those enter the control system. My approach had friction, since I would be extremely concise and direct people to the slide notes if they had questions. In this org, people were notorious for lifting slides from others decks for their own presentations (hence I would distribute as PDF to discourage this) since people would not field questions those slides might raise.
Just like native apps do...?
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
It does have a default Page Zoom setting and it will remember Page Zoom changes per-domain (e.g. I have this site set to 115%).
There is a way for web sites to make use of iOS's Dynamic Type setting [0] to make text larger, but it's up to each site's author to include the requisite values in their CSS.
[0] https://www.interactiveaccessibility.com/blog/text-resizing-...
Browsers are native apps, so they already do that for websites.
From time to time people complain and say I need to "get with it", but not a single person has complained they couldn't read them from the back of the room!
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
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.
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.
My addon list isnt that big either... it's just that I disable a lot of things as well, like webGL and other stuff. Suprising number of sites needlessly use these things.
Follow https://github.com/tridactyl/tridactyl/issues/2712 if you want updates when that's added. It would help if you could link to the website that hijacks ctrl-f in that issue :)
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!
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.
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.
I see this "we can't afford to test on different resolutions" excuse with games that completely break for anything that is not 16:9 a lot. Don't target a fixed size. Don't target a fixed aspect ratio. Don't target a set of aspect ratios. Make your application responsive - you don't need different devices to test that responsiveness.
[0] https://firefox-source-docs.mozilla.org/devtools-user/index....
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.
Fixed positioning is you explicitly opting out of composability.
> 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.
No, the way to fix it is to look at your DOM and CSS instead of adding more abstractions with broken edge cases on top of your abstractions.
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.
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.
[0] https://news.ycombinator.com/item?id=31274454
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.
https://web.dev/accessibility/
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.
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.
Pro tip: Double tap for a few more options.
I've never been able to zoom on mobile apps.
At least one person wanted it: me.
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.
It seems like that battle is already lost, this isn't some default setting that they are just accepting, web developers are doing it because they think they have a good reason, some random blog post isn't going to change their minds.
Bringing this to developers' attention might very well be enough to get tons of people to remove the zoom block from their websites.
The disadvantage of being disabled doesn’t come from the way that disability limits us as much as it comes from the countless ways it makes all the normal things people do slightly harder.
Advocates fight to change these things not because it’s easy to do but because eliminating at least some of the hurdles in life makes our overall experience a little easier.
I think it cultivates a healthy mindset though: At an early age, you learn that all assymetric tools were designed by idiots, so by kindergarten, you're already questioning everything.
I suspect this is why lefties are drastically overrepresented in leadership positions, NASA, etc.
Source: https://www.bls.gov/opub/mlr/2015/beyond-bls/left-versus-rig...
According to the research, “lefties are generally born with a different brain structure that negatively affects their social and cognitive abilities.”
I really like this line of thinking because I think abled people are often overwhelmed by the prospect of disability. I bet left-handedness is the sort of impairment that people can get their head around as a starting point.
I’ve tried using my vision impairment (which requires a low to moderate level of support) to describe the same thing, but peoples’ eyes tend to glaze over as soon as I say “amblyopia”. :-P
Then you have learned the wrong lession. Assymetric tools might not be inclusive, but they are generally designed that way because it brings some kind of advantage.
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).
* 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.
Edit: Having just tried the sites in the Safari ... they zoom in just fine with that set, so .. Im a bit confused
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
How about: "Please, stop preventing mobile users from using the zoom function"
In the same vein, if you use images on your responsive website, consider linking to the full size version.
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.
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'm not a designer but I don't think it looks terrible at that percentage, and I personally found it a bit more readable.
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.
I don't think browsers or users are really the problem. Browsers are paving cattle paths. Users are stuck with what they get.
Developers on the other hand. They're the ones who insist on using a document markup language to describe and build user interfaces.
The manager doesn't want that annoying autozoom. The designer doesn't want to change the font size or page layout. There are also edge cases where something that was supposed to be 16px ends up being slightly smaller because of unit conversion and Safari zooms anyway. The developer, tired of this bullshit, googles a solution to satisfy everyone.
Fortunately, there's yet another workaround for developers stuck in this situation. Drop "maximum-scale=1", but keep "user-scalable=no" in the meta viewport tag. Safari will ignore the directive and allow the user to zoom freely, but this somehow disables zooming on inputs. Makes sense, huh?
One browser implementing a non-standard feature that doesn't even work consistently eventually hurts everyone, including the developer and the user. Just blaming the developer misses the larger problem.
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.
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.
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.
Had a chuckle.
Me: "ABSOLUTLEY!"
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.
Note: I can't test this right now because I don't have any sites that do this particular bad thing
There are some other accessibility tricks that Firefox advertises [3] like ignoring website font and color choices.
Firefox also has native support for overriding website CSS [5] but "modern" websites often come with impossible to understand DOM and CSS structures (if they even use CSS and not just forcefully insert style into the DOM directly because separation of concerns is for losers I guess).
Then there are websites like Github and some shitty forum software that insist on hijacking keyboard shortcuts like Ctrl+F and Ctrl+K. You can go into about:config and set permissions.default.shortcuts to 2 (Services.perms.DENY_ACTION) to block websites from overriding shortcut settings by default. You can go into the site settings and manually enable them again by going to page info (ctrl+i), then tabbing over to permissions, and changing the value for "override keyboard shortcuts" from "default" to "allow". Or, you could simply block the websites that offend you from that screen without changing the default.
[1]: https://www.codeinwp.com/snippets/disable-right-click-contex...
[2]: https://codepen.io/impressivewebs/embed/zYYxepW?height=265&t...
[3]: https://support.mozilla.org/en-US/kb/accessibility-features-...
[4]: https://superuser.com/questions/318912/how-can-i-override-th...
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.
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.
Disabling or otherwise inhibiting user behavior is not a creator's right.
Ultimately, that's the creator's mistake to make and it's incumbent upon the end-user to read the content as they can, if they must.
I'm not sure why people believe they have a right to dictate how someone else's content is created.
I guess I'm more talking about individuals here, not organisations, but I think the problem lies more in individual's websites.
I do not believe anyone here is at all believing that they have a right to dictate how someone else's content is created. The argument is about modification, not creation. People should absolutely have the ability to modify their local version of the content to make it readable to them.
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?
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.
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
https://imgur.com/a/Kgktbvs
Yes. Scaling to the screen size is fine, overriding the users's attempt at zooming in is not.