- From: Adam Cooper <cooperad@bigpond.com>
- Date: Thu, 25 Apr 2024 12:48:40 +1000
- To: "'Benjamin Love'" <benjamin.james.love@gmail.com>
- Cc: "'Ginger Claassen'" <ginger.claassen@gmx.de>, "'ML W3C, WAI'" <w3c-wai-ig@w3.org>
- Message-ID: <001d01da96bb$147da400$3d78ec00$@bigpond.com>
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 <mailto: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 <mailto:ginger.claassen@gmx.de> > Sent: Wednesday, April 24, 2024 5:53 PM To: ML W3C, WAI <w3c-wai-ig@w3.org <mailto: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
Received on Thursday, 25 April 2024 02:48:48 UTC