aria-valid-attr-value WCAG mapping

[lilzesh]

Product

axe-core

Question

I was testing some pages recently which made me wonder about the aria-valid-attr-value rule and why it maps exclusively to 4.1.2. I understand that ARIA attributes like aria-label and aria-labelledby certainly have direct 4.1.2 implications but there are other attributes handled by the check of this rule that do not seem to fit with the 4.1.2 tagging (e.g. aria-controls, aria-describedby, among others). Invalid values for some of these other attributes, to me, would align more appropriately with 1.3.1 as it is likely that we would be dealing with some sort of information or relationship expressed visually that cannot be programmatically determined. With some of these other attributes we wouldn't be dealing with the programmatic determinability of name and role, and some are not settable by a user.

I wonder if it makes sense to separate this rule and check into attributes whose invalid values are 4.1.2 violations and others that are 1.3.1 violations? Both likely still make sense tagged as needs review. Also, if this type of discussion has occurred in the past and what may be limiting factors of my argument as I acknowledge I'm lacking a lot of historical background.

[lilzesh]

I do find the defintion of name, in the context of the normative text of 4.1.2 curious. To me this implies that name is actually a superset that contains not only accessible name but any text that helps identify a component, which very well could be a description. Perhaps this is a reason something like aria-describedby might sneak into 4.1.2.

[WilcoFiers]

That's a good question. Most attributes that can fail aria-valid-attr-value are related to 4.1.2. aria-describedby for example can never fail it. It's okay for that to be empty, it's okay for that to have non-existing IDs... axe cannot confidently fail anything about that. The same is true for other attributes that use IDs (DREFS properties).

The scope of 4.1.2 isn't attribute related, it's related to what type of element its on. An invalid ARIA property on a button always falls under 4.1.2. We could in theory split all of those rules up to have elements on interactive roles mapped to 4.1.2 and elements on non-interactive roles to 1.3.1. That's gets us a little closer to a "correct" mapping. But it isn't going to be perfect either. For separators you can't just look at the role. In interactive separator is different from a static one for instance. Elements may be interactive without having the correct role, so maybe you include those? But then you end up with too many elements, so maybe you look at other properties to try and guess the intended role. Etc. We can endlessly tweak an algorithm like that and never get it right.

That's why generally we opt for keeping things predictable. We did a similar thing with impact. Until fairly recently axe would sometimes report the issue of a rule as critical, and other times as serious, depending on the situation. That kind of worked, but its far from accurate. We made a best effort based on what the architecture of axe allows us to. But people kept asking why its sometimes critical and other times serious, and assuming axe did something much smarter than what it actually does. The little bit this made axe better wasn't worth the extra confusion this created for people trying to understand the results.

[lilzesh]

An invalid ARIA property on a button always falls under 4.1.2.

Could you elaborate on this for me? I am paraphrasing but 4.1.2 has three qualifiers, i.e., that all user interface components...

1. have a programmatically determinable name and role, and
2. states, properties, and values that can be set by the user, can be programmatically set, and
3. changes to these items are made available to user agents

As much as I want authors (developers) to supply states and properties with valid values, the normative text doesn't appear to require valid values. The intent of the authors (writers of this Success Criterion) very well may have been that but all that seems to be required is that if a user can set them, they can be programmatically set.

This was really the foundation of my concern, i.e., that 4.1.2 doesn't actually require valid states and properties on user interface components. I agree, failures come with providing states and properties with invalid values, but in my mind those are likely to fall under something like 1.3.1, because there is likely some visual information or relationship expressed that isn't programmatically determinable.

Apologies, I feel myself driving this conversation more into the realm of the interpreting normative text instead of sticking to axe-core specifically. I agree, even if we both agreed that this rule/check should be split it is very plausible that the juice is not worth the squeeze.

I appreciate the thoughtful response @WilcoFiers. Cheers.