With the help of our JavaScript we're changing the hint message within the paragraph and the screen reader will be told to read the change. To inform the user of this change we're using aria-live="assertive" on an visually hidden paragraph. As soon as he/she ticks the checkbox the button will be enabled. You see, in our example the user has to check a checkbox, otherwise the button will not work. On top we're using something called aria-live. Here's a simple example of a form that not only uses aria-disabled but also some JavaScript to prevent this disabled button to submit the form by accident. The user might submit the form anyhow, even if not all your conditions have been fulfilled. It's also important to notice that although "disabled" the aria-disabled will be clickable. So you have to add some CSS to the button, e.g. Hint: A button with aria-disabled="true" doesn't look the same as a button with the attribute disabled.
In this case we can use an aria-disabled="true" instead of the good old disabled. But when a screen reader doesn't ever reach the button, then he will never indicate that there's a button. Thus we disable the button until all the conditions have been fulfilled. But our form depends on the fact that every input has to be filled out - or something else has to happen before it can be submitted.
And normally a form gets submitted by hitting a button. Now close your eyes and imagine the screen reader reads out all the inputs of a form. By using the tabulator key and navigating within a form the screen readers will ignore the existence of any disabled button. It’s inactive.Īnd what about visually impaired users? They don’t get any feedback at all.
Either way, sighted users will get some sort of visual feedback that he/she is not able to click on this button. The disabled attribute often appears a little bit dimmed or transparent. This button should be disabled as long as all forms haven’t been filled out. You could have a form with a button at the bottom.
0 kommentar(er)
