WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Whether or not to disable form submitbutton

for

From: tim.harshbarger@deque.com
Date: Dec 18, 2023 6:13AM

Yes. However, this does not mean you should automatically use ARIA. Take the required state for example.. There are non-ARIA ways to indicate that. You could make the required indicator (perhaps an *, the word "required", or an image with alt text) part of the accessible name of the element. If you are using a native HTML element that is interactive, you might use the required keyword.

I do want to note something about the disabled state just in case no one has mentioned this. Screen reader users can still access controls in a disabled state even if they are not part of the tab order. Unlike people who can see but may only use the keyboard to interact with a system, a screen reader does allow the user to access all non-interactive elements that are visible on the screen. There are a few exceptions where a screen reader user might not be able to access content that is visible, but just using the disabled keyword on an element won't accomplish that alone.

Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

re: the required state is not clearly indicated, there's an awesome discussion on github

Request for clarification: does Name, Role, Value include static states like "required"? #3523
https://github.com/w3c/wcag/issues/3523

On 12/18/23, Geethavani.Shamanna < <EMAIL REMOVED> > wrote:
> There are two scenarios that I have come across with regard to
> disabled
> buttons:
> 1. The disabled button is accessible to mouse users, but is not
> keyboard focusable, not in the tab order and not accessible to screen reader users.
> 2. The disabled button is keyboard-focusable and is in the tab order,
> but not accessible to screen reader users. In this instance we
> recommend the use of the aria-disabled attribute.
>
> Considering that required fields are not always clearly indicated in
> forms, validating individual fields might be a better solution than
> disabling the Submit button.
>
> Geetha
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> <EMAIL REMOVED>
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
> submit button
>
> External email: if the sender or content looks suspicious, please
> click the Report Message icon, or forward it to report-phishing
>
> Correct, this is why in the org I work in we encourage designers to
> hide the submit button until the conditions of the forms are ready to
> submit or don't disable it and handle via error management.
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
> submit button
>
> 1. Most developers use the disabled attribute and not aria-disabled.
> It is important to keep an eye on this one.
> 2. Aria-disabled is rendered through the accessibility tree, which
> makes it discoverable by assistive technologies. What would happen to
> keyboard only users?
> I am not trying to argue with anyone on the list. I just like to
> remind folks that WCAG does not only focus on users with assistive technologies.
> There are many users that fall under the cognitive and motor categories.
> Many of them do not use Ats. It is important for us as accessibility
> professionals not to fall in the same trap like UX Designers. We
>
> The approach I mentioned, which validates each form field once focus
> is lost, can accomplish the following:
> 1. Informs all users of the invalid field before the user proceeds.
> This helps keep those with certain cognitive disabilities focused on
> filling out the various parts of a form, especially if it is lengthy.
> 2. Reduces overhead navigation, because both screen reader and
> keyboard only users would not have to navigate from the Submit button
> back to the various form elements that failed validation. overhead navigation.
> 3. Provides a client-side validation approach, which would eliminate
> unnecessary postback to the server. This can be very helpful for
> mobile users or those with poor internet connections.
> 4. Standardizes the form validation, which provides an efficient user
> experience for various types of users and avoids using the disabled
> attribute on the Submit button.
>
> Again my 2 cents. 😊
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc: Hill, Barry (Accessibility Tester) < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
> submit button
>
> Thanks for that, Mark and all. Interesting that it can be made focusable.
> Does the fact that it's disabled yet focusable become an accessibility
> issue in itself?
>
> Thanks again in anticipation.
>
> Cheers
>
> Barry
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
> submit button
>
> A disabled Submit button can still be focusable and exposed to AT.
> Coding-wise, if you add the HTML disabled attribute it will not be
> focusable in most, if not all, browsers. But if you add
> aria-disabled="true" it will remain focusable. This makes it
> discoverable and gives you the opportunity to provide some information
> in the name or description about why it is currently disabled.
> > From: WebAIM-Forum < <EMAIL REMOVED> > on behalf of
> jp Jamous < <EMAIL REMOVED> >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: [EXTERNAL] Re: [WebAIM] Whether or not to disable form submit
> button
>
> What Chat GPT provided is not necessarily WCAG compliant. In fact, it
> is a UX Design guideline. All of the UX designers I have worked with
> since 2018 have been implementing this.
>
> While it might work for sighted users, I find it to work against
> screen reader and keyboard only users. If the form does not display
> any errors once a form element loses focus and no status alerts are
> spoken, then the user would tab to the end of the form and there is no
> Submit button receiving focus. That Throws the user off until the user
> figures out that something is wrong with the form.
>
> I am not claiming that I am against it. As long as 1. there is a
> visual alert And 2. status alert
>
> Once the invalid form element loses focus , having the Submit button
> disabled is okay. Unfortunately, UX Design does not take all users in
> consideration. That is why my approach with UX Designers is to look at
> an inclusive approach rather than what is defined by UX Design documentation.
>
> Just my 2 cents on this.
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> <EMAIL REMOVED>
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Whether or not to disable form submit button
>
> I was actually unsure about this.
> So I asked my buddy ChatGPT and this is what he said
>
> While there may not be a universal standard, it's considered a good
> practice to disable the submit button until all required fields are correctly filled.
> This helps prevent incomplete or erroneous form submissions and
> enhances user experience.
>
> Dean Vasile
>
>
> 617-799-1162
>
>> On Dec 14, 2023, at 7:59 AM, Hill, Barry (Accessibility Tester) via
>> WebAIM-Forum < <EMAIL REMOVED> > wrote:
>>
>> Hi all
>>
>> I'm looking for a rule or regulation on this, but, if there isn't
>> one, best practice will help. Should a submit button on a form be
>> disabled until after all fields have been correctly completed?
>>
>> Thanks in anticipation.
> > > http://list.webaim.org/<;http://list.webaim.org/>; List archives at
> http://webaim.org/discussion/archives<;http://webaim.org/discussion/arc
> hives> > > > http://list.webaim.org/<;http://list.webaim.org/>;
> List archives at
> http://webaim.org/discussion/archives<;http://webaim.org/discussion/arc
> hives> > > > archives at http://webaim.org/discussion/archives
> > this email including any attachments may be privileged, confidential
> and is intended exclusively for the addressee. The views expressed may
> not be official policy, but the personal views of the originator. If
> you have received it in error, please notify the sender by return
> e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are
> trademarks of Sky Limited and Sky International AG and are used under licence.
>
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited
> (Registration No. 2067075), Sky Subscribers Services Limited
> (Registration No. 2340150) and Sky CP Limited (Registration No.
> 9513259) are direct or indirect subsidiaries of Sky Limited
> (Registration No. 2247735). All of the companies mentioned in this
> paragraph are incorporated in England and Wales and share the same
> registered office at Grant Way, Isleworth, Middlesex TW7 5QD
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >


--
Regards,
Kavein
Kaveinthran (He/Him)
Curious, Native Blind
Part time Research Consultant in ADPAN
Disabled independent Human Rights Advocate
email: <EMAIL REMOVED> < <EMAIL REMOVED> > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>