WebAIM - Web Accessibility In Mind

E-mail List Archives

Whether or nottodisableformsubmitbutton

for

From: Dean.Vasile@outlook.com
Date: Dec 19, 2023 4:00PM

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 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 REMOVED> > on behalf of Hill, Barry (Accessibility Tester) via WebAIM-Forum < <EMAIL REMOVED> >
> Date: Tuesday, December 19, 2023 at 11:31 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc: Hill, Barry (Accessibility Tester) < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
> 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 REMOVED> > On Behalf Of jp Jamous
> Sent: Monday, December 18, 2023 2:51 PM
> To: WebAIM Discussion List < <EMAIL 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 REMOVED> > On Behalf Of <EMAIL REMOVED>
> Sent: Monday, December 18, 2023 7:14 AM
> To: 'WebAIM Discussion List' < <EMAIL 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 REMOVED> > On Behalf Of Kavein Thran
> Sent: Monday, December 18, 2023 5:58 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form submit button
>
> re: the required state is not clearly indicated, there's an awesome discussion on github
>
> Request for clarification: does Name, Role, Value include static states like "required"? #3523
> https://github.com/w3c/wcag/issues/3523<https://github.com/w3c/wcag/issues/3523>
>
>> On 12/18/23, Geethavani.Shamanna < <EMAIL REMOVED> > wrote:
>> There are two scenarios that I have come across with regard to
>> disabled
>> buttons:
>> 1. The disabled button is accessible to mouse users, but is not
>> keyboard focusable, not in the tab order and not accessible to screen reader users.
>> 2. The disabled button is keyboard-focusable and is in the tab order,
>> but not accessible to screen reader users. In this instance we
>> recommend the use of the aria-disabled attribute.
>>
>> Considering that required fields are not always clearly indicated in
>> forms, validating individual fields might be a better solution than
>> disabling the Submit button.
>>
>> Geetha
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> <EMAIL REMOVED>
>> Sent: 18 December 2023 06:06
>> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
>> submit button
>>
>> External email: if the sender or content looks suspicious, please
>> click the Report Message icon, or forward it to report-phishing
>>
>> Correct, this is why in the org I work in we encourage designers to
>> hide the submit button until the conditions of the forms are ready to
>> submit or don't disable it and handle via error management.
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> jp Jamous
>> Sent: Monday, December 18, 2023 8:50 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
>> submit button
>>
>> 1. Most developers use the disabled attribute and not aria-disabled.
>> It is important to keep an eye on this one.
>> 2. Aria-disabled is rendered through the accessibility tree, which
>> makes it discoverable by assistive technologies. What would happen to
>> keyboard only users?
>> I am not trying to argue with anyone on the list. I just like to
>> remind folks that WCAG does not only focus on users with assistive technologies.
>> There are many users that fall under the cognitive and motor categories.
>> Many of them do not use Ats. It is important for us as accessibility
>> professionals not to fall in the same trap like UX Designers. We
>>
>> The approach I mentioned, which validates each form field once focus
>> is lost, can accomplish the following:
>> 1. Informs all users of the invalid field before the user proceeds.
>> This helps keep those with certain cognitive disabilities focused on
>> filling out the various parts of a form, especially if it is lengthy.
>> 2. Reduces overhead navigation, because both screen reader and
>> keyboard only users would not have to navigate from the Submit button
>> back to the various form elements that failed validation. overhead navigation.
>> 3. Provides a client-side validation approach, which would eliminate
>> unnecessary postback to the server. This can be very helpful for
>> mobile users or those with poor internet connections.
>> 4. Standardizes the form validation, which provides an efficient user
>> experience for various types of users and avoids using the disabled
>> attribute on the Submit button.
>>
>> Again my 2 cents. 😊
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> Hill, Barry (Accessibility Tester) via WebAIM-Forum
>> Sent: Sunday, December 17, 2023 5:45 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Cc: Hill, Barry (Accessibility Tester) < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
>> submit button
>>
>> Thanks for that, Mark and all. Interesting that it can be made focusable.
>> Does the fact that it's disabled yet focusable become an accessibility
>> issue in itself?
>>
>> Thanks again in anticipation.
>>
>> Cheers
>>
>> Barry
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> Mark Magennis
>> Sent: Thursday, December 14, 2023 4:04 PM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] [EXTERNAL] Re: Whether or not to disable form
>> submit button
>>
>> A disabled Submit button can still be focusable and exposed to AT.
>> Coding-wise, if you add the HTML disabled attribute it will not be
>> focusable in most, if not all, browsers. But if you add
>> aria-disabled="true" it will remain focusable. This makes it
>> discoverable and gives you the opportunity to provide some information
>> in the name or description about why it is currently disabled.
>> >> From: WebAIM-Forum < <EMAIL REMOVED> > on behalf of
>> jp Jamous < <EMAIL REMOVED> >
>> Sent: Thursday 14 December 2023 14:00
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: [EXTERNAL] Re: [WebAIM] Whether or not to disable form submit
>> button
>>
>> What Chat GPT provided is not necessarily WCAG compliant. In fact, it
>> is a UX Design guideline. All of the UX designers I have worked with
>> since 2018 have been implementing this.
>>
>> While it might work for sighted users, I find it to work against
>> screen reader and keyboard only users. If the form does not display
>> any errors once a form element loses focus and no status alerts are
>> spoken, then the user would tab to the end of the form and there is no
>> Submit button receiving focus. That Throws the user off until the user
>> figures out that something is wrong with the form.
>>
>> I am not claiming that I am against it. As long as 1. there is a
>> visual alert And 2. status alert
>>
>> Once the invalid form element loses focus , having the Submit button
>> disabled is okay. Unfortunately, UX Design does not take all users in
>> consideration. That is why my approach with UX Designers is to look at
>> an inclusive approach rather than what is defined by UX Design documentation.
>>
>> Just my 2 cents on this.
>> -----Original Message-----
>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>> <EMAIL REMOVED>
>> Sent: Thursday, December 14, 2023 7:19 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Whether or not to disable form submit button
>>
>> I was actually unsure about this.
>> So I asked my buddy ChatGPT and this is what he said
>>
>> While there may not be a universal standard, it's considered a good
>> practice to disable the submit button until all required fields are correctly filled.
>> This helps prevent incomplete or erroneous form submissions and
>> enhances user experience.
>>
>> Dean Vasile
>>
>>
>> 617-799-1162
>>
>>> On Dec 14, 2023, at 7:59 AM, Hill, Barry (Accessibility Tester) via
>>> WebAIM-Forum < <EMAIL REMOVED> > wrote:
>>>
>>> Hi all
>>>
>>> I'm looking for a rule or regulation on this, but, if there isn't
>>> one, best practice will help. Should a submit button on a form be
>>> disabled until after all fields have been correctly completed?
>>>
>>> Thanks in anticipation.
>> >> >> http://list.webaim.org/<;http://list.webaim.org/>;<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 REMOVED> < <EMAIL 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
> > > > > > > >