Labels and Inputs

Labels and inputs are cornerstones of the web and are imperative to be able to retrieve information from the end user. In this lesson, we'll cover how to pair labels and inputs and how they work in tandem to provide an accessible experience for all. Labels and inputs go together like two P's in a pod, as the two elements typically need to be used in conjunction with one another. Inputs play a crucial role on gathering information in our ubiquitous throughout the web. For example, like the contact form that you see here. Very important, labels provide context and guidance for the associated input. Inputs that rely solely on attributes like placeholder text or icons to convey their purpose exclude users who rely on assistive technology. When labels and inputs are properly associated, they offer significant accessibility advantages, including convenient interaction. So when you associate a label with an input, it allows users to simply click on the label to interact with the corresponding input. The expanded target area for input focus offers a benefit to all users, including those utilizing touchscreen devices, as it facilitates easier interaction of the input element. There's also enhanced screen reader support. Directly associating labels with inputs ensures that screen readers announce the label when the associated input receives focus. This provides users with clear and contextual information about the purpose and function of the input. And as you can see, the screen reader is reading out the labels here for the contact form. Now we'll go through some examples of the two different ways to associate a label with an input. The first approach is what we call explicit association. And to achieve this, you need to do two steps. The first is assign an ID attribute to the input element. In this case, we'll add an ID with the value of email-address. Second, we need to apply the four attribute of the label element, ensuring that the value of the four attribute matches the ID value of the corresponding input element. On the label here, we'll add a four attribute and give it the same value that we gave it to the ID, which was email-address. Alternatively, you can nest the input elements directly within the label tag. When this approach is used, the four and ID attributes are no longer required as the association is implicit. As you see here, we'll add a new label. And this time, we'll add an input with a type of checkbox, and we'll just nest that input within the label, forming that implicit association. Now we'll take a look at an accessible-friendly way of hiding a label. Occasionally, you may want the ability to hide a label. For example, in certain situations where the purpose of the content may be evident from the visual context. While the label can technically be visually hidden, we have to ensure that we think about this from an accessibility standpoint, so that individuals using assistive technology are taken into consideration and have a comfortable user experience. Although there are one-line styles like Display None and Visibility Hidden, which will achieve the desired visual effect, this is not suitable for screen-meter users. A commonly employed technique uses CSS to keep information accessible to assist ive technology, but visually hidden. This approach presents the label within a one-by-one pixel area. I show in the example using the CSS class visually hidden. So we would just add a class while visually hidden, like I said. And then we would take that class and apply it to the respective label element. So in this case, we'll apply it to the first label element for email address. And if you notice when we do that, the label gets removed from the UI. And when you apply this technique properly, you still include the label element in the HTML. You just apply the class and then that removes it from the DOM. And we'll see. So if we take a look and actually inspect this input, you'll notice that the label is still in the DOM. The class are just being applied to it. And if we look at the accessibility tree, it still notices that the email address label is there, which is exactly what we want. And if we take a look at MDN itself, they are employing the same technique with their search input. They have a label. They have a class called visually hidden, just like we do. The label is search MDN, but you don't see it, but it's still accessible to the accessibility tree. Again, this is a very common technique that's used.