WebAIM - Web Accessibility In Mind

E-mail List Archives

Whether ornottodisableformsubmitbutton

for

From: jp Jamous
Date: Dec 20, 2023 9:44AM

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 REMOVED> > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Wednesday, December 20, 2023 2:21 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

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 REMOVED> > On Behalf Of jp Jamous
Sent: Tuesday, December 19, 2023 6:21 PM
To: WebAIM Discussion List < <EMAIL 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 REMOVED> > On Behalf Of Hill, Barry (Accessibility Tester) via WebAIM-Forum
Sent: Tuesday, December 19, 2023 10: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

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


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