Color contrast [afw4f7, 09o5cg] should not apply to aria-disabled non-link a elements

[Jym77]

Text has minimum contrast and the similar "enhanced contrast" rule has exceptions to Applicability for "inheriting semantic group or widget that is disabled".

I've seen an actual page, part of a dictionary with links for each letter, looking like:

<a href="a.html" class="good-contrast">A</a>
…
<a class="bad-contrast" aria-disabled="true">X</a>
…

because there is no entry starting with "X" in that dictionary.

Now, the "X" text has bad contrast, it has an aria-disabled ancestor, which is matching our disabled definition (second condition: The element has a shadow-including ancestor whose aria-disabled attribute value is “true”.)

But, since the <a> element has no href attribute, it is no a link: HTML AAM, thus not a widget, and its text is excluded from the exception, i.e. applicable to the rule which flags it as bad contrast.

---

I think that in a case like that, the text should be part of the exception. It is, pretty much, "part of an inactive user interface component" to put it in WCAG terms.

I think we should be a bit conservative and only extend the exception to "a and area elements with no href and aria-disabled="true"", rather than, say, to anything with aria-disabled="true".

[WilcoFiers]

Talked this over iN CG. i think we came to two conclusions:

1. Yes, the rule should consider any element with aria-disabled=true as disabling its comment, not just on groups and widgets
2. We should add something to the background that suggests that the common pattern of removing href from an achor as a method of making it "inactive" is insufficient to indicate a link is disabled, since removing the href removes the link's semantics. Links, including inactive links must have a link role as per 4.1.2.

[tombrunet]

Adding the clarification: An a element without an href attribute by HTML and ARIA specs is not a link. It's a jump target and has no role, it's just text. You could replace the a with a span and there would be no semantic difference since the element was not give a name to be a jump target.

[dan-tripp-siteimprove]

Some notes on what I said during the meeting:

• ARIA 1.2 says about aria-disabled: "This state is being deprecated as a global state in ARIA 1.2. In future versions it will only be allowed on roles where it is specifically supported."
• We have the ACT rule "ARIA state or property is permitted" which seems to me it should fail <a aria-disabled="true">x</a>. Today I tested that with the free browser extensions for alfa, axe, and IBM Equal Access. None of them failed it. Maybe the situation is that the tool implementations haven't yet implemented ARIA 1.2's idea about aria-disabled.
• I see customer examples like Jean-Yves' about once per month. They're always either a dictionary or a calendar. They never have aria-disabled="true" already. I have been recommending to those customers that they add aria-disabled="true" and href="javascript:void(0);". I might change that recommendation to aria-disabled="true" and role="link".
• Wilco's "two conclusions" above roughly make sense to me if we implement either one or the other. Not both. It's unclear to me if they are "conclusions" or "options".

[dan-tripp-siteimprove]

It seems to me that Wilco's conclusion 1 says "fix the rule" and conclusion 2 says "fix the code". These seem like mutually exclusive options to me.

[Jym77]

CG discussion: we've also spotted that the last assumption/definition of "disabled" gets a bit wonky (notably Inapplicable Example 9 doesn't match this assumption).

Decision:

• Update the definition of "disabled" to replace "has been rendered inoperable by disabled or aria-disabled" by "has been rendered inoperable and has either disabled or aria-disabled". This makes the definition subjective (big change). But then, Inapplicable Example 9 becomes Applicable (and Failing) because the input has not "been rendered inoperable"; and Inapplicable Example 11 becomes cleaner because it is both inoperable and aria-disabled, but with no links between them. The last assumption becomes useless and can be removed.
• We agreed that removing the href attribute from an a element is not the good way to disable it because it then loses its role of link which becomes a failure of 4.1.2 or 1.3.1 (fight incoming!) We want to add a Background note explaining this, as well as the "good" solution (also add role="link" since it is not anymore the implicit role) + probably add an example for it. We can't really add the motivating case of this issue as a Failed Example (because it is not really a 1.4.3 error, more a 1.3.1/4.1.2 one and implementation that would flag it that way would incorrectly be "punished"); we can however have a Passed Example which shows our recommended solution for this kind of cases.