False positive: 'color-contrast' rule fails disabled control's label added using "aria-describedby" attribute

[adrianaferrugento]

Product

axe-core

Product Version

4.9.0

Latest Version

• [X] I have tested the issue with the latest version of the product

Issue Description

Same as 2090, but here the label is added using aria-describedby attribute

Per WCAG 1.4.3 the text that is part of an inactive user interface component do not have contrast requirement.

Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Expectation

'color-contrast' would not fail for labels related to disabled controls

Actual

'color-contrast' rule fails for a label( added using aria-describedby attribute) of a disabled control

How to Reproduce

[straker]

Thanks for the issue. From the screenshot I believe the issue is that the input element is not truly disabled. If you'd like to disable it you'll need to use disabled or aria-disabled=true, as data-disabled is not recognized by the browser as disabling the input.

[adrianaferrugento]

Hi @straker, thank you for the quick reply! Our textarea element does have disabled set on it and it still doesn't recognise the aria-describedby element as being part of that component.

[straker]

Gotcha. I see what you mean. I'll have to ask the team about what should happen in these cases. I'll let you know when I get an answer.

[adrianaferrugento]

Amazing, thank you!

[WilcoFiers]

I agree with @adrianaferrugento on this one. There's a very good chance that if a control is disabled, things related to that control are not intended to be used. Ignoring an element referenced with aria-describedby feels reasonable. I'd say aria-errormessage and aria-controls should get that treatment too.

I think we should consider going a step further than that even and try to identify the container group (fieldset, radiogroup, etc), if all controls in a group are disabled, all text in it can be skipped in contrast testing. Either that or we set it as needs review. We'll look at that when we get to fixing this.

[yuri-scarbaci-lenio]

Adding to this https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum

WCAG makes an explicit callout on disabled elements as incidentals and we are also affected by this

is this officially a false positive just for the sake of people coming in from google?

[dylanb]

the disabled attribute is invalid for use on a <div>

[yuri-scarbaci-lenio]

Oh you are 100% right, my bad and nice catch!

switching to aria-disabled instead properly fix the axe-core report

[dylanb]

You should probably add a role of some sort to the item in question so it is semantically marked up

[adrianaferrugento]

@dylanb Could I ask why you closed this issue? It still hasn't been fixed to my knowledge? My problem is with a textarea and the label that it's describing it and not a div

[yuri-scarbaci-lenio]

yep, will review this more in depth on my side ASAP, for now that text is properly announced by screen readers as it is linked via the input labelled-by constraint and there is an internal javascript also handling some edge-cases and such with announcement, it has been manually tested to be compliant (but ofcourse there is always space for improvements) and the concern was mainly axe-core reporting this as a violation during the static analysis (which was 100% on point and I will consider adding some more html analysis tools to detect html violation to the flow too to avoid issues as this in the future)

Once again thanks you for helping me identify this

[dylanb]

@adrianaferrugento sorry, it seems like there are two different issues with different source code getting mixed up here, will re-open

[adrianaferrugento]

No worries, thank you @dylanb!