RE: Inactive buttons, contrast and accessibility

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

Received on Thursday, 25 April 2024 00:22:42 UTC