Hacker News new | ask | show | jobs
by Xirdus 25 days ago
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).
3 comments

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.
I figure there must be an extension to handle these problems, I googled and the AI gave me a bunch of helpful answers, which all happened to be Chrome extensions despite me using FF. hmmm. It did also say it could help me find FF extensions if I really wanted them, but there seems to be some shenanigans going on here.

Anyway, an extension should solve it.

A propos image tricks sites pull, I've noticed before the right click for images don't work at all in Instagram web, I wonder how they do that, probably background on a div.

In my experience, the reader mode works perfectly fine for sites like that (it worked for that one site I mentioned in my original comment as well) both in Chrome and Firefox.
i think firefox shows the "open image in new tab" for backgrounds also, now. at least sometimes. still easily defeated by putting an invisible div above it so no right clicks reach it... or do some js bullshit to disable right clicks...
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...

Six years is getting long in the tooth. Isn't it about time to upend everything once again and invent another cascading wheel that trades old, familiar edge cases for new, unfamiliar edge cases?
clamp is superior to @media because it solves a common problem with @media, although I am more apt to consider that problem in relation to proportions of divs and margins given the needs of responsiveness.

Indeed I'm not sure what edge case I might expect to find given the ability of using clamp in conjunction with @media.

> 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.
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

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.