First and foremost I like hooks libraries and think there should be more of them. That said when looking at their examples this appears to require exactly the same code you would need anyways, but with the additional boilerplate required by the library. Is the goal to add intellisense for people who don't already know how to write accessible front ends? Is the goal to enable me to use a div as a button via hook instead of writing semantic HTML? Not trying to be rude but honestly not seeing the value add outside maybe the FocusScope's restoreFocus and there is no way that works 100% as expected in the wild.

IMO the community is much better served by tools that help you identify accessibility gaps during the design phase, experience your application in other usage paradigms, or audit third party packages for accessibility before taking them as dependencies. If you work with designers who love hover triggered tooltips with forms with more tooltips inside them this library cannot fix the fact that you're making a terrible experience. If you want to npm install React-ported Kendo components because you "remember they worked well with jQuery" this library will not make them accessible. Turn voiceover on, turn your screen off, eat your own dog food.

What's worse "accessibility helper libraries" like this often get used as an excuse to say "of course we made this accessible look at all the helpers in the code" but the team never actually audits to see what the experience is like (hint: your Lighthouse accessibility score does not indicate WCAG compliance), and surprise surprise they've incorrectly implemented the helpers in a way that actually degrades the experience. Then they pay my agency a lot of money to hurry up and do it the right way before the NFB lawsuit drops.