Why not try it? But also, why wouldn't it?
I completely agree that this is a pain point. In general, high quality documentation is lacking. I am not however convinced that this is a problem that can be automated and abstracted away. Neither am I convinced that it's one we should necessarily try to hide. It won't win me any favors but I think the issue here is simply an endemic skill and knowledge gap. Shifts in culture via higher educational curricula and stated quality attribute priorities within companies will do more good here than anything else.
Accessibility is a quality that needs to be built in from the start. The good news is that provided your HTML is sane and not a mess of class tagged DIVs, or you're building a pretty straightforward document-like navigation/content/etc site, you really only need to declare attributes to handle the places you do something unusual. The defaults are generally correct.
Much of this "unusual" behavior that needs special treatment is within custom components (e.g. a custom date selector widget with plenty of invisible divs used for layout of the calendar days can be inscrutable to a screen reader without hinting) and is the responsibility of component library or framework producers. Some issues here run deeper, like properly correlating ARIA attributes in shadow and light DOM. But that being the case, such component libraries aren't even necessarily suitable for many sites (either too complex, or make too many mismatching assumptions).
The bulk of the remaining accessibility attribute slinging that needs to happen has to do with the overall site layout (especially reactive layouts). I don't know of any framework that will handle this for you in a satisfying way for anything sufficiently sui generis. I think the tough but true answer here is "the people building the site should have at least skimmed the WAI-ARIA standard, and be using an auditing tool, and know what to be thinking about as they design the site from the start".
That guy is asking you if replacing a part of the html with some other html alerts screen readers to the change.
It’s a reasonable question and you could share what you know about how screen readers react when this replacement happens. You could write some documentation on how to alert them, some best practices to follow.
Instead you say read the fucking manual, as if that helps. You put on a veneer of caring for accessibility but it seems you care about the “purity” of htmx more.
Frontend frameworks often do spend a lot of time thinking about the accessibility concerns associated with client side routing, so it's not absurd to consider this question in scope for a frontend library that handles DOM updates.
See for instance this 2019 study by Gatsby: https://www.gatsbyjs.com/blog/2019-07-11-user-testing-access...
Or even the modern Next docs on route announcements: https://nextjs.org/docs/architecture/accessibility#route-ann...
Some of this will have to be bespoke work done on a per-site basis, but I'm not sure I'm comfortable with the idea of completely punting this responsibility to developers using htmx, even if it does make philosophical sense to say "this is scope creep", because ultimately users with disabilities will end up being the ones whose experience on the web is sacrificed on this altar of ideological purity.
Of course it is, but it's like asking if using React.js will prevent SQL injection attacks. They are orthogonal things. Making screen readers announce things is controlled by the HTML you write, not by htmx.
It's actually like asking what a database library will do to prevent SQL injection attacks. And the answer is simple - "don't do string interpolation yourself, instead use the `(?, ?)` syntax". If you use that the SQL escaping will be taken care of automatically by the library. If the database library said something idiotic like "read the spec and implement your own SQL escaping logic" it would be a dereliction of duty.
Make no mistake, a frontend library like htmx has a responsibility to not break the front end from an accessibility perspective. If existing screenreaders break when you replace HTML then the htmx approach is broken and htmx needs to address that.
EDIT: here's the one mention of `aria-live` in the React.js codebase defining it as a valid ARIA attribute for ReactDOM: https://github.com/search?q=repo%3Afacebook%2Freact%20%22ari...
The one mention in Vuejs core to define its accepted values: https://github.com/search?q=repo%3Avuejs%2Fcore%20%22aria-li...
The one mention in the Svelte runtime defining its accepted values: https://github.com/search?q=repo%3Asveltejs%2Fsvelte%20%22ar...
Do people go after these frameworks saying they need to handle breaking screenreaders by dynamically updating content? Of course not. Setting live regions is the responsibility of the web page creator, not the framework.
I'll believe that once I see you file an issue which mentions accessibility against any of the projects I linked to ;-)
https://github.com/facebook/react/issues?q=is%3Aissue+author...
https://github.com/vuejs/core/issues?q=is%3Aissue+author%3As...
https://github.com/sveltejs/svelte/issues?q=is%3Aissue+autho...
Simon don’t waste your time with this guy. I thought he was affiliated with htmx but he’s just some dude trying to prove he’s “right”.
Now if you say that component frameworks like shadcn/ui or whatnot should implement accessible behaviours and patterns, I am 100% with you on that. But React/Vue/htmx are at a lower level, they can't decide those things for you.
EDIT: sure enough, someone filed an issue with shadcn/ui that it does not announce something properly in screenreaders: https://github.com/shadcn-ui/ui/issues/4209
My problem with that is that, as you can hopefully see, I am very motivated to learn how to do this... and yet I have not managed to learn it.
"Learn how to do it" only works if there are clear and obvious resources we can point people to that will help them learn what the need to learn. The ARIA spec is not that.
This also feels like an inherently solvable problem, which is why I always take any opportunity to put it in front of people that might feel incentivized to help solve it.
There are. Start with MDN. There is no more clear and obvious resource than this: https://developer.mozilla.org/en-US/docs/Web/Accessibility
There was a time when I didn't know anything about web accessibility. But I learned by reading, trying out small experiments, and using a screen reader to check my work. If I can do it, you can certainly do it.
After a while you face issues like 'Why isn't the screen reader announcing the dynamic content update', you search for solutions, and you come across incredibly helpful content like this: https://tetralogical.com/blog/2024/05/01/why-are-my-live-reg...
> This also feels like an inherently solvable problem
It shouldn't, especially if you don't know anything about web accessibility. It's hubris to think that something we know nothing about should already have been solved, why hasn't it? Is everyone else just an idiot? No, of course not. It's a complex and nuanced problem. Not the basics like always put an `alt` attribute in your `img` tag, those things are easy. But when you insert dynamic updates with JavaScript into the mix, it gets more complex.
And yes, I agree it is not the clear and obvious resource we can point people.
We DO need better "guide" format documentation, rather than dry technical reference. Nearly everything I've seen online is in very poor shape or outright wrong.
I share your feeling that it is solvable, and I also hope that people will help solve it.
But I'm sure of one thing: the people who write that documentation will be familiar with the specifications and refer to them (among other sources) while writing.
An "Accessibility Book" (like sections of the Python and Django docs, or the Rustonomicon for unsafe Rust) would be a fantastic resource and I hope someone writes it.
More generally, I often see people calling others "lazy" for not making websites accessible, but I personally found it hard to get my head around the WCAG recommendations, and I work with designers/developers all the time that don't know how to follow the WCAG recommendations even when you point them to documents and tutorials.
It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
There are some sites that try to document what works and doesn't in different screen readers (e.g. https://a11ysupport.io/tests/), but even then it's still not easy knowing what to do and I don't know of an authoritative up-to-date site.
> It's like nobody wants to admit it's difficult, and that's not even getting into screen readers still having many inconsistencies for basic UI patterns.
Accessibility IS hard.
It feels sometimes like nearly everyone involved thinks they'll just read a few good blog posts and know how to make sites accessible. Then the struggle is due to not having read good enough blog posts.
Everyone wants a quick "fix" to a lack of education. Nothing replaces familiarizing one's self with primary source specifications, and most crucially, spending significant time trying out real screen readers.
I feel completely starved of information here. I care about accessibility. I want to build a web page where clicking on a tab refreshes a subset of that page... and I still can't find a really good guide on how to do that in a way that works in screen readers, that's accompanied by a video (ideally multiple videos, one for each common screen reader) showing the experience I can expect my users to have from that pattern.
HTMX actively encourages that pattern, so I'd love to see the project also embrace helping developers do The Right Thing with regards to the accessibility of that pattern.