benpate
Give this a try, and see if it's any more accessible -- https://benpate.github.io/hyperscript-widgets/modal/ -- I've learned a bit since those first demos, and have followed every W3C guideline I can find on accessibility to make them.
One more thing, I'm nowhere near being an accessibility expert, so I'm positive someone who knows more will have suggestions on how to improve this, too. But it has nothing to do with htmx/hyperscript, and everything to do with me being new at accessibility.
Bugs/Suggestions/Pull Requests are always welcome. That's what makes htmx fit for "serious projects."
Edited to add: Htmx is a JS-based extension of the natural hypermedia patterns your browser already uses, not a widget library. All of the demos on the site are just that -- demos that show you the kinds of things you can build, and not plug-and-play, ready-for-npm widgets you can just drop into your application without a second thought.
But to me, the real value in hyperscript is that it’s crafted for the specific needs of a client-side browser application. Using hyperscript, I can get things done in a fast and maintainable way, using a very-high-level language that everyone understands. Sure, I could do it in Javascript too, but the price is significantly more code that is much harder to maintain.
Oddly, I’m building hyperscript into the front-end my current web app for the same reason that I chose Go (over Node.JS) for the app back-end: the end of callback hell. What’s listed above as simply “async transparency” and “event driven flow control” are complete game changers for a web-based front-end — No more callbacks. No more promises. Orchestrate complex animations like they’re “hello world.” And start using events like they were meant to be used, but in ways that you simply never would have thought of if you had to do it in Javascript.
That’s my $0.02. I hope hyperscript works out as well for you as it does for me. Cheers :)