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.