Why is focus state interaction is different for Checkbox and radio field

Question

Today I noticed that radio buttons and checkboxes have different interaction for focus state.

If you look at the example webaim of a radio button you notice that you can not select the next radio button using the same tab-interaction. To select the second option you need to use the up and/or down keys to change your selection (and it auto selects your current version).

However when you want to switch checkboxes you can use the tab-interaction to jump to the next. I find this interaction somewhat strange.

I can understand that you only select 1 of the options of a radio button, but this makes every radio button field for key-board only users mandatory (because the first tab auto selects the first radio), while not every radio button field might be mandatory.

Example: In some signups, selecting your gender/sex is not required but optional. These are mostly Male / Female and sometimes Other. Keyboard only users would be required to fill this information because they can not skip the question using tab.

Am I missing something, or is this behaviour inconsistant with other interactions? Any WCAG experts that can shed some light on this?

Answer 1

Your answer can be found on this page: https://www.w3.org/WAI/ARIA/apg/patterns/radio/

Quoting from that:

Some implementations may initialize the set with all buttons in the unchecked state in order to force the user to check one of the buttons before moving past a certain point in the workflow.

So radio button choices are meant to be mandatory by design. I would always select one by default to make that clear for users.

It is for that reason that when you click one you can't unselect it, so that's the same problem when selecting it using the keyboard. That is the design of radio buttons and it's a bad idea to manipulate that (using javascript) for accessibility reasons but also because it is adding completely unnecessary complexity. When that isn't the behaviour you want, choose some other control. In your example for gender selection there can be a third option: A neutral (eg "None") option which is also a choice, otherwise you can add a switch (checkbox maybe) to toggle the whole gender fieldset on or off (enabling/disabling all radio buttons).

Checkboxes are independent input fields. They can be grouped together to form a combined (field)set of choices but they operate independently.

Radio buttons are dependent on each other since choosing one unselect the others.

Answer 2

jazZRo is right and provides a good source.

Checkboxes are independent input fields

This is true for the intention of checkboxes, and most use cases.

However, I agree with the remark in the question that the behaviour can be strange, even annoying, in certain use cases for checkboxes.

Use listbox for long checklists

A long list of checkbox items should be considered a composite widget as well, just as radiogroup, and focus should be managed. That way it would be possible to jump to the next widget without pressing Tab repeatedly.

But since the role checkbox does not create that expectation, another one should be used.

listbox seems like the right role:

A widget that allows the user to select one or more items from a list of choices.

You could use actual <input type="checkbox"> elements to make sure the status is reflected in the form data. You would need to make sure that focus is managed, and change their role to option.

HTML intends the <select multiple> element for a checklist, but its usability is not good. Its role also is listbox.

Data tables and grids

Another form of checklist is data grids with checkboxes to select rows.

Within a grid, focus must be managed any way, so Tab will not jump from one checkbox to the next either.