Disabled button fails the contrast ratio test - should it?

[ricksbrown]

The default contrast ratio of disabled buttons (in Chrome and probably others) fails the low contrast tests.

I would argue that since the user does not / cannot interact with disabled elements they should be ignored for this (and perhaps other?) tests.

Another argument in favor of ignoring them is that if you style a disabled element to meet the contrast ratio audit then it will probably lose the disabled look and harm usability.

[jdan]

@alice This is sort of related to what you were saying about placeholder text recently. Might be a good question for the web-a11y slack channel if you haven't already asked!

[stevefaulkner]

"Text or images of text that are part of an inactive user interface component" are exempt from color contrast requirements.
http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html

[alice]

Thanks @stevefaulkner!

@ricksbrown do you think it would work to just check for the disabled attribute in the audit rule? I'd be tempted to make this part of the relevantElementMatcher, even.

[ricksbrown]

@stevefaulkner thanks

@alice Yep I think this will be pretty straightforward (I always think that before spending hours on one tiny little problem).

The complicating factors to consider would be:

• aria-disabled Should we also ignore ARIA widgets that are aria-disabled (yes - I think Steve's answer applies to that too).
• Disabled ancestor - aria-disabled is global and could be on anything - what effect would that have to descendent components? Also fieldset can be disabled in HTML - what effect would that have.

[alice]

• Totally makes sense to ignore aria-disabled on the current element
• Yep, need to walk up the tree in case aria-disabled is set higher up: "The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied." http://www.w3.org/TR/wai-aria/states_and_properties#aria-disabled
• fieldset is a spanner in the works! Doesn't look like the disabled property (as opposed to attribute) is exposed on the elements which are disabled by being in a disabled fieldset. So we'll need to be somewhat subtle about that - if it's an <input> and one of its ancestors is a <fieldset disabled> then we ignore it. Ugh I hate having to recreate browser logic.

[ricksbrown]

OK I'm happy to run with this (unless anyone else wants to).
@alice your temptation to put this in the relevantElementMatcher makes perfect sense - the result of the audit should be NA not PASS for disabled elements.

[alice]

@ricksbrown works for me, go ahead and take it :)