Support efforts for computer vision based browsers, MCP and APIs.
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.
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.
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?
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.
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
As mentioned ARIA has had 20 years to succeed before my Hacker News post. ARIA will continue to fail with or without me.
ARIA attributes are only one of the tools to help with web page accessibility and are somewhat last resort when you can't do what you aim to do with bare HTML.
The first tool is to not break stuff in the first place.
The solution to "accessibility is not ideal across the world" is certainly not "Outright avoid tagging stuff for accessibility anyway", as if using ARIA attributes were somewhat harmful. It's not, unless you misuse them, and no, the spec isn't unworkable, and you also don't have to use it all.
The response to "software is broken" is not "software has had 50+ years to be bug free, let's put the burden on the users to deal with it since obviously developers can't do bug free".
I feel that claiming the web now consistently complies with ARIA is an incredibly bold claim, and the burden of proof is on you but you can test the top 50 websites yourself if you genuinely believe that.
> are somewhat last resort when you can't do what you aim to do with bare HTML
This thinking was popular 20 years ago when ARIA was created. Application-like behaviour, which nearly always means JS, is the majority of websites.
> ARIA attributes were somewhat harmful
Wasted engineering effort on minimally effective outcomes is harmful.
> "software has had 50+ years to be bug free, let's put the burden on the users to deal with it since obviously developers can't do bug free".
Others not following your religion is not a defect.
... that I didn't make
> This thinking was popular 20 years ago when ARIA was created. Application-like behaviour, which nearly always means JS, is the majority of websites.
That's besides the point, your JS code still generates HTML. Writing applications in JS doesn't change anything about the topic.
What I'm saying is that you mostly don't need to use aria attributes with a good HTML structure, generated from JS or not. Use them sparingly when you can do it in pure HTML (again, generated or not).
> Others not following your religion is not a defect.
That's not an answer to the stuff you quoted and there's no religion here.
You have a point about web accessibility lacking but we'll have to disagree about "let's just give up good practice since it's not been perfect despite all these years". Actually, you are not claiming "not perfect", you are claiming "not present", but you're wrong on this as other commenters told you.
> ... that I didn't make
Ok so you agree that the web has not and is unlikely to be ARIA compliant?
But then persist in supporting ARIA despite knowing that goal isn’t and never will be achievable?
That seems exactly like religion.
> you're wrong on this as other commenters told you
As does this. Nobody has refuted the point in the original post that ARIA is a boil the ocean strategy, in face you have just conceded it. What makes you think other commenters disagreeing would change that?
There are imperfections in any piece of furniture and yet we are still building furniture? How religious!
You sound like this to me.
There's a whole world between "accessible HTML is never achieved anywhere" and "accessible HTML is fully achieved everywhere". As other commenters already told you, we are actually mostly there, there's no complete failure here. Sure, shit's not perfect (far from it, sadly...) but I feel like you are throwing the baby with the bath water.
I'm not willing to increase my electricity bill or spend tokens to make up for your unwillingness to use widely accepted - and mandated by law in many cases! - solutions. I'll just pass and probably others will do as well.
I'll stop here, this is not productive, none of us will likely move from where we stand. Let's just say that you are apparently alone in your position here in this discussion and you have so far failed to convince us. Call that position in which everyone here is except you "religion" all you want. I'll even snarkily risk a tu quoque by emphasizing that AI is no magic dust.
Good day.
Because, asides from users interacting with less programs than they do websites it’s not possible for a user to systematically fix all the programs they interact with. You are proposing an 0(n) solution instead of an 0(1) solution.
That should be incredibly obvious before this discussion even started, and even more obvious after reading this far in the thread. You’re replying but you’re not paying attention to what you’re reading. I’m not going to bother continue reading or interacting with you any further.
As a developer, however, get your shit fixed! And that fixing doesn't involve any MCP. Don't expect visitors to run AI...
Why not? That's a more reasonable expectation than asking every website to change.
I won't blame a disabled user seeking AI-based tools to browse the web to survive with what they have, but I will totally blame the devs who created the situation.
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.
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.
You also said that ARIA can't help with custom controls in that post, which is where the other links are applicable as they describe doing just that. I.e. using ARIA tags to implement tabs, accordions, etc. either with or without a framework library.
I didn't write the post. The author believes in ARIA, I believe ARIA is fundamentally broken.
From https://news.ycombinator.com/item?id=48281764:
> > 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.
Do you have any sources to back these claims up?
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.
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 OSYes 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 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.
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.
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.