Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Greyed out submit buttons (conditional upon successful form completion) #922

Open
DavidMacDonald opened this issue Oct 25, 2019 · 8 comments
Open

Comments

@DavidMacDonald
Copy link
Contributor

@DavidMacDonald DavidMacDonald commented Oct 25, 2019

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.

image

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

@meesrutten

This comment has been minimized.

Copy link

@meesrutten meesrutten commented Oct 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@mraccess77 mraccess77 commented Oct 25, 2019

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

This comment has been minimized.

Copy link

@tremby tremby commented Oct 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@mraccess77 mraccess77 commented Oct 25, 2019

@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

This comment has been minimized.

Copy link

@tremby tremby commented Oct 25, 2019

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

@JAWS-test

This comment has been minimized.

Copy link

@JAWS-test JAWS-test commented Oct 26, 2019

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

This comment has been minimized.

Copy link
Contributor

@jake-abma jake-abma commented Oct 28, 2019

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

This comment has been minimized.

Copy link
Contributor

@alastc alastc commented Nov 4, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.