Axe-core: Consistency when enabling/disabling best practice rules

[WilcoFiers]

The "tabindex greater than 0" rule is a best-practice and so it shouldn't run in the axe-extension default. Reported by Dave Musser.

[dylanb]

All best practices are on by default

[WilcoFiers]

In that case we have a few other issues :P

Disabled by default:

1. skip-link
2. region
3. label-title-only
4. href-no-hash
5. heading-order

Enabled by default:

1. checkboxgroup
2. empty-heading
3. frame-title-unique
4. image-redundant-alt
5. meta-viewport-large
6. radiogroup
7. scope-attr-valid
8. tabindex
9. table-duplicate-name

[WilcoFiers]

@dylanb @marcysutton I think we can turn these rules back on, but we should make a few changes:

• I think href-no-hash should just go away. I don't see why this is a best practice. There is also the case of things like <a href="#">Back to top</a> which is a false positive for this rule.

• Additionally, I think we can improve skip-link (and justify it being on by default) if it only checked that if there was a skip-link, it had an focusable target. It shouldn't fail if there isn't a skiplink. That also addresses an issue discussed here: https://github.com/GoogleChrome/lighthouse/issues/3409

[dylanb]

the href-no-hash rule has mutated from what used to be a useful rule - which looked for anchors that did not have an href at all (non-semantic use of anchor) to this one. The intent of non-semantic use of anchor is that often these are used to create clickable items that are then not keyboard accessible due to the lack of the href. Perhaps we could bring back that rule as a review item?

I agree on the skip-link rule change suggestion

[WilcoFiers]

I don't see how a rule that looks for with no href is useful. Those things are still valid. They're often used in place of elements with id attributes. The problem isn't with the <a>, it's that there is an element that can't get focused, even though it should. We're working on a different rule for that: https://github.com/dequelabs/axe-core/issues/528

[marcysutton]

We should talk about how this impacts attest-devtools. We have an option in there to enable Best Practices, but it makes little sense when many of these are already enabled. cc @downzer0

[dylanb]

@marcysutton attest-devtools default is to disable all best-practices which is why that also has the checkbox

[downzer0]

To add to this for some context, one of our customers is using a custom ruleset but the checkboxgroup (a best practice that is specifically disabled) fires in iframes (and only in iframes). It seems there is an issue with custom rules not being respected within frames.