That's what makes it so bad, even their little incomplete snippets can't use many tags correctly. From H1 + H2 pairings, to lists with headings, to paragraphs around non-paragraph content, to using FIELDSET and LEGEND for each and every blasted INPUT in an app doing LABEL's job, to lacking media targets across near every deployment, to the use of scripting for things that are none of scripting's business. These clowns DO NOT know enough HTML to be using JavaScript to manipulate anything remotely related to it.
As to their "accessibility" page it's telling they start out with Aria roles, which are already obsolete -- even according to some sections of the WAI-ARIA text -- thanks to HTML 5. Remember, MOST aria roles should be used when you can't use the correct tags or attributes. Since there is in point of fact no real-world scenario in which that should be a thing... well...
Which is why even the example they start the page with is junk; what with aria-required being redundant to just plain "required", and "aira-label" being redundant to having an actual flipping label tag. /FAIL/ almost as hard as the nitwits who don't realize that placeholder is not a label... Like most of the forms artsy-fartsy types vomit up in ignorance of accessibility norms.
But what can one expect when they ENCOURAGE people to use on-event attributes. Even if they are compiling them out, it's stupid to encourage that way of hooking elements.
Just like their document fragment crap and spaghetti code approach to templating, that in most if not all cases is redundant to normal backtick strings or functions/methods, AND tends to piss all over the output markup with their "key" rubbish.
Much less the mind-numbing derpitude of them using htmlfor instead of "for" because they were too stupid to treat HTML attributes as reserved words before they started making this dumbass bloated system.
They then go on to basically just quote WebAIM and MDN on things they themselves and not a single React developer seems to practice, much of it quoted out of context.
The "variables for nothing" spaghetti code of their focus handling is a mind-scratcher since that's generally not something one should have to dick with as part of generation, but one has to remember they go full Gungan with rebuilding entire sections of the DOM even if you're just changing one value, so who knows what you might accidentally trigger with that approach.
THEN they have the cojones to claim that their way of handling the DOM is "faster". Almost as if they swallowed the "speed" lies of the "Shadow DOM" hook, line, sinker, and a bit o' the rod.
Meesa sayz yew nevah goes FULL Gungan.
Thus by the time they get to mouse events they're dicking around with INACCESSIBLE client side scripting (since scripting or CSS off/blocked their chazerei doesn't work) for something that isn't even JavaScript's flipping JOB! Try using their faux-select idiocy on a braille reader.
Again, if you're not horrified by the code on that entire series of pages, you don't know any of this as well as you might think.
A situation only exacerbated by how everything is handled easily making people write two to ten times the code they should need; not counting a few basic minor copypasta helper functions or the size of the client-side framework/scripting (react.js, react-dom.js, etc) against it.