Improve shadow DOM support (visualizations & tab stops automation)

[karanbirsingh]

This issue tracks tasks that would holistically improve support of shadow DOM in Accessibility Insights. We are pretty close but have some small improvements to make.

I made a tracking issue because it feels like there could be other areas of the tool I'm forgetting. For example, any fixes should also check assessment behavior. Happy to restructure or break out as requested.

At the moment, everything below is related to open (not closed) shadow DOM support.

Current status

Automated checks supports open shadow DOM (see FAQ added in https://github.com/microsoft/accessibility-insights-web/issues/3768). We do not support closed Shadow DOM (expected). This is consistent with axe-core, which added native open shadow DOM support in v3.0.

Running automated checks on a webpage with open shadow elements results in a reasonable list of errors and automated report.

Improvements

Visualization

Accessibility Insights for Web does not draw highlight boxes around elements inside open shadow DOMs.

One example of this behavior for headings is here: https://github.com/microsoft/accessibility-insights-web/issues/5126 In this case, no highlight box is drawn at all.

axe-core provides a canonical way to find out whether a resulting node is in a shadow DOM:

If the item in the Array is an Array of strings, then it points to an element in a shadow DOM and each item (except the n-1th) in this array is a selector to a DOM element with a shadow DOM. The last element in the array points to the final shadow DOM node.

Our code (one example in https://github.com/microsoft/accessibility-insights-web/blob/20a946b8d4bbf8fe098c1dddbde1e4348c417d91/src/injected/visualization/highlight-box-drawer.ts#L16) does not leverage this fact.

If we run automated checks on an element inside shadow DOM, the shadow root is highlighted instead of the child element.

Tab stops automation

Testing tab stops on pages with open shadow DOMs can have unexpected effects (see details & proposed fix in https://github.com/microsoft/accessibility-insights-web/pull/5463#issuecomment-1122915346):

• Our tab-stop-listening code identifies the shadow root rather than a child node when focused. Therefore we produce many "keyboard trap" errors.
• I plan to merge the Tabbable update without opting in to shadow DOM support. We should opt into support separately and together with the other changes in this section.

Examples to test against

This CodePen is a modified version of shadow-doms.html Dan added in our repo.

other details

Version 2.32.0 Chrome Version 101.0.4951.54 (Official Build) (32-bit) Windows 19044.1645

[ghost]

This issue has been marked as ready for team triage; we will triage it in our weekly review and update the issue. Thank you for contributing to Accessibility Insights!

[ferBonnin]

@sfoslund should this be moved back into ready for work or did we address it all with #5728 ?

[sfoslund]

@ferBonnin no, it was not all addressed with #5728. I plan on addressing the rest of it next time I have slack time, but for now I'll mark as ready for work :)

[sfoslund]

Forgot to close on this when I merged https://github.com/microsoft/accessibility-insights-web/pull/6046, but that PR should wrap up the last of the work for this issue-- marking it as resolved

[ghost]

The team requires additional author feedback; please review their replies and update this issue accordingly. Thank you for contributing to Accessibility Insights!

[ghost]

This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for contributing to Accessibility Insights!