Issue with aria-required-children validation fix messaging

[awkawk]

Product

axe-core

Product Version

4.10.3

Latest Version

• [x] I have tested the issue with the latest version of the product

Issue Description

Actual

Getting an issue flagged with a test of a menu component. This is what appears in the DOM:

<ul id="optmenu" role="menu">
        <li tabindex="-1" role="presentation">
              <a role="menuitem"><i class="icon-save" aria-hidden="true"></i>Save &amp; Exit</a>
       </li>

Note that the immediate child of the ul with role=”menu” is an li with role=”presentation”. This node would ordinarily be ignored, but it also (incorrectly) has tabindex=”-1” so the validation is regarding it as not presentational. The issue that is raised provides this “how to fix”:

Element has children which are not allowed: [role=presentation]

This is misleading as to the actual fix. If we were able to indicate that the issue was not that the role=”presentation” marked element wasn’t allowed but that that element couldn’t be tabbable that would make more sense and support a fix more clearly.

The opposite issue is similarly affected, as on this same page as the element within the li with role=”presentation” gets flagged for a aria-required-parent issue and the “how to fix” says:

Required ARIA parents role not present: menu, menubar, group

How to Reproduce

Take any good menu component and add tabindex="-1" to an element between the element with role="menu" and the element with role="menuitem".

[straker]

Thanks for the issue. Normally the rule presentational-role-conflict would flags the issue with tabindex=-1 and role=presentation so we don't need to put the same message into other rules. However I just realized that that rule is marked as a best-practice rule, so if your not running best-practice rules you'd never see the rule tell you why those elements are not presentation.

[awkawk]

Got it, thanks. I wasn't running the BP rules, so didn't see it.

However, it seems odd that the same problematic code results in a best practice issue AND a critical issue. If it is critical, it seems like clearer messaging about how to address the issue in the critical issue content would be warranted.

[straker]

That's a good point. I'll start discussions on the team about how we may want to handle this information directly in the rule it affects rather than relying on presentational-role-conflict.