[feature request] Ability to target an element in the DOM

[dwavid]

trafficstars

I love the power that Accessibility Insights gives me, but I'd love to be able to target a specific element in the DOM. It seems to currently target everything within the DOM. If I could either give it an ID, class name, or point-and-click, that would be amazing. It would declutter the test results.

[msft-github-bot]

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]

thanks for the feature request @dwavid! we agree this would be an interesting feature and started looking into it a while ago, but there are some fit and finish elements that require some work.

We are leaving this feature as needs investigation to allow the community to up-vote if this is something they would like to have in Accessibility Insights for Web.

Also, for tracking purposes, listing below the list of elements we would need to address:

• add highlighter to the element selected
• small UI changes in the panel
• think about:
  • how does users know they have scoping on?
  • how is scoping shown in the report?
  • does it work with persistence?
  • where is the scoping button located in the UI?

[msft-github-bot]

This issue requires additional investigation by the Accessibility Insights team. When the issue is ready to be triaged again, we will update the issue with the investigation result and add "status: ready for triage". Thank you for contributing to Accessibility Insights!

[ssawczyn]

Recognizing the challenges and considerations already outlined by @ferBonnin I think this would be a fantastic feature. Sometimes, I just need to assess a form or a widget and when the recipient sees unrelated results, they are apt to disregard everything as irrelevant.

One suggestion might be to change the UI such that the tester can manually specify a specific path or ID, this could appear somewhere near where the target page is already present. Admittedly this wouldn't be as cool as some sort of selector, but I think it would be a lot less work to implement this alternative, and since the user would manually have to paste the path or ID, there would not likely be confusion around whether a specific area is targeted or not. If multiple areas on a page are needing to be assessed, each would require its own assessment: this makes it consistent with each page, or possibly state, already requiring its own assessment.

[Gcamara14]

Hi All,

Are there any updates on this ticket? I know the IBM accessibility checker has this tool and so does deque. Maybe teams can look at the way IBM's implemented something like this.

[DaveTryon]

Unfortunately, this is out of scope given our current priorities.

Thanks for using Accessibility Insights!