E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Whether or not to disable form submit button

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

From: Hill, Barry (Accessibility Tester)
Date: Thu, Dec 14 2023 5:59AM
Subject: Whether or not to disable form submit button
No previous message | Next message →

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.

Cheers

Barry

Barry Hill
Accessibility Coach
"Empowering Accessibility, One Step at a Time"

Accessible Experiences Ltd
Mobile: 07833452110

Information in 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

From: Dean.Vasile@outlook.com
Date: Thu, Dec 14 2023 6:19AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS 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.

From: jp Jamous
Date: Thu, Dec 14 2023 7:00AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.

From: Yeti
Date: Thu, Dec 14 2023 7:07AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

Hello Barry,

> disabled until after all fields have been correctly completed?

I always do it like that!Und

And don't forget that there must also be a notification when the button becomes available.

Ad Astra

Yeti

From: Dean.Vasile@outlook.com
Date: Thu, Dec 14 2023 8:40AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

I think that was worth way more than two cents!
Great feedback
Dean Vasile

617-799-1162

> On Dec 14, 2023, at 9:01â¯AM, jp Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> ï»¿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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
> > > > > > >

From: Mark Magennis
Date: Thu, Dec 14 2023 9:03AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS REMOVED = > on behalf of jp Jamous < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 14 December 2023 14:00
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.

From: Srinivasu Chakravarthula
Date: Sat, Dec 16 2023 5:22AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

I agree. Submit button can be in disabled state but user should know about
its presence and purpose.
Regards,
Srinivasu
Regards,

Srinivasu Chakravarthula, CPWA (2018), DHS Trusted Tester
Website <http://www.srinivasu.org>; | LinkedIn Profile
<http://linkedin.com/in/srinivasuc>; | Follow me on Twitter
<http://twitter.com/csrinivasu>;
Director of Product Accessibility, Freshworks, Inc
<https://www.freshworks.com>

On Thu, Dec 14, 2023 at 9:33â¯PM Mark Magennis < = EMAIL ADDRESS REMOVED = >
wrote:

> 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 ADDRESS REMOVED = > on behalf of jp
> Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
> > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7CMark.Magennis%40skillsoft.com%7C044bdc53e6af4f99e91b08dbfcacffa8%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638381592180735166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sDEbJGQOGyqs9xQdtxy0TbhiwnEbX4hJyJK%2Bk1qk1Ic%3D&reserved=0
> <http://list.webaim.org/>; List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7CMark.Magennis%40skillsoft.com%7C044bdc53e6af4f99e91b08dbfcacffa8%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638381592180735166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WSkrLoReoCvVchxtaLQUIpb7zau%2BWRHS2YVrGJjLZ4I%3D&reserved=0
> <http://webaim.org/discussion/archives>;
> > > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7CMark.Magennis%40skillsoft.com%7C044bdc53e6af4f99e91b08dbfcacffa8%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638381592180735166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sDEbJGQOGyqs9xQdtxy0TbhiwnEbX4hJyJK%2Bk1qk1Ic%3D&reserved=0
> <http://list.webaim.org/>;
> List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7CMark.Magennis%40skillsoft.com%7C044bdc53e6af4f99e91b08dbfcacffa8%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638381592180735166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WSkrLoReoCvVchxtaLQUIpb7zau%2BWRHS2YVrGJjLZ4I%3D&reserved=0
> <http://webaim.org/discussion/archives>;
> > > > > >

From: Hill, Barry (Accessibility Tester)
Date: Sun, Dec 17 2023 4:45AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, December 14, 2023 4:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp Jamous < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 14 December 2023 14:00
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
Information in 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

From: jp Jamous
Date: Sun, Dec 17 2023 2:50PM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Sunday, December 17, 2023 5:45 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, December 14, 2023 4:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp Jamous < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 14 December 2023 14:00
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
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

From: mhysnm1964@gmail.com
Date: Sun, Dec 17 2023 11:06PM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 8:50 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Sunday, December 17, 2023 5:45 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, December 14, 2023 4:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp Jamous < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 14 December 2023 14:00
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
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

From: Kavein Thran
Date: Mon, Dec 18 2023 2:58AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

hi,

just to jump in and provide quite a similar perspective that I found
on UX stackexchange
disabling submit button without notification let users to think
there's something wrong.

https://ux.stackexchange.com/questions/110076/best-practice-validation-for-long-form-with-disabled-submit-button

On 12/18/23, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS REMOVED = > On Behalf Of jp
> Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Hill,
> Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Mark
> Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp
> Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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/archives>;
> > > > http://list.webaim.org/<;http://list.webaim.org/>;
> List archives at
> http://webaim.org/discussion/archives<;http://webaim.org/discussion/archives>;
> > > > http://webaim.org/discussion/archives
> > 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 > > http://webaim.org/discussion/archives
> > > > 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
twitter <https://twitter.com/kaveinthran>
My LinkedIn <https://my.linkedin.com/in/kaveinthran>

From: Geethavani.Shamanna
Date: Mon, Dec 18 2023 2:59AM
Subject: Re: Whether or not to disable form submitbutton
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: 18 December 2023 06:06
To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 8:50 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Sunday, December 17, 2023 5:45 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: Thursday, December 14, 2023 4:04 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp Jamous < = EMAIL ADDRESS REMOVED = >
Sent: Thursday 14 December 2023 14:00
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Thursday, December 14, 2023 7:19 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
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

From: Kavein Thran
Date: Mon, Dec 18 2023 4:57AM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of jp
> Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Hill,
> Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Mark
> Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of jp
> Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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/archives>;
> > > > http://list.webaim.org/<;http://list.webaim.org/>;
> List archives at
> http://webaim.org/discussion/archives<;http://webaim.org/discussion/archives>;
> > > > http://webaim.org/discussion/archives
> > 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 > > http://webaim.org/discussion/archives
> > > > 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
twitter <https://twitter.com/kaveinthran>
My LinkedIn <https://my.linkedin.com/in/kaveinthran>

From: tim.harshbarger@deque.com
Date: Mon, Dec 18 2023 6:13AM
Subject: Re: Whether or not to disable form submitbutton
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>

From: Geethavani.Shamanna
Date: Mon, Dec 18 2023 7:25AM
Subject: Re: Whether or not to disable formsubmitbutton
← Previous message | Next message →

I agree. As a screen reader user myself, I have come across instances where I could access the disabled button on the page, but it wasn't available in the tab order. Also instances where aria-required had been used to mark required fields, leaving sighted users at a disadvantage. It is incredible how innovative developers get. I recently came across a website where required icons had been added to the tab order preceding the form fields. Besides having redundant icons in the tab order, it wasn't clear whether the field preceding the icon was a required one or the field following it.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: 18 December 2023 13:14
To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0<https://eur01.safe/
> links.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data
> %7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec02ad6cc4a4756de08db
> ffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%7C6383850204256138
> 93%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2MRWWvKgEwaE56f8E1xk
> fXKj76fiifWIXJ17Hqk%3D&reserved=0> List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0<http://web/
> aim.org%2Fdiscussion%2Farc&data%7C02%7Cgeethavani.shamanna%40open.a
> c.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd98
> 1685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=R9pzX7qvrS10%2B6jDTjdoSYttsPawkhKCa4sTGWUDPVI%3D&reserved=0
> hives> > > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0<https://eur01.safe/
> links.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data
> %7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec02ad6cc4a4756de08db
> ffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%7C6383850204256138
> 93%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2MRWWvKgEwaE56f8E1xk
> fXKj76fiifWIXJ17Hqk%3D&reserved=0>
> List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0<http://web/
> aim.org%2Fdiscussion%2Farc&data%7C02%7Cgeethavani.shamanna%40open.a
> c.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd98
> 1685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=R9pzX7qvrS10%2B6jDTjdoSYttsPawkhKCa4sTGWUDPVI%3D&reserved=0
> hives> > > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0 List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0 > 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
> > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0 List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0 > > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0 List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0 >
> > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0 List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0 > > > http://list/.
> webaim.org%2F&data%7C02%7Cgeethavani.shamanna%40open.ac.uk%7Ce84ec0
> 2ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5fd981685%7C0%7C0%
> 7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uyMo2M
> RWWvKgEwaE56f8E1xkfXKj76fiifWIXJ17Hqk%3D&reserved=0 List archives at
> http://webai/
> m.org%2Fdiscussion%2Farchives&data%7C02%7Cgeethavani.shamanna%40ope
> n.ac.uk%7Ce84ec02ad6cc4a4756de08dbffcb3356%7C0e2ed45596af4100bed3a8e5f
> d981685%7C0%7C0%7C638385020425613893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=EMp6Y4YNMIzPmNF64B3uTmzhyVA4IUiw0%2BLL%2F7GWf90%3D&reserved> 0 >

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

From: jp Jamous
Date: Mon, Dec 18 2023 7:50AM
Subject: Re: Whether or not to disable formsubmitbutton
← Previous message | Next message →

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>

From: Hill, Barry (Accessibility Tester)
Date: Tue, Dec 19 2023 9:31AM
Subject: Re: Whether or not to disableformsubmitbutton
← Previous message | Next message →

The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>
Information in 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

From: jp Jamous
Date: Tue, Dec 19 2023 11:20AM
Subject: Whether or not todisableformsubmitbutton
← Previous message | Next message →

Barry,

I am unable to follow the business requirements for the form. Obviously, the Submit button is disabled when all check boxes are not checked. When one or more of those check boxes is/are checked, the Submit button becomes enabled. Am I following you so far?

If what I stated above is your actual business requirement, then I would suggest informing the user prior to checking any boxes. For example, "Make a selection from the following list. At least one option should be checked to continue: *" That way, all users are aware of what is expected from them. That reduces their failure of skipping all of the checkboxes.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Tuesday, December 19, 2023 10:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>
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

From: Eller, Meagan M
Date: Tue, Dec 19 2023 12:24PM
Subject: Re: Whether or not todisableformsubmitbutton
← Previous message | Next message →

Personally, I hate when forms have disabled submit buttons. Just let me try to submit the form and show me the errors! I have run into a non-zero number of forms that Iâve filled out but the Submit button stays disabled. Sometimes I can eventually figure out what I did wrong, but sometimes I canât. Disabling the submit button prevents me from quickly finding my error.

Is there a reason you canât just let the person submit the form and then find out what the error is?

To me, this is more a UX issue than an accessibility issue.

Best,
Meagan

From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Hill, Barry (Accessibility Tester) via WebAIM-Forum < = EMAIL ADDRESS REMOVED = >
Date: Tuesday, December 19, 2023 at 11:31â¯AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F3523&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HmvIISqSw1pUrmWucl2ewtkJZvd9cyPZtCc0mjeAZfA%3D&reserved=0<https://github.com/w3c/wcag/issues/3523>

On 12/18/23, Geethavani.Shamanna < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.
> > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wM6PfRyYhz0MSHhEz8%2BY07Ns167mV9rae60UlifLKp0%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wM6PfRyYhz0MSHhEz8%2BY07Ns167mV9rae60UlifLKp0%3D&reserved=0><http://list.webaim.org/>; List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kPYPSaFHm05eGw8aT09fl%2B4J9lPsUW6IcuFaCzflR00%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farc&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pdaSuRdy3GFZoRV5EETpUcehiNlIqocv%2FK386DZs8Us%3D&reserved=0<http://webaim.org/discussion/archives>;
> hives> > > > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wM6PfRyYhz0MSHhEz8%2BY07Ns167mV9rae60UlifLKp0%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2F&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wM6PfRyYhz0MSHhEz8%2BY07Ns167mV9rae60UlifLKp0%3D&reserved=0><http://list.webaim.org/>;
> List archives at
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kPYPSaFHm05eGw8aT09fl%2B4J9lPsUW6IcuFaCzflR00%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farc&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855152636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pdaSuRdy3GFZoRV5EETpUcehiNlIqocv%2FK386DZs8Us%3D&reserved=0<http://webaim.org/discussion/archives>;
> hives> > > > archives at https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qd2QJgfe0PViDGG73CGm8BovbwTkIqC8VDHdD%2BSFHxE%3D&reserved=0<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 https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qd2QJgfe0PViDGG73CGm8BovbwTkIqC8VDHdD%2BSFHxE%3D&reserved=0<http://webaim.org/discussion/archives>;
> > > > archives at https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qd2QJgfe0PViDGG73CGm8BovbwTkIqC8VDHdD%2BSFHxE%3D&reserved=0<http://webaim.org/discussion/archives>;
> >
> > > archives at https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qd2QJgfe0PViDGG73CGm8BovbwTkIqC8VDHdD%2BSFHxE%3D&reserved=0<http://webaim.org/discussion/archives>;
> > > > archives at https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebaim.org%2Fdiscussion%2Farchives&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qd2QJgfe0PViDGG73CGm8BovbwTkIqC8VDHdD%2BSFHxE%3D&reserved=0<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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkaveinthran&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Dukf87VN07YVq7YaCiiM3nqviff0CkLZ4BDxid0p6O0%3D&reserved=0<https://twitter.com/kaveinthran>> My LinkedIn <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.linkedin.com%2Fin%2Fkaveinthran&data%7C02%7Cmmeller%40iu.edu%7C24b6f195a1644c76876808dc00afefed%7C1113be34aed14d00ab4bcdd02510be91%7C0%7C0%7C638386002855308866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TQxSrNLKJONVZlQn7nahfkAnKrRxkgBRsVwurAXOELo%3D&reserved=0<https://my.linkedin.com/in/kaveinthran>>
Information in 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

From: Kevin Prince
Date: Tue, Dec 19 2023 3:09PM
Subject: Re: Whether or not to disable form submit button
← Previous message | Next message →

As long as the state is clear then not an issue.

Kevin

From: Dean.Vasile@outlook.com
Date: Tue, Dec 19 2023 4:00PM
Subject: Whether or nottodisableformsubmitbutton
← Previous message | Next message →

Hi all.
I have been reading this thread for sometime and I would like to chime in a little bit. Here are my thoughts.
I am exclusively a screen reader user, and I run into forms often when testingwebsites.
My issue with forms is not so much whether or not the submit button is dimmed, Disabled or not disabled.
It is the fact that when I do receive notifications, they do not take focus to where the error is on the page or they jump to the top of the page.
And the descriptions on where the errors are sometimes highlighted and not spoken.
These are the biggest issues I have with forms and their submit buttons
Dean Vasile

617-799-1162

> On Dec 19, 2023, at 2:25â¯PM, Eller, Meagan M < = EMAIL ADDRESS REMOVED = > wrote:
>
> ï»¿Personally, I hate when forms have disabled submit buttons. Just let me try to submit the form and show me the errors! I have run into a non-zero number of forms that Iâve filled out but the Submit button stays disabled. Sometimes I can eventually figure out what I did wrong, but sometimes I canât. Disabling the submit button prevents me from quickly finding my error.
>
> Is there a reason you canât just let the person submit the form and then find out what the error is?
>
> To me, this is more a UX issue than an accessibility issue.
>
>
> Best,
> Meagan
>
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Hill, Barry (Accessibility Tester) via WebAIM-Forum < = EMAIL ADDRESS REMOVED = >
> Date: Tuesday, December 19, 2023 at 11:31â¯AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
> The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.
>
> Cheers
>
> Barry
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
> Sent: Monday, December 18, 2023 2:51 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
>
> Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL
>
> The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.
>
> With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.
>
> Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.
>
> I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.
>
> What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Monday, December 18, 2023 7:14 AM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
>
> 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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
> Sent: Monday, December 18, 2023 5:58 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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<https://github.com/w3c/wcag/issues/3523>
>
>> On 12/18/23, Geethavani.Shamanna < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> = EMAIL ADDRESS REMOVED =
>> Sent: 18 December 2023 06:06
>> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> jp Jamous
>> Sent: Monday, December 18, 2023 8:50 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> Hill, Barry (Accessibility Tester) via WebAIM-Forum
>> Sent: Sunday, December 17, 2023 5:45 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> Mark Magennis
>> Sent: Thursday, December 14, 2023 4:04 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
>> jp Jamous < = EMAIL ADDRESS REMOVED = >
>> Sent: Thursday 14 December 2023 14:00
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
>> = EMAIL ADDRESS REMOVED =
>> Sent: Thursday, December 14, 2023 7:19 AM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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/>;<http://list.webaim.org/>; List archives at
>> http://webaim.org/discussion/archives<;http://webaim.org/discussion/arc<;http://webaim.org/discussion/archives>;
>> hives> >> >> >> http://list.webaim.org/<;http://list.webaim.org/>;<http://list.webaim.org/>;
>> List archives at
>> http://webaim.org/discussion/archives<;http://webaim.org/discussion/arc<;http://webaim.org/discussion/archives>;
>> hives> >> >> >> archives at http://webaim.org/discussion/archives<;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<;http://webaim.org/discussion/archives>;
>> >> >> >> archives at http://webaim.org/discussion/archives<;http://webaim.org/discussion/archives>;
>> >>
>> >> >> archives at http://webaim.org/discussion/archives<;http://webaim.org/discussion/archives>;
>> >> >> >> archives at http://webaim.org/discussion/archives<;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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran<https://twitter.com/kaveinthran>> My LinkedIn <https://my.linkedin.com/in/kaveinthran<https://my.linkedin.com/in/kaveinthran>>
> > > >
> > > > Information in 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
> > > > > > > >

From: Hill, Barry (Accessibility Tester)
Date: Wed, Dec 20 2023 1:20AM
Subject: Re: Whether or nottodisableformsubmitbutton
← Previous message | Next message →

You've got it spot on there, JP. I like your suggestion for the text, which I will suggest to the designers. Just to clarify, is it the case then to have that submit button disabled until a selection is made? That prompts another question: Do we need to inform screen reader users that the submit button has become active as soon as the first selection is made? Excuse my coding ignorance, but would that require aria?

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Tuesday, December 19, 2023 6:21 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Barry,

I am unable to follow the business requirements for the form. Obviously, the Submit button is disabled when all check boxes are not checked. When one or more of those check boxes is/are checked, the Submit button becomes enabled. Am I following you so far?

If what I stated above is your actual business requirement, then I would suggest informing the user prior to checking any boxes. For example, "Make a selection from the following list. At least one option should be checked to continue: *" That way, all users are aware of what is expected from them. That reduces their failure of skipping all of the checkboxes.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Tuesday, December 19, 2023 10:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>
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 Information in 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

From: jp Jamous
Date: Wed, Dec 20 2023 9:44AM
Subject: Whether ornottodisableformsubmitbutton
← Previous message | No next message

Barry,

Glad to help. Good luck with the designers. LOL

1. I agree with you that the button can be disabled until one of the checkboxes is checked. Then, your developers can make that button enabled via JavaScript as soon as one of those checkboxes is checked.
2. I would not inform screen readers of that change for a specific reason. The output would become too verbose and can make some users confused if they hear: "Submit button is enabled.", once the checkbox is checked
One of the questions that might cross your mind is, how would I achieve inclusive design if I don't inform a screen reader user of what the sighted user can see? I know it sounds like what I suggested in #2 contradicted my inclusive approach mindset. However, it is important to identify how each of our senses provides information to our brains. For example, a sighted user would automatically see the button color changes once the checkboxes is checked. That can be easily ignored and it is easy to identify visually what happened.

On the contrary, if I hear JAWS say: "The Submit button is enabled", I am not going to find that Submit button until I down-arrow or tab to get to it. So finding it and building that info/relationship between the 2 HTNL elements would be confusing to me as a first-time user. Of course, once I become oriented to the form's layout, then the message would be fine. This would lead to the difficult part of WCAG, how do you find the sweet spot across all users? That is not a spot that is easily attained in certain cases. That is why I like to refer to the saying, a picture is worth a thousand words. To the human eye absolutely. I know that first-hand as I was fully sighted for the first 12 years of my life. If I want to hear 1,000 words through JAWS to obtain what is happening visually, I will need a mental institution by the time JAWS is done ranting. LOL I am sure you get the point.

To answer your ARIA question, should you decide to provide that status update that is not important in my humble opinion, you can use aria-describedby on the first checkbox that gets checked. Here is the programming logic.
1. Checkbox2 is checked
2. Javascript changes the button to enabled
3. It then adds to the checkbox aria-describedby=" lblStatusText" of the visually hidden span that would already be in the DOM, as a part of the Submit button. The output would look like this:
<input type="checkbox" aria-describedby="lblStatusText">
<button type="submit">
<span id="lblStatusText" class="sr-only">
The Submit button is enabled.
</span>
<span id=lblSubmit">Submit</span>
</button>
Two things your developers might need to do for all screen readers to catch what Javascript did:
1. set the focus on a empty element then back on the checked checkbox for screen readers to recognize that aria-describedby was added
2. wait for about 250 milliseconds using a counter before placing the focus back on the checked checkbox. That might be necessary for certain screen readers to recognize that the accessibility tree was updated by Javascript.

