Is there a way to add an exception to Accessibility Insights so that elements with a specific attribute are allowed to break a specific rule?

Question

We are using a package that breaks the "aria-hidden-focus" rule because an element with "aria-hidden" is focusable. I reached out to the package owners and they said this is on purpose because elements with data-tabster-dummy attribute are intentionally focusable with aria-hidden. Their only purpose is to redirect the focus to the proper element immediately after they receive focus. If they don't have aria-hidden, the screen readers will choke starting to announce them.

As a result, our app is failing Accessibility Insights fast pass test. We'd prefer if Accessibility insights would ignore this issue so that it doesn't keep flagging it.

I've taken a look at Accessibility Insight's documentation but haven't been able to find any information yet about if they allow exceptions. Ideally we'd like to contribute to the Accessibility Insights repo and add something that says "if an element has the data-tabster-dummy attribute and it breaks the aria-hidden rule, don't flag it as an issue".

Answer 1

OK, I asked around a little about this. The redoubtable Scott O'Hara had this piece of wisdom to offer:

automated checkers failing code doesn’t really matter if the code - while “invalid” - was written specifically to improve accessibility when it is used

So, apart from reporting the issue against Accessibility Insights, I don't think there's anything to do except tolerate these well-intentioned but false positives.

Answer 2

I very specifically did not say "false positive" in the thread where my quote is pulled from - as it's important to note that just about any automated check could produce a false positive for instances of invalid code which is purposefully and carefully breaking best practices for very specific reasons.

Regarding this rule that's being referenced, 99.x% of what the rule is meant to cover are actual accessibility issues that can have serious impact on a user's ability to access content.

But here, we have an instance of someone knowingly breaking that rule very carefully and for very specific reasons that I really don't want to have to write a blog post about to explain... rather the point is that weeding this edge case out would be very difficult to consistently and accurately do, as there is no standardized way to implement focus bumpers (outside of an element is focusable but also javascript immediately moves that focus to another element to restrict focus to the descendants of the necessary element).