accessibility - Choose between two options on website, should I use buttons or radiobuttons?

Question

I'm working on a voting app and I'm trying hard to make it as accessible as possible. But I can't get my head around what the best way is to do this.

I have a question, an explanation about the question and two options to choose from. The current way I've build it is like this:

<h2>Do you like apples?</h2>
<p>Apples are a type of fruit and can be sweet or sour.<p>

<button aria-pressed="false" aria-role="button" aria-label="Yes, I like apples">yes</button>
<button aria-pressed="false" aria-role="button" aria-label="No, I don't like apples>no</button>

With a small script I will make sure that the button pressed gets an aria-press="true". But then it struck me that it might be better using radiobuttons for this?

<h2 id="q-appleTitle" for="q-apple">Do you like apples?</h2>
<p id="q-appleDesc" >Apples are a type of fruit and can be sweet or sour.<p>

<input type="radio" id="qYes" value="yes" aria-describedby="q-appleTitle q-appleDesc">
<label aria-label="Yes, I like apples" for="qYes">Yes</label>

<input type="radio" id="qNo" value="no" aria-describedby="q-appleTitle q-appleDesc">
<label aria-label="No, I don't like apples" for="qNo">No</label>

What is the preferred method of doing something like this?

question from:https://stackoverflow.com/questions/65831099/choose-between-two-options-on-website-should-i-use-buttons-or-radiobuttons

Answer 1

It struck me that it might be better using radio buttons for this?

This should almost certainly be a radio button, due to the fact that for screen reader users this will announce that there are 2 options and which option they have selected (if any).

If these were just buttons they would not know how many options they have to choose from.

What is the preferred method of doing something like this?

Now as radio buttons are <input>s they must be contained within a form.

This means for screen reader users "forms mode" is enabled which makes navigating easier etc. As such they should not automatically load the next page (as this is not expected behaviour and expected behaviour is key to accessibility).

Instead once an option is selected you should enable a "next" button, which should also be the "submit" button for the form.

As the inputs should now be within a form things like pressing Enter to submit will be automatic so you don't need to worry about implementing all of that.

Forms behaviour to consider

Final considerations are that to comply with WCAG users should be able to go back and change their answer, or edit their answer later, or if this is part of a multi-part form that once submitted cannot be changed, they should see a summary of all of their selections before the final submission.

This is to ensure you meet guidance G98: Providing the ability for the user to review and correct answers before submitting and guidance G164: Providing a stated time within which an online request (or transaction) may be amended or cancelled by the user after making the request

Final thoughts

In your second example with the radio buttons your aria attributes aren't quite right.

Anything relating to label is read before aria-describedby.

So at present when selecting a radio button it would read:

"Yes, I like apples, Do you like apples? Apples are a type of fruit and can be sweet or sour."

You do not need the description to be read out with each radio button so that makes things easier and perhaps you should use aria-labelledby instead and give your <label> an id, as that will read any referenced elements in order (so aria-labelledby="q-appleTitle yourNewLabelID" instead of your current aria-describedby).

Finally, if you do this, there is no need for your aria-label on your <label> elements. At the moment this is massive overkill.

However for people with cognitive disorders being able to see "Yes, I like apples" would definitely be beneficial, so I would recommend changing the label text to that if space allows, the slight extra verbosity for a screen reader is worth the trade-off.

I haven't tested the below but I would imagine it announces correctly for a screen reader, with a decent fallback using for= for screen readers that don't support aria-labelledby.

<input type="radio" id="qYes" value="yes" aria-labelledby="q-appleTitle q-appleLabel">
<label id="q-appleLabel" for="qYes">Yes, I like Apples</label>