Speaking of WebAccessibilityFails, the article overflows to the left without a scrollbar when viewed on a phone narrower than an iPhone, making the first word of every line unreadable (and there are a lot of lines on a phone narrower than an iPhone).

I keep my browser zoomed in substantially to compensate for uncorrectable vision issues. I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks.

There are several equally useless failure modes I’ve seen with this, a few off the top of my head:

  - rendering fails, everything falls apart

  - some elements disappear

  - it drops into the feature-limited mobile view

  - the author or framework overrides zoom with some other behavior — this one makes me especially crazy because they had to do *extra work* to screw up accessibility
Certain websites are impossible for me to use and I just avoid them.

I remember seeing a website that had <html style="font-size: XXX%"> for the top-level element, and had JS that would dynamically recalculate that percentage on every resize event to keep the visual font size almost (exactly) constant. Made me think for a moment that my mouse wheel broke.

One of my pet peeves in the modern web is when someone displays an image and scales it to exactly the size of your screen, but I want to look more closely at a part of the image so I do a scrollwheel zoom, only for the image to actually shrink as every UI element except the thing I want gets bigger. And then you go "ok, right click on the image and do the "Open Image in new tab" thing and somehow the site defeats that and puts all of their UI crap in the new tab as well.

The modern version is to use @media to achieve the same annoying effect without js. Fortunately, there's a finite number of rules so I've found that if you zoom far enough the text does actually start getting larger. Though I expect that someone's already figured out how to use CSS Math to keep text tiny at all zoom levels.

>The modern version is to use @media to achieve the same annoying effect without js.

I think that is the up until about 2020 way, the modern way is using clamp to do it

https://css-tricks.com/linearly-scale-font-size-with-css-cla...

> I’d say perhaps once per day I’ll encounter a website that has never had zoom in/out (ctl +/-) tested because if you zoom up even one level from 100%, everything breaks

Just tested, hn breaks if you zoom >110%.

How does it break for you? Seems OK to me on android — in fact, I already had it at 110%. Reminded me to check my desktop settings which have HN fixed at 125%. I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!

> I cannot believe that, in 2026, the default font size is set at 12px — is anyone actually reading it at that size?!

The very first "quality of life" thing I do when I install a new computer / operating system nowadays is double (sometimes triple) the default font size. 12pt was probably fine when our monitors were 640x480, and when we were 18 years old.

For some reason I though the GP was talking about browsing on mobile, where I have the issue:

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

The same issue happens on desktop but it requires zooming a bit more than 110%, and is screen-size dependent.

I leave HN on default everything, but I have a 1080p monitor so it might look bigger for me than someone with a higher resolution monitor... I don't know how that works. But I often have to zoom out of websites linked here because the text is so big and it feels uncomfortable to read

Yeah, 12px is fine (27" 1440p, no display scaling). It is on the small side. I'd go a bit larger for something I made. But it's not a small enough to slow down my reading.

Which platform is this on? I usually read hn on a desktop browser, and it works fine well above 110% there.

Android

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

I use DuckDuckGo Browser, Firefox, and Chrome on Android pretty much in that order of preference. In both mobile mode and desktop mode all of these browsers support pinch zoom and two-finger drag scrolling. I have no problems with this site using those.

I think we might need a little more information than just the OS to differentiate.

I browse everything at 125% and HN is fine on my machine so I decided to check. It depends on your width.

1080px wide (aka on my vertical monitor) HN comments stop reflowing > 300%

At 1920px wide it never stops reflowing.

For some reason I though the GP was talking about browsing on mobile, where I have the issue:

https://imgbox.com/EiovsE5b https://imgbox.com/A4Fl9lE9

[deleted]

This is caused by using CSS grid with "minmax(auto, 57rem)" and an overflowing table. It can be fixed with adding "safe" to "justify-content: safe center" that is defined on main.

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

Funny how the problem itself is created by CSS, and the solution is "more CSS." On the other hand, bare HTML tends to be extremely accessible and lacks these kinds of basic problems with panning, zooming, and scrolling.

CSS is this weird thing where it has dominance as a layout engine because it is so battle tested compared to a lot of other layout engines, but was clearly designed by a committee that could give a rat’s ass about how ergonomic it is to use.

It took until 2023 to support nesting, something that was so obvious that preprocessors have had it since at least 2006.

Bare HTML is pretty bad for accessibility. For example, you get no maximum width, making websites painful to read in a wide window.

Windows are resizable. Built-in width selection!

You can’t set a different size per site. More width is better for sites that have sidebars and stuff.

The most infuriating case I've seen within the last few days is the Airbnb CAPTCHA, which relies on the user being able to see content that is blocked at zoom levels over 100%. They have an alternative audio option that they've clearly never tested; it always reports failure, even if the CAPTCHA was solved correctly. Unthinkable for an organization with their resources.