I don't work on Chakra, I lead the team that builds Elastic's design library[0]. We take accessibility pretty seriously. In general this means: - We make sure

I don't work on Chakra, I lead the team that builds Elastic's design library[0]. We take accessibility pretty seriously. In general this means: - We make sure tab order and keyboard control is a equal level citizen. - All our colors and palettes are backed by math, both for contrast and for color blind qualitative comparison. - We build using semantic HTML and try to to avoid abstracting things like input controls and labels with too much magic. - We test and build for screen reader support at the component level and then provide helpers for navigation. Usually, given the complexity, this means a decent mix of native html, aria, and hidden text to make things read correctly. We do have some automated axe testing, but in all honesty, axes only gets the surface level spec and might cover 30% of what you need. The rest is really hand touched, backed by pretty strict review. In general the bigger frameworks like ours are getting better at this stuff, but it's still fairly poorly considered in the industry overall. The specs are pretty verbose and poorly standardized against browsers. This make it very much like building a traditional visual frontend during the browser wars of the 2000s (I was there!). Third party audits are normally done on the products themselves (in our case Kibana), not the framework itself. This ends up being an indirect method of auditing the framework though. All our work is open source and documented. If you have any questions, please ask away. I love this stuff and web UI has been a 20-year passion for me. [0]: https://elastic.github.io/eui/#/ https://elastic.github.io/eui/#/