You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<imgsrc="snowstorm.jpg"
alt="street in a snowstorm" aria-details="snowstorm-desc"><detailsid="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.
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:
If the feature's use is supported by all platforms: allow, else
If the feature's use does not have a negative impact on accessibility: allow, else
If we can detect a fallback: allow, else
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).
The text was updated successfully, but these errors were encountered:
@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.
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):
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.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: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).
The text was updated successfully, but these errors were encountered: