Violation overlay

[raunofreiberg]

Events

Instead of modifying the styles of the node in violation (à la adding a border), I thought it would be nice to add an overlay on top to draw more attention.

Currently, this is done by adding an extra DOM node into document.body, having it observe the target node's position, and update accordingly. This has a drawback of hijacking any clicks that may happen on the target node since the overlay appears on top. This can (?) be a problem. Maybe we should just modify the styles of the target node instead?

Popover

To show the violations, a popover appears on hover. A few things to think about here:

1) How would a user click on the link inside the popover? Should we instead open on click instead? 2) If we open on click, then should we prevent any clicks from happening on the node in violation?

[raunofreiberg]

Regarding events — maybe an option would be to have a keyboard shortcut that could be used to toggle the overlays on/off? This way you can turn the overlays off, interact with the app as needed, and whenever ready, turn them back on.

[raunofreiberg]

Regarding the Popover — I've decided to replace open on hover with open on mouse down in https://github.com/raunofreiberg/axe-mode/commit/4c81675a6981f4c2799810004b1b02737e5c85d4:

Should be a neater experience all around ✌️

[chaance]

A few thoughts and questions about the overlay:

• Have you given much thought to dismissal in the event of a false positive? I haven't reviewed the code too deeply yet, but I'm curious how we might identify an element as safe. Some sort of allow-list perhaps?

• Since we're triggering on click, is there any reason we can't use a dialog to make the popovers accessible? I can't see any reason to have multiple on screen at a time. It would probably simplify keyboard navigation a great deal as well. Did you try this approach and run into some limitations there?

• I think using a mouse/click event is the right move here. 👍

• Since we're appending the overlay triggers to the end of the document, keyboard navigators would need to tab through everything on the screen to access the trigger nodes. It'd be nice to have some sort of mechanism to jump to the violations from the beginning, perhaps similar to @reach/skip-nav.

[raunofreiberg]

Have you given much thought to dismissal in the event of a false positive?

Could you elaborate? I don't know if we should start defining our own ruleset for this. I think this sort of thing is done by axe-core itself.

Also, from their readme 😅

It returns zero false positives (bugs notwithstanding).

Since we're triggering on click, is there any reason we can't use a dialog to make the popovers accessible?

I haven't given this any thought, but on first thought — a dialog would somewhat lose the context in which the information applies. E.g. switching between browser/code/docs to read the information and pin point the exact element without losing context. Also, right now it is possible to open a popover, then click on another element to trigger its popover — which makes for quite a fluid experience. Messing with opening/closing modals is less fluid in that sense, IMO.

I might be wrong though 🙃

Since we're appending the overlay triggers to the end of the document, keyboard navigators would need to tab through everything on the screen to access the trigger nodes.

Would it be possible to remove tab indices from the element in violation, and add keyboard navigation to the trigger nodes?

[raunofreiberg]

Closing this as there's no additional actionable items here besides the keyboard navigation which is tracked in #14!