E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Gote, Pooja
Date: Mon, Apr 19 2021 1:49AM
Subject: Conditional occurrence of Form CTA buttons
No previous message | Next message →

Hi Team,

I have a question regarding conditional occurrence of CTAs, be it for Desktop or Mobile. I had always preferred for actionable items to be available to the users at all times and just take the help of form validation to make sure all the required input is provided.
But I have been seeing implementations where the 'Submit', 'Save', 'Next' buttons are shown and if shown always, made 'Active' (and kept disabled at other tiems) in the design only when the required data is filled.

My approach - Keep the actionable item always available to the users and implement proper form validations and error correction mechanisms, instead of keeping the button conditionally hidden or disabled.

Could anyone provide advanced approach suggestions for such scenarios, if any? And thoughts on my approach above.
Would appreciate your guidance. Thanks!

Regards,
Pooja Gote
Digital Accessibility SME | Customer Experience (CX) | TIAA Digital
Mob: 90966-10050 | Ext. 348535 | = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

"Make Accessibility a Forethought, and not an Afterthought!!"

*************************************************************************
This e-mail may contain confidential or privileged information.
If you are not the intended recipient, please notify the sender immediately and then delete it.

TIAA
*************************************************************************

From: Mark Magennis
Date: Mon, Apr 19 2021 6:29AM
Subject: Re: [EXTERNAL] Conditional occurrence of Form CTA buttons
← Previous message | No next message

Hi Pooja,

There are different ways of making things hidden or disabled. I would say that if a button simply doesn't make sense when the UI is in a certain state then it may be okay to hide it completely, but it should be hidden both visually and to AT. A problem may occur if it's a button that the user expects to find though, such as Submit or Save. If it's just not there, it may appear as if something has gone wrong with the app. Having it there but disabled shows that it's available but just not at the moment which seems to be the logic you are describing. If that's logical then I don't see a problem with doing that. You might consider adding a description using aria-describedby to tell screen reader users why it is not available at the moment, if that is visually obvious but not obvious to screen reader users. If it's not visually obvious then your concerns are justified because it might be confusing or disconcerting.

How you disable it also makes a difference. To functionally disable it you can just block the Enter, Space, and mouse click events. But it will still be focusable while tabbing and won't be announced as disabled by a screen reader. To have it announced as disabled you can add either the HTML disabled attribute or the aria-disabled attribute. The HTML disabled attribute will remove it from the Tab order in most browsers so it won't receive focus while tabbing. Again, perhaps not what you want because it may appear that it's not there. Adding aria-disabled will leave it in the Tab order but it will be announced as disabled, so it is 'visible' to all but obviously not functioning right now.

Mark