Hacker News

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

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

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.

This is spot on. They are ripe for getting entirely wiped out by AI, and good riddance tbh.

My personal gripe is their refusal to support restarting heading levels within sections, causing whole classes of problems with CMS templating.

ARIA-AT is a W3C Community Group (of which I'm a member) trying to address this problem: https://aria-at.w3.org/about

Why would they want to improve their tools? In many cases (Vispero), they're the ones selling accessibility consultancy

Those have been there for a bit, what is more recent is CSS anchor positioning which lets you position the popover near the item that triggered it. It’s all finally very nice!

> I think the accessibility consultants like this state of affairs: they can threaten more lawsuits and extract more in consulting fees.

I think there is truth in this. A lot of the assistive technology (AT) vendors, also sell consultancy.

Go to the Vispero career pages (who develop JAWS for Windows) and a big chunk of the jobs are remote consultancy roles advising clients on accessibility errors and selling for billable hours.

What makes a web page accessible? Why, it has to work with JAWS, of course!

Vispero makes a lot of money from this; the consultants are all in India, the clients are all in the West, so they can hoover up the difference. I get the impression most AT vendors are extremely cheap, which may explain why it takes decades for them to improve things

It's not really arcane, a div is meaningless because it's simply a container. If you want it to have meaning you can't just add a label. If I put the word "button" on a rock, it doesn't make it a button. That's the same story here.

Is this an arcane rule? "Don't label divs" and "aria-label is for when there's no content in the DOM that can be read" are pretty simple rules. Labels are ways to tell a screen reader about content it can't read, like an image or icon. Pretty straightforward.

It's way way simpler than, say, var hoisting in JavaScript.

> MCP

Respectfully screw making users rely on AI for accessibility. Just make the damn page accessible already. Actually, more like make sure you don't break the accessibility that's there by default with correctly written plain HTML.

To hell with using vision based AI for web accessibility. it really isn't that hard to get right. Semantic html is already accessible. ARIA can help when devs want to use the wrong elements for some reason or for custom controls.

What document?

Do you have any sources to back these claims up?