Those are the different scenarios I can think of that your developers might need to handle.

With all of that information at your disposal, you may send me a check to the Order of JP Jamous for a $250 consultation fee. LOL Just kidding.

Good luck.
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Wednesday, December 20, 2023 2:21 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

You've got it spot on there, JP. I like your suggestion for the text, which I will suggest to the designers. Just to clarify, is it the case then to have that submit button disabled until a selection is made? That prompts another question: Do we need to inform screen reader users that the submit button has become active as soon as the first selection is made? Excuse my coding ignorance, but would that require aria?

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Tuesday, December 19, 2023 6:21 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Barry,

I am unable to follow the business requirements for the form. Obviously, the Submit button is disabled when all check boxes are not checked. When one or more of those check boxes is/are checked, the Submit button becomes enabled. Am I following you so far?

If what I stated above is your actual business requirement, then I would suggest informing the user prior to checking any boxes. For example, "Make a selection from the following list. At least one option should be checked to continue: *" That way, all users are aware of what is expected from them. That reduces their failure of skipping all of the checkboxes.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Tuesday, December 19, 2023 10:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

The particular case I'm looking at has five options that can be selected as check boxes, from one to five of them depending on user choice. Then there is that submit button to action the selections. Apparently, we cannot use in-line validation for the check boxes. Should this still be an enabled submit button using the subsequently generated error message to explain the error, or can we use Aria describedby to explain why the submit button is disabled? If there is another solution for this simple form, I'd be only too pleased to hear it.

Cheers

Barry

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of jp Jamous
Sent: Monday, December 18, 2023 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

Good point Tim. I am an old school developer. I was coding with VB 6 in college and dove into the .NET when it came out. That tells you how old I am. LOL

The professor that taught me programming came from the punch card days. He taught me old skills and tricks that I still use until today. I am so grateful to have met Ron.

With the above in mind, I refuse to use ARIA unless there is no HTML approach to the problem. Sure HTML is loose and browsers are forgiving now, but that does not mean we should go with the flow and get sloppy with our markup. In fact, many programming languages are following Apple's approach with Swift. Only retrieve from a class what you want and not the whole class as Object Oriented Programming has always done. That allows efficient programming, faster execution and more information can be loaded in the memory of a device without bogging it down.

Users not only want accessibility but productivity as well. I have witnessed so many developers inject ARIA all over, because it is in their minds now that ARIA is for people with disabilities. The same concept as screen readers are the only assistive technologies to worry about. Both of those are wrong. In fact, it is our duty as Accessibility Professionals to educate developers to lead them down the right path.

I am not stating that my approach is the best. Every situation is different. For example, if a business wants an accessible sight, but time is money, they might use ARIA to expedite their sprints. It might be feasible for them to do that then to lose money on each sprint. They can purchase additional resources on their cloud-based web servers and put the load on that side rather than on the client side.

What I am claiming is that we still need to teach proper markup, efficient execution and best user experiences. Those 3 are a part of the user interface and accessibility is all about the user interface. A good example is the reason why Twitter came out with Bootstrap in the early 2000 for mobile devices and why Facebook came out with React for mobile browsers as well. The interesting part is that React is still the hottest web development framework and Bootstrap is still a major part of all of Visual Studio's web templates. That fact says quite a bit about efficient execution.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, December 18, 2023 7:14 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button

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 ADDRESS REMOVED = > On Behalf Of Kavein Thran
Sent: Monday, December 18, 2023 5:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: 18 December 2023 06:06
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> jp Jamous
> Sent: Monday, December 18, 2023 8:50 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Hill, Barry (Accessibility Tester) via WebAIM-Forum
> Sent: Sunday, December 17, 2023 5:45 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc: Hill, Barry (Accessibility Tester) < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> Mark Magennis
> Sent: Thursday, December 14, 2023 4:04 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > on behalf of
> jp Jamous < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday 14 December 2023 14:00
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Thursday, December 14, 2023 7:19 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > twitter <https://twitter.com/kaveinthran> My LinkedIn <https://my.linkedin.com/in/kaveinthran>
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 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