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.