feat: improve keyboard navigation of overlays

[raunofreiberg]

Trivial keyboard support for interacting with overlays.

I'm not sure how to properly define the order of elements in keyboard navigation. Currently, every overlay gets a tabindex of 0 so the sequence will be based on the order of the violations that axe gives us, not the elements themselves.

@chancestrickland maybe you have some ideas here?

[chaance]

I think this is an area we might want to solicit feedback from the community. Here are two approaches that I think could work pretty well:

• We have a visually hidden link similar to a skip nav link at the very top of the DOM tree that says something like "In development mode, click here to navigate to accessibility warnings", and then from there all warning triggers are tabbable in natural DOM order. This could be a lot simpler to implement if warnings are grouped in a portal in a separate root. It might also be a nicer experience because users could decide whether they want to traverse the site normally or concern themselves with our warnings (they may be working on a big feature that triggers warnings but not be quite ready to deal with them yet).
• Warning triggers are tabbable directly after the element that triggers the warning. This could actually be annoying IMO, but others may find this more natural (or at least philosophically closer to the experience of a mouse user). It could get weird to implement.

I'm going to pull this down and spin it up later today, just wanted to get some initial thoughts written down in the mean time.

[raunofreiberg]

@chancestrickland any additional thoughts on this? A nav skip link sounds like the natural choice for me, so I'd go with that!