Create Semantic, Accessible HTML for Radio Buttons and Checkboxes

Share this video with your friends

Social Share Links

Send Tweet
Published 4 years ago
Updated 4 years ago

We'll round out the HTML for our form fields by adding radio buttons and checkboxes, including each in a checked, unchecked and disabled state. You'll learn about best practices for both field types semantically as well as when to use each.

Radio buttons should be used when you want a single selection out of a set of options while checkboxes should be used when you want multiple selections out of a set. A key difference between radio/checkbox and other inputs is that you wrap the label around the options which creates a direct relationship between the label and input so a for attribute is not strictly necessary.

Instructor: [0:00] Let's create the HTML markup for our radio buttons and checkboxes. Our first step will be to add both partials, so radio.njk, as well as, checkbox.njk. Then we will comment out our existing select and go ahead and include both radio and checkbox. We once again have a blank slate to work through adding our markup starting on our radios.

[0:25] As we've done for both text inputs and selects, we're going to be wrapping each field in our form-group class. Let's go ahead and create that as our starting point. A unique difference of radios and checkboxes is that the best practice is to wrap the input with the label.

[0:42] Within our label we will add both the input, and in this case, the type needs to be set to radio, and then we will add our actual label text after that input. In this case, I'll simply say radio and you see that has been rendered to the screen.

[0:59] Since we defined label styles for form-group, that's why we're already seeing a bit of styling applied. Because the input falls inside of the label, there is an automatic relationship, and a for attribute is not necessarily required.

[1:14] Another unique aspect of radio buttons is that only one in a set can be checked at a time in order to create that relationship among a set of radio buttons. The name field should be the same for all related radio buttons. Add the name of radio, then if we duplicate this, and on our second one, we're going to represent this as prechecked.

[1:37] I'm going to update my label and also add the checked attribute. On save, we can see that represented at that second one's checked. Since they both have the same name value, if I click the unchecked radio, it will become checked and the other radio unchecked. If the name value was different, we would be able to check both radios at the same time, which would be contrary to the purpose of radio buttons.

[2:01] Radio buttons should be used when you want to make one selection from a set. Whereas checkboxes should be used to allow multiple selections from a set. Just like we did for our other field types, we'll go ahead and duplicate this and add disabled versions.

[2:17] In this case, let's update this label to "Radio disabled," and this last one to "Disabled and checked." On both of these inputs, we will add the disabled attribute. You can see those rendered out and as we're used to seeing by now, the native browser styles has given them a slightly grayed out appearance.

[2:34] The essential semantic markup for radio buttons and checkboxes is actually identical. I'm going to copy this entire set and then, in my checkboxes file, we'll do a Find and Replace.

[2:46] We'll go ahead and ensure that we turn on match-casing so that we can replace the uppercase Radio to Checkbox and the lowercase radios to checkbox. On Save, we now see our series of checkboxes as well, including unchecked, checked in both a default and disabled state.

[3:03] In this lesson, we learned that the best practice for radios and checkboxes is to place both the input and label value within the label tag. We also learned that the essential semantic HTML for both radio and checkboxes is identical.

egghead
egghead
~ 24 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today