Greyed out submit buttons (conditional upon successful form completion)

[DavidMacDonald]

I think we need a position on submit buttons that remain inactive until the user successfully completes the form.

It is typically greyed out below the contrast standards, and is not tabbable until all fields have been sufficiently completed and has the html5 disabled attribute. Typically there are errors messages on the fields of the form that trigger when the user leaves the field if incorrectly filled in.

There are a number of positions I've heard... what's ours?

[meesrutten]

You could add an :invalid selector on the form element and style the button from there:

https://developer.mozilla.org/en-US/docs/Web/CSS/:invalid

This does not really do anything for people using screen readers or other assistive technology, if I'm correct. But this does enable you to set pointer-events or the background color.

[mraccess77]

HI @DavidMacDonald this is something we brought up in WCAG 2.1 many times but it was deferred as part of the bigger issue -- I'd also like to see progress on this issue.

Separate but related -- I've also seen situations such as the Alarm screen on Apple Watch where the alarms are inactive and grayed out -- yet they are not disabled - the control is still interactive -- it's just not switched on -- so it's grayed out and difficult to see. This raises issue with the word "inactive" and what it really means.

Another similar issue is a readonly/disabled field used to verify credit card number stored on file. This field is marked with disabled attribute because you can't change it -- but you have to be able to see the numbers to verify the credit card. In this case the input is disabled but the content's of the field are meant to be seen. So we need a better way to define when the content must still be sufficient in contrast. That is -- it's not the operability -- but the availability of the information.

[tremby]

In this case the input is disabled but the content's of the field are meant to be seen. So we need a better way to define when the content must still be sufficient in contrast.

Isn't the readonly attribute good for that purpose?

[mraccess77]

@tremby Yes, readonly by itself is good for that as it also allows for selection of text. But I've seen cases where it's marked readonly and disabled.

[tremby]

@mraccess77 hm, perhaps to stop it from submitting with the rest of the form.

[JAWS-test]

Regarding the submit button, I think:

• According to WCAG there is no contrast requirement for disabled elements (excluded e.g. in SC 1.4.3)
• According to WCAG, there is no requirement that deactivated items should receive the focus.
• According to WCAG there is a requirement that error messages are perceptible (SC 3.3.1, 3.3.3) and that input instructions are available (SC 3.3.2, 3.3.5). Thus a user should be able to perceive why the submit button is deactivated and therefore not visible and not accessible with the keyboard.

I find the WCAG SC sufficient at this point.

However, there are cases of deactivated elements that should be visible and therefore require sufficient contrasts, e.g. when checking form field entries.

At this point, I think the WCAG exception for disabled elements regarding contrasts is wrong. I suggest that we explain in the Understanding document when deactivated elements require sufficient contrasts or that in some cases non-disabled elements should be used. With WCAG 3.0, the exception should be dropped or formulated more precisely. My suggestion was: "Incidental: Content that is part of an inactive user interface component (unless this component transmits information), that is pure decoration, that is not visible to anyone, or that is part of a picture that contains significant other visual content, has no contrast requirement." (#901)

[jake-abma]

until now (based on 2.1 discussions) our point of view was we couldn't fix it as it serves (at least) 2 groups, low vision who need it Vs. aesthetic / design / coga reasons to make clear it's disabled.

Postponed till Silver (as with all things we didn't agree on yet... :-) ) was the last call

[alastc]

For the contrast aspect I think Jake summarised it, but I'm not sure if the question is about contrast, what it conveys to AT, or wanting to have a position (paper) on this interface approach in general?