Create Accessible Styles for Invalid Form Fields

Instructor: [0:00] In our field description lesson, we learned how to associate an extra description with a field alongside its label. Now, we're going to extend this to create styles for an error state on the field.

[0:12] As a starting point, we'll duplicate our descriptions and rename it to Validation. Then, navigate to that on our local server. The error styles we will be creating will be generic for you to add with your preferred validation solution and will be triggered by a single class, which we will call FieldError.

[0:29] We are adding this to the form group for the field we would like to mimic an error state for, which will be our street address. Now, we will add a new SaaS file that we will call Form Validation. We'll add this as the last item in our main SaaS file, and then we can open up our FieldError class.

[0:49] The first change we can make is to add the color property. We will pull in our existing custom variable for the color of Error. That has already made quite an impact by updating the label and description to red.

[1:02] An important consideration for accessibility is that we cannot rely on color alone to indicate that the field is in an error state. We will also be adding an icon, prior to the field description, and we're going to use an SVG background image. Within our field error class, we'll attach an extra field description set of styles. To prepare for aligning our icon, we will update the display method to flex and set align items to center.

[1:34] Also, our current red color does not meet 4.5 to one contrast, because we had previously reduced the opacity. We'll also within this rule, bring our opacity back up to one. What those changes mean there's not really a visual difference quite yet.

[1:49] To add the icon I mentioned, we're going to create it before pseudo element. It's going to be a little smaller than our font size and have a margin right to separate it from the description text value, and on Save, you'll see that the background image here is creating an X icon.

[2:07] One issue of using our SVG icon is that for the color which for this icon is being created via stroke, we cannot use the current color solution that we leveraged for the checkbox icon, in which case there was an inline SVG in the HTML DOM. We also cannot pass a custom property.

[2:27] In order to maintain the theme ability of this icon, we need a way to pass in our Sass variable directly. However, due to Sass processing issues, and the fact that an SVG uses a background image needs to be URL encoded, we're going to hop into our theme file and create a new function that will properly format our SVG.

[2:48] This function will intake a color value from our theme system, look it up with our previously created color function and URL-encode and format it for the SVG to use. I'll replace my temporary value of red within the stroke and we will temporarily to the new SVG color function and direct it use the error value from our theme color palette. On save, you see that adjustment has been made, and this will now continue to be themable by the primary theme's error color.

[3:17] An additional state that we need to be sure is styled is the focus state. Recall that on focus there needs to be at least a three to one contrast change between the default color and the focus color. That's why we are not changing the initial border-color, because we are going to change it just for the focus state to our new error color.

[3:38] In the mixin that's used to provide that focus state, we had defined that the border-color and the box-shadow will pull from the custom property of field focus. Within our field error class, we can simply redefine that field focus to use the variable for the color of error. On save, when I focus the field, it is now updated to using the red error color on focus, maintaining our contrast and emphasizing that the field is in an error state.

[4:05] To ensure that our field error class is extendable to all field types, we're going to copy the field set we created for the radio buttons and add that. In this case, since the legend is serving now as a label for the entire radio group set, we're going to add our field error class on the field set.

[4:24] On save, that gets us most of the way there, but in this case, we would like to update the border-color of the input controls, since we are using a slightly different method to apply the focus state, which we will keep as blue.

[4:38] Since we have a class of form-control that is used for radios and checkboxes, we will redefine the color default when within the field error class to use our error color. On save, we now see the border has updated to red, but we have still maintained our contrast because of the slightly different method used to apply the focus state.

[4:58] Just to round out validating that our error class works across field types and because we mentioned that color alone is not sufficient to indicate that a field is in an error state, let's add our field description to our radio field set, remembering to add an unique id to the field description and use that as the area described by value on both of the radio native inputs.

[5:23] Although we're not going to complete this process by adding any necessary JavaScript for validation, a best practice to keep in mind is that when there are multiple fields on the form that have an error state, when returning the user to the form.

[5:37] The first field that is invalid should be focused, even better is providing a list of fields that are invalid and supplying an anchor link for a user to quickly navigate to the invalid fields. If necessary, update or add the description text to emphasize that the field is invalid and what is required for it to become valid.

[5:59] In this lesson, we created the field error class, which provided a variety of updates to either a form group or a field set including updating the primary colors to our color error from our theme system, and adding an icon prior to the field description text since a contrast change is not enough to indicate that a field is invalid.

[6:22] We also made the choice to not update our field border until the field is in a focus state to also ensure that contrast remains a three to one color change. Similarly, with our radio buttons, we did supply the updated border color because our focus state uses an alternate method that still retains the three to one color change.