i doubt it will be a silver bullet, but I've been meaning to add an accessibility section in the docs

Yeah, I'm reworking my tabs for that now. If we have a widget library that's 1000% accessible and blessed by the accessibility gods from on high, it will close down that argument pretty quick.

it's just the dumbest go-to argument from the complication mavens and it'd be nice to have a simple link demonstrating that they are wrong and don't deserve their salaries.

but every time I start mustering up the energy to write it, someone comes along like this and my shoulders just sag: https://twitter.com/samwightt/status/1475289259510747137

more uninformed takes from the worst part of our industry :/

htmx isn't even a framework

oh, he seems very informed

they don't even know what these things are

but rather ideological

he does mention unpoly which, I must admit, does a much better job on accessibility

> HTMX is interesting (do NOT use it in production, it has accessibility issues, @unpolyjs > is one of the only accessible alternatives), From that guy as well

i find the accessibility community rather mean like this, however, and it triggers my irish

passionate, we must give him that

you're way too generous.

he's a screaming moron. he's just loud, not informed.

i would love to see the garbage apps these people build and point out the inevitable mass of accessibility problems they've built into their swill

> But the 'server latency' point is just wrong. You can decrease server latency, but you can't beat the speed of light. Other tweet from that guy. 62ms is the worst case scenario I think, if you are using a server on the other side of the world. math

Yeah, that looks like a big red-flag to avoid. No sense in spreading more hate on twitter.

I have always been less concerned with latency under, say 300ms and more concerned with, for example, the back button working and so forth, but it is obviously still a concern

And, 62ms is less time than you spend holding down the mouse button when you click. Seriously. The time between your mousedown and mouseup is long enough to get a signal from Austraila to Denver.

I use some vanilla MPAs that perform quite admirably to my standards when it comes to latency

XD love this little fact.

latency, to an extent, feels like accessibility: we all have issues with it, we are all trying to make it better, let's get on with it

optimistic concurrency on the client side, very hard for me to get my head around, but I am perhaps old fashioned

as a former minecraft pvper I can confirm this - I was never able to click faster than 14 clicks per second, or a click every 71ms.

i don't like "save" buttons that lie to me about the data actually being saved

cookie clicker pro here, i can get 16 per second with a special two handed grip... 😛

Rich Harris made some of the most incredible infographic visualizations I've ever seen but... I feel like by definition they are not accessible, they are very much for people that can see. And this was the reason he invented svelte to power complex viz originally

These types of viz very much needed JavaScript they were not html based documents

i am here to dispense the tea @User, the accessibility weirdos are right, you know. not about htmx destroying accessibility, but about accessibility not being an option or something to debate. "can people use it" is a quality metric for all web software. even if "people" means just you. and it always includes the disabled -- you could lose your sight, your mobility, almost every single ability literally tomorrow. enough moralizing, let me get back to the code. adding an "accessibility" section is not the right fix. at the risk of being 7b'd, here is my 3-point plan: 1. in parts of the docs that discuss powerful features, add warnings > COMMON PITFALL: Although htmx allows you to make a request from any element, you should still [use links, forms and buttons](/docs/pitfalls/links-forms-buttons) wherever appropriate. Consult [section 4 of the HTML specification](https://html.spec.whatwg.org/multipage/#toc-semantics) for more info. 2. go through every example in the docs and perform accessibility testing. if we can't do that, then at least compare our implementation to WAI-ARIA recommendations. most of ARIA is adding-changing attributes so htmx shouldn't have much of an issue. 3. after we do the docs, we get to htmx itself. we tell the SPA crowd that we should not break the existing features of the web, so let's do as we say. - html already has these attributes:

href/action

for specifying url,

method

,

target

. make them the default way of doing things. maybe

aria-controls

could be a way to specify target as well? - look at how the big SPA frameworks do routing and steal their route announcers for hx-push-url. better yet, discourage simulating navigation. 4. reach out to htmx advocates in our community. ask them to demonstrate an understanding of accessibility best practice (we would put it less condescendingly) and help them do so.