Axe-core: aria-details shouldn't be reported as a critical violation

[rdeltour]

The aria-details attribute was introduced in ARIA 1.1 to identify an element that provides an extended description for an object.

An example to provide extended description for images (based on this live example from @marisademeglio):

<img src="snowstorm.jpg"
            alt="street in a snowstorm" aria-details="snowstorm-desc">
<details id="snowstorm-desc">
     <p>A snow-covered street lined by snow-covered cars and snow-covered branches. Two humans are at the end of the street. The street appears to have been recently plowed, but as it's snowing, there is already fresh accumulation.</p>
     <p>Although this description does not warrant the use of <code>aria-details</code>, that's what this test is about, so there you have it.</p>
</details>

Actual: Axe (v3.4.0) reports the presence of aria-details as a critical violation, as any other unknown or invalid ARIA attribute.

Expectation: I would expect the severity to be demoted, maybe not even reported at at all in the case where the attribute isn't harmful and can be used as a progressive enhancement technique.

Motivation: in most cases, the attribute isn‘t harmful, or has a decent natural fallback.

AT support for aria-details is not quite there yet. See an the testing done by Scott O'Hara in November 2018, which hasn't improved significantly as far as I know.

However, this seem to be a case of progressive enhancement, where the presence of aria-details is not harmful for the browser+AT combinations that do not support it, but can help a little when support is enabled.

• When the detailed description is visible and close to the described element in DOM order, then it is a natural fallback for the detailed description.
• When the detailed description is farther apart in the document, then authors can use text ("see details in section XXX below") or a hyperlink to refer to the details, as a fallback.

In any case, I think that aria-details shouldn’t be disallowed if we follow the decision tree in how Axe makes decisions on rules:

1. If the feature's use is supported by all platforms: allow, else
2. If the feature's use does not have a negative impact on accessibility: allow, else
3. If we can detect a fallback: allow, else
4. disallow the feature's use until it is supported

I don't think it has a negative impact on accessibility, so it should be allowed as per (2); or at least as per (3) if the details content is both visible and following the described element in document order (or is referenced with text or link).

[WilcoFiers]

You make a very good point :). We're going to change this and add it as a global attribute. Thank you Romain!

[jeankaplansky]

rule help revisions not required. Confirmed with @straker on 12/23/2019.

[padmavemulapati]

When tried , by adding aria-details attribute its giving the impact as "serious"

But when tried with the pass/fail scenarios from

https://github.com/dequelabs/axe-core/blob/develop/test/integration/rules/aria-allowed-attr/

, getting impact as "critical"

[straker]

@padmavemulapati the first issue you have highlighted is CSS media queries rule. The second issue is throwing because of the role=row and that you don't have any required children.

[padmavemulapati]

Yes, this clarification just wanted to know. Thank you