Re: Inactive buttons, contrast and accessibility

I think you’re missing the point of my claims and recommendations.

My first comment was regarding visually styled “disabled” via CSS, which is
often implemented using reduced contrast, which negatively impacts users
like myself who have a difficult time identifying that presentation method.

I would also say that MDN has very thorough documentation for web
programmers and their particular approach does a reasonably effective job
of inviting (rather than excluding) audiences who may have less technical
training or experience. But that is my opinion (as I stated prior to
sharing the resource).

And yes, end-user research is fundamental to asserting any solution,
whether micro or macro. Your opinions alone (like my own) should never be
treated as capital “T” truth (quote unquote universally accepted as
normative, proper, necessary). Always challenge what is given. Respect
those who got us here. And promote those who will get us further.

Regarding your 3rd paragraph, I am not aware of commonplace web-form design
to only present fields (especially required fields) only after user inputs
a value. I wouldn’t agree with that approach at all and it would break with
recommendations for optimization to ensure user understands full process of
a user input scenario. Or maybe I am not aware of the particular experience
you are referencing. “Particular” only meaning I am not aware not that it
isn’t true or systemic.

As for final paragraph, sure, a “simple” form (I.e., a set of controls that
we assume general audiences would understand the operational and validation
logic… but our objective here is to provide the most users with reasonable
access. Y that would be akin to me authoring an article on fundamentals of
HTML and a somewhat experienced user becoming frustrated because I am
explaining the purpose of element attributes. But the article is on
fundamentals of HTML, for a generalized audience who we as authors assume
do not understand what an attribute even means in programming.

But I also feel this discourse / discord (potentially) is not “helping” the
inquirer.

Ben

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

> So where is the evidence for inactive controls being ‘neither necessary
> nor recommended’ (I’d hardly cite MDN as a repository of trusted user
> research).
>
>
>
> Plenty of randos on the web asserting a preference, but it’d be good to
> see some well conducted user research or input from experienced usability
> specialists.
>
>
>
> One further pattern which is common these days is to present a username
> field and then when that is validated present a password field a la Google
> … errors at the top of a view for this would likely be overkill.
>
> And I question the need for visible required indicators for a two field
> login form …
>
>
>
>
>
>
>
>
>
> *From:* Benjamin Love <benjamin.james.love@gmail.com>
> *Sent:* Thursday, April 25, 2024 11:20 AM
> *To:* Adam Cooper <cooperad@bigpond.com>
> *Cc:* Ginger Claassen <ginger.claassen@gmx.de>; ML W3C, WAI <
> w3c-wai-ig@w3.org>
> *Subject:* 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
>
>
>