0

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".

Sarah
  • 1

1 Answers1

0

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.

brennanyoung
  • 6,243
  • 3
  • 26
  • 44