If I display a hidden button, based on a radio button selection, does it meet accessibility requirements?

Question

HI I have a scenario where a user (car dealership) has to fill out some car details for a sold car and then print a driving permit. When they click the 'print permit' button the permit will print and they are prompted with the question: Did the permit print correctly? yes radio button and no radio button.

By clicking the 'yes' radio button the 'registration complete' button appears for the user to click which takes them to a car registration success page. If they choose 'no' they have to start the registration process over again.

They have to print the permit before they can proceed to success page otherwise the registration has failed. Is this ok from an accessibility stand point? Do all buttons on a page have to be available to assistive technology, even if they are based on a users decision? thanks

Answer 1

You can make it accessible for assistive technology by using a aria-live region that announces the button when it becomes visible. But hiding the button isn't necessary at all and only makes things more complicated than it should have. There are better solutions that are clear, accessible and show all the information upfront.

The following example shows all the user needs to know: What is being printed, how to correct things when needed and that a correct print is essential to continue.

The button is greyed out but can still be clicked. When the user clicks it and the checkbox is unchecked the help text above will highlight (e.g. red with icon). For screen readers that message can be read again by using aria attributes*. This way users that are confused and click it anyway will not be left in the dark.

When the checkbox gets checked it is also nice to give some positive feedback (e.g. green check mark) and make the button green.

Those are just examples but the essence is in keeping things visible and clear.

*When the button is clicked and the checkbox is not checked, that checkbox is basically invalid, so when that happens set the aria attribute aria-invalid to true and use aria-errormessage to read the text below (again).

<label>
    <input
        type="checkbox"
        name="print_confirmed"
        aria-invalid="true"
        aria-errormessage="message">
    The driving permit was printed correctly
</label>
<p id="message">
    You need to have a correctly printed driving permit before you can continue
</p>

Answer 2

Even if you don't use assistive technologies, hiding the "Continue" button may be confusing, as it sounds like an essential action that is missing from the page. For a screen reader user, the button will not be announced if it's hidden with display: none, so the page will appear incomplete. Overall, there are more inclusive ways of disabling buttons.

For the case described in the question, I would consider a different approach. The user might not want to print the form for whatever reason, and they wouldn't know how to proceed until the "Yes" option is chosen. I believe this could be solved by removing radio buttons and introducing a bit of copy to nudge the user to do the intended action – but not blocking them from doing something else.

This way, the prompt is fully keyboard-accessible, there are no moving parts, the visual focus is on printing the form, and your users aren't forced to do what they don't want to do.

It would be best if your application supported going back, in case the user changes their mind. They press "Back", print the form, and proceed as usual.

Answer 3

The interaction is destined to be inaccessible, regardless of what you do with form controls on the page. The reason is that you are (apparently) requiring the user to print a form.

Only users who have access to printers can print a form.

Once a form is printed, you have lost control over the interaction and cannot make it accessible. The form is on paper. Most likely, users who cannot see, and users who cannot write, will be unable to complete and sign the form. Even if they can do that, then they will need to handle the form, perhaps by putting it into an envelope, addressing the envelope, affixing postage to the envelope, sealing the envelope, and mailing the envelope, all of which will be impossible or impractical for users with some disabilities, users who have no postage, or users who cannot travel to a post office.

To make this interaction accessible, you can eliminate the requirement to print. You can instead create an accessible digital process for the user to supply the information you need without ever leaving the website.