More impactful duplicate ID check option

[dylanb]

Duplicate IDs are only an accessibility issue under two conditions:

1. The item is an interactive element - in this case, the duplicate ID could cause assistive technology (such as Dragon) to target the incorrect item, resulting in potentially irreversible adverse actions, or
2. The item is referenced through one of the ID reference techniques. In this case, the wrong element could be referenced

Change the duplicate ID test, to have an option that will cause it to only report on interactive elements (testing the entire DOM to see whether there are references to an element is too slow)

[dylanb]

Test for reference could be done through document.querySelectorAll on:

1. [aria-describedby=id]
2. [aria-labelledby=id]
3. [header=id]
4. [aria-owns=id]
5. [aria-controls=id]
6. [aria-activedescendent=id]
7. [aria-flowto=id]

[marcysutton]

Rather than creating separate rules, we talked about using the data object in the check to provide additional data for severity. We'd have to make a change in axe-core to update the impact based on that data object.

[dylanb]

When we bury the information in the check or in the data, it makes it difficult for users to figure out what is going on whereas a different rule gives us a prominent help message with-which to communicate. For this reason, we decided a while back to separate out rules rather than embedding different failures into a single rule.

Additionally, we can turn complete rules off and on, whereas issues buried in data cannot be turned off and on.

There is an art to this, but my vote would be to separate these out into separate rules for both of those reasons.

[marcysutton]

It's a trade-off–users might also be confused as to why there are multiple multiple-ID rules. I think we'll have to play with it to see what works best.