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

reply
> Respectfully screw making users rely on AI for accessibility.

Why? It's the right tool for the job.

> Just make the damn page accessible already.

Oh so just modify every website and expect the disabled people to wait while this happens?

This disabled web browser industry doesn't care about disabled people. Their solutions don't work, disabled browsers are expensive because government grants are given to purchase them.

reply
> Why? It's the right tool for the job.

No, it's not. Why should disabled users be forced to indirectly interact with a webpage via a non-deterministic agent, rather than directly interact with one that's specifically designed to accommodate them?

reply
> rather than directly interact with one that's specifically designed to accommodate them?

Because a world where that happens consistently doesn't exist, it hasn't existed for the last 20 years we've been using ARIA tags, and won't ever exist.

reply
Your advice to "avoid aria tags" would make that a self-fulfilling prophecy. The ways to make it happen:

1. A robust set of web primitives that are accessible by default, and

2. A government that will actually enforce laws (which already exist!) requiring websites to be accessible

reply
> Your advice to "avoid aria tags" would make that a self-fulfilling prophecy.

As mentioned ARIA has had 20 years before by Hakcer News post. It will continue to fail with out without me.

reply
For a user running into broken pages, sure, you have to compose with what you have.

As a developer, however, get your shit fixed! And that fixing doesn't involve any MCP. Don't expect visitors to run AI...

reply
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.
reply
> it really isn't that hard to get right.

Yes you just need every website to use it, rather than fixing the client. Which is the 'boil the ocean' strategy mentioned in the comment you're replying to.

> ARIA can help when devs want to use the wrong elements for some reason or for custom controls.

But it can't. See this article.

reply
See https://www.w3.org/WAI/ARIA/apg/patterns/ for a guide on how to create accessible markup for custom controls and the associated examples.

See specifically https://www.w3.org/WAI/ARIA/apg/practices/names-and-descript... for details on naming. That has extensive notes and details for labeling elements correctly.

See https://getbootstrap.com/docs/5.0/components/ for bootstrap markup on creating accessible components.

There are plenty of other resources.

reply
I did read the article. Why do you need to label a div? It's just a container, not a semantic element. If you really want to use a div for something semantic you can set role and aria-label. That is done all the time and works with screen readers.
reply
What document?

Do you have any sources to back these claims up?

reply
> What document?

https://news.ycombinator.com/item?id=48237159

> Do you have any sources to back these claims up?

Yes, asides from the article, check the prices of browsers from the disability industry and consider for yourself whether it's logically easier to fix every website or make a client that can adapt existing webpages.

reply
NVDA is a free screen reader for Windows (written by blind devs) that works with Firefox and Chrome.

You don't need to pay for a specialist browser as all web browsers (Firefox, Chrome, Edge, Safari, etc.) will implement the native accessibility model of the operating system they are running on (IAccessible/MSAA for Windows, etc.).

In Firefox you can press the right mouse button and select "Inspect Accessibility Properties" or select the "Accessibility" tab from the developer window and it will show the accessibility tree (roles, states, properties, etc.) just like the DOM tree in the "Inspect" tab. That is what the browser is displaying to screen readers and other accessibility software and uses the behaviour of the HTML elements along with the ARIA roles/states/properties defined by the webpage to construct that tree. Thus, it will display an ol/ul as a `role=list` unless overridden to be e.g. a `tablist` by the website.

See https://www.w3.org/TR/wai-aria-implementation/ for a specification on how browsers should implement HTML and ARIA to different operating system accessibility APIs.

reply
Clients can't automatically fix all existing web pages, because the semantic information just isn't there. AI doesn't excuse web developers. It wouldn't even be a fix. Who wants to wait for an AI agent for each interaction?

Not all accessibility tools are expensive:

   - NVDA is free and open source
   - Narrator is included with windows
   - Voiceover is included with macOS and iOS
   - Orca is free and open source.
   - Talkback comes with Android
   - Chromevox comes with Chrome OS
reply