RE: *****SPAM***** RE: Inactive buttons, contrast and accessibility

Hi Adam,

I am a screen reader user too and I agree that user testing often would be needed.

But before user testing, let’s first think through:

Is aria-errormessage already supported sufficiently? Hopefully, it improves.

Then let’s go to visual design:
I’d assume the following user expectation:
A standard component like *Submit* doesn’t change its visual appearance in the process of filling out a form. 
(A screen reader would not announce visual change or tabindex=-1 without verbose workaround anyway.)
Don’t make me think about the change of the contrast of a standard component but tell me what to do!

We are talking about a small form with two input fields and a submit button. 
For me as a screen reader user an error hint in a dialog or live region with a correct focus management would fit.

Wolfgang

-----Original Message-----
From: Adam Cooper <cooperad@bigpond.com> 
Sent: Thursday, April 25, 2024 2:23 AM
To: 'Ginger Claassen' <ginger.claassen@gmx.de>; 'ML W3C, WAI' <w3c-wai-ig@w3.org>
Subject: *****SPAM***** 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 18:24:12 UTC