Programmatically Labeled Forms
Welcome to Part 6 in our First Steps to an Accessible Website series!
We are getting close to wrapping up this blog series and with this post we are turning our attention to form labels. When it comes to forms, there are about 18 different WCAG 2.1 Level A/AA Success Criteria that provide guidance. This is not always apparent based on the wording of the WCAG Success Criteria alone, which is one of the reasons why we created WebAlign. WebAlign provides the structured, comprehensive, and clear way to understand and apply WCAG 2.1 Level A/AA to the web development lifecycle.
We are not going to be covering all the 18 related WCAG criteria as that goes beyond the ‘first steps’ that this blog series is about. Instead, we are going to focus on a basic approach to labeling forms that will ensure that assistive/adaptive technologies (AT) of all types can access and correctly associate the label to its corresponding input control. In WCAG 2.1, this is covered by Success Criterion 1.3.1 Info and Relationships. This criterion requires that the information and relationship of content presented visually can also be determined programmatically. The specific Sufficient Technique that applies is H44: Using label elements to associate text labels with form controls.
While there are other methods of providing programmatic labels, such as using an aria-label attribute, these methods often do not provide a visual label and/or may not be fully supported by some AT. In most cases a visual label should be provided, and the basic HTML method outlined in this post will ensure that the label is programmatically associated with the form element.
Visual Only Form Labels (Bad)
Form labels are a very standard and basic part of HTML, yet I am still amazed at how often we come across form input fields that have visual labels, but the labels themselves are not coded to programmatically link the label with its input form. For example, we often see labels coded something like:
<span>First Name:</span>
<input id="User" name="First Name" type="text" />
Here is a working example of the previous code snippet:
First Name:
While this provides a visual label for the input control, the label text and the input control are not programmatically linked. Some AT may assume the text before the input control should be provided as the label text, but not all AT will do so and when they do there are cases in which the AT can get it wrong. This can lead to situations where the AT user believes they have entered the correct data but have entered incorrect data!
HTML Label Tag (Good)
A basic HTML label is constructed using the <label> tag. For example, if we were to label a text input field for a person’s first name, it would look something like:
<label>First Name:
<input id="User" name="First Name" type="text" />
</label>
Here is a working example of the previous code snippet:
The above method of labeling an input control does programmatically link the label to the input control, conforms to Success Criterion 1.3.1 Info and Relationships, and should work for most AT without an issue. Where problems start to arise is when there is a lot of extra content between the opening and closing label tags. This can cause problems for AT because, depending on the amount and complexity of the additional content between the label tags, the AT may not be able to accurately parse the HTML code. When this happens, the label tag is lost to the AT and as a result to the user who needs to that information.
HTML Label For Tag (Best)
The best and most reliable method to programmatically link a visual label to its input control is to use the <label for> tag. It is basically the same as the HTML label tag but adds the ‘for’ attribute. Here is an example:
<label for="User">First Name:</label>
<input id="User" name="First Name" type="text" />
Here is a working example of the previous code snippet:
Including the ‘for’ attribute for the label tag allows us to wrap the tag around the label text only and specifically identify which control the label belongs via the label tags ‘for’ attribute and the input control’s ID attribute. The key here is to ensure that the ID value for the input control is unique on the page otherwise this will interfere with AT’s ability to reliably connect the label with the input control.
Here is an example that shows a common situation where a layout table has been used to arrange a series of input controls and their labels. This layout does not lend itself to using the <label> tag alone (without the <label for>) and can make it very difficult for a screen reader user know the purpose of the input field. If you have a screen reader, try reading through the following to experience what we mean.
| First Name: | Last Name: |
Here is the same example of using a layout table but this time using the <label for> tag to programmatically associate the visual labels with their corresponding input controls. Using a screen reader, you will be able to hear the difference this method makes compared to the last one.
Summary
While there are a several ways to label input controls for AT, many do not provide a visual label. When visual labels are necessary it is always best to use the <label for> tag to ensure the best compatibility with browsers and AT software.
In the next post, we will talk about accessible keyboard testing.
As mentioned at the outset of this post, there are about 18 different WCAG 2.1 Level A/AA Success Criteria that touch on forms. We have just scratched the surface with programmatically labeled forms. If you and your teams can benefit from a structured, comprehensive, and clear way to understand and apply WCAG 2.1 Level A/AA to your web development lifecycle, please request a demo of WebAlign and let us show you how it can help in designing, creating, and maintain accessible web content.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “First Steps to an Accessible Website (Part 6)”