Focus on accesibility?

[robinmetral]

Hi! Just stumbled on the library, and I'm wondering what you mean by "focus on accessibility" on the README. I was interested in how you were handling some complex UI patterns in terms of a11y, but couldn't find anything in the docs about it.

For example, I looked at the notifications package, since toasts are notoriously hard to get right, a11y-wise. Unfortunately it looks like the package isn't using live regions at all, which means that these notifications are completely inaccessible for screen reader users at the moment—which is even more of a problem if it requires user input (cf. the example you have for an email input inside a toast).

Beyond possibly addressing these issues for the notifications, could we consider adding explicit a11y documentation, to show what is actually being considered in terms of a11y? I'd love to see, for example, which components/patterns are WCAG compliant out of the box; which require extra implementation from developers, and so on.

Thanks again for your work on the library though, so far DX looks really well thought through 💯

[rtivital]

Hi @robinmetral, I've not updated README for a while and some things have changed since the launch on first version. About 6 months ago, I've tested all components with screen reader but stopped doing so to focus on other features, so I guess I should remove that from README to not confuse anyone. Our current approach to development includes testing with jest-axe and making sure that keyboard events work as in WAI ARIA recommendations. Unfortunately, I do not have much time to test components with screen reader right now, but we are always open to contributions that can improve accessibility.