Hacker News new | ask | show | jobs
by ramblurr 19 days ago
What document?

Do you have any sources to back these claims up?

1 comments

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

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
> Clients can't automatically fix all existing web pages, because the semantic information just isn't there

Yes it is. Webpages semantically provide information on the purpose of onscreen elements by their appearance. Vast quantities of humans ensure the semantic information is there by using the websites. Websites that do not convery semantic information through their appeareance will die, because nobody is using them.

> Not all accessibility tools are expensive

I want to acknowledge your point here - the situation may have improved the last time I looked at accessibility tools, which at the time was mainly overpriced badly maintained proprietary software. I still think the "boil the ocean" strategy is discredited and wrong.

I'm glad that a large proportion of web developers are happy to boil the ocean then. I use the web every day with a screen reader. It works. 99% of what I want to access is fine. Often not perfect, but a whole lot better than what I could get out of AI.

I do use ChatGPT to research things, but I don't usually see that as accessibility solution. I completely agree that screen readers and browsers would benefit from AI, as they already are; Chrome and Edge can generate missing image descriptions. AI can certainly enhance accessibility, but it can't replace the existing technology that already works quite well a lot of the time.

The other positive about AI for accessibility is that the frontier models have a good understanding of what works. Instead of learning all the guidelines, you can just ask an agent to review the page for accessibility and fix any problems.

I realise I am only looking at it from a screen reader point of view, and yes, we are quite a small minority. But good universal design helps everyone, whether they just need to zoom the page for comfort without it breaking, their eyes are not that of a young person, they have dexterity issues using a mouse, and many more. Accessibility in general isn't serving a tiny minority,. I imagine most of us will come to appreciate it in some way.

> I'm glad that a large proportion of web developers are happy to boil the ocean then.

That’s not how that expression works. The ocean is every website. An individual developer cannot modify every website.

More to the point, most websites are not accessible, will not validate, and this will never be the case.

It's not a binary. most web sites are accessible to some degree. Just the fact that semantic elements exist at all makes a big difference. Popular frameworks have accessibility built in.
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.