Re: Inactive buttons, contrast and accessibility

Visually disabled controls and/or functional elements (buttons) are neither
necessary nor recommended (for contrast requirements you noted, when
contrast is method of denoting “disabled”). I accept this design choice as
a hold over when we designers/developers were left to our individual
creativity rather than well researched and tested approaches.

Ensuring there’s a visually present and programmatically readable
“required” labeling on required form controls is step one. Required
attributes as well.

Step two, as mentioned already, is ensuring that an on click of the submit
element (or any functional element that requires user complete an input
prior to event) checks that all information is entered and valid. If it is
not, notification to end user that required inputs have not been made with
instructions for input value, without overburdening the user
informationally.

There are a lot of online programming focused resources to aid
developers/designers. I like MDN. Here’s a starting resource. Check out
quick overview of “required” attribute on form elements:
https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation

Hope that helps.



On Wed, Apr 24, 2024 at 5:28 PM Adam Cooper <cooperad@bigpond.com> wrote:

> How about actually asking people who use a screen reader about their
> experience?
>
> Or even do some A/B usability testing with people to see which pattern
> works?
>
> An inactive button on a login form is probably a common enough pattern on
> the web especially if inline error handling is done properly (e.g.:
> aria-errormessage etc.)
>
> People who use screen readers are no more or less aware of how the web
> works than people who don't use a screen reader
>
> No need for dialogs or tooltips or live regions or any other over thinking
> it
>
> The contrast of the inactive button is a gap in WCAG 2.x and hopefully
> will be resolved in later versions so feel free to override the default CSS
>
> while a button that is inactive might be removed from the tab order, it is
> still navigable using cursor key navigation and quick keys with a screen
> reader.
>
> I'm guessing it might be possible to override the tab order behaviour
> using tabindex="0" if you really want to, but I'd test this in a range of
> user agent combos and devices etc. before implementing it
>
>
>
> -----Original Message-----
> From: Ginger Claassen <ginger.claassen@gmx.de>
> Sent: Wednesday, April 24, 2024 5:53 PM
> To: ML W3C, WAI <w3c-wai-ig@w3.org>
> Subject: Inactive buttons, contrast and accessibility
>
> Good Morning everybody,
>
>
> We have a rather difficult issue in a web portal.
>
> There is a login form and the question is now what to do about the submit
> button if one of the fields user name or password has not been filled.
>
> Do we make the button inactive i.e. contrast does not meet WCAG and remove
> it from tab-order or do we keep it in tab-order and provide a tool tip why
> it is inactive and what to do about the contrast in the latter case?
>
> Sighted users would think the button is an interactive element if we
> fulfill contrast requirements.
>
>
> I am looking forward for some helpful input here!
>
>
> Thanks and solong
>
>
>      Ginger
>
>
>
>