Use Sass Mixins to Style Inputs with Accessible Contrast and Keyboard Access

Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 3 years ago

We'll begin to apply our theme styles for our text inputs by creating the .form-field component. We'll make use of the Sass feature of "mixins" to create :focus and :disabled styles that can be reused. While creating the :focus and :disabled states we'll discuss the importance of contrast and keyboard access for accessibility.

An important take-away is that you need at least a 3:1 contrast ratio between your border and background AS WELL AS a 3:1 contrast ratio between your border and focus state.

Instructor: [0:00] In this lesson, we will complete the styling for our text inputs and text areas. We have already added the class of form-field to each of these input types, but we have not yet created styles. Our first step is to create the Sass file of form-field.scss. Before we move on, we'll need to be sure to import this into our styles file and we'll add it as the last import in our current list.

[0:28] After we open up our new class here, the first thing we'd like to do is update the border-color. Right now, it is inheriting the primary color and that inheritance is from the cascade. We need to go into our theme file and create a new color. This color we will call the default. We're using the term default to stand for the initial state of these fields versus the focus or disabled version.

[0:57] Like we had done for our color text where we used scale-color to create a variant of our primary, in this case, we're going to use our background-color as the base. Since we know that is quite a light version of our primary already, we're going to darken it a bit more by scaling back the lightness, and we'll also desaturate it by scaling back the saturation.

[1:18] Then we'll want to come down into our colors map and add that in as the value of default. Now, in our form-field class, we will add the border-color property and use that new default color. On save, you can see that's been applied.

[1:32] One of our important items for full accessibility of our fields is that we meet visual contrast guidelines. In this case, this border that is produced must have at least a 3:1 contrast with the background.

[1:47] The next set of styles we want to add is a custom focus state. Right now, on the nondisabled text input and text area, there is a blue border on my particular browser. Yours may be a different color based on user settings, but we'd like to go ahead and theme that focus state.

[2:04] We will go ahead and nest a selector for the focus. Because we're building this in a design system minded way, we will want to reuse some of the focus styles that we placed here. Instead of tying them specifically to the form-field class, we're going to create a new file to hold our form mixins. One way to use mixins in Sass is to group related styles that can be applied to multiple rules.

[2:32] Our first mixin will be for our field-focus, and we're going to update the border-color to use our primary theme value. We're also going to add a slight box-shadow and that's just a preference, so if you don't like the effect that it produces, you don't have to add it.

[2:48] Because we are changing the border-color, instead of using the default browser style, which is being added as an outlined property, we still do want to maintain an outline. We'll supply the transparent, so that it is not visible to most users.

[3:04] The reason we maintain an outline is that for users on Windows, who may be using Windows high-contrast mode, where the colors that normally are visible outside of high-contrast mode don't apply, the outline ensures that there maintains a visible focus on interaction with the field.

[3:22] We won't see this applied because we need to add the mixin into our focus rule. The way to do that is @include and the name of our mixin, so field-focus. We received an error and the reason is we need to also import our mixins. We're going to place the mixins after the theme import since we are using theme values within the mixins.

[3:46] On save, after that's been imported, once I click into the fields, where I can also tab, you'll see our focus styles being applied.

[3:55] Similar to how we discussed that the default border needed 3:1 contrast, there also needs to be 3:1 contrast between the default border color and the color that appears on focus. Otherwise, sighted keyboard users may lose track of where focus is being applied if that contrast is not significant enough.

[4:16] To wrap-up this lesson, we need to add a bit more styling to our disabled inputs, so that they're clearly differentiated from interactive inputs. Similar to our focus, we will scope this to our form-field class. We'll also want to create a mixin for these, as well, but once again, we need a few more feed color values.

[4:36] For our disabled themed values, we need both a border-color and a background-color. For these colors, we will scale them off of the default we just created, where the border is 40 percent lighter than that default and the background is 75 percent lighter than that default. Then, we'll be sure to add them into our norm.

[4:55] We can move into our mixins style, and now we'll add our new field disabled mixin, where we'll apply the disabled border-color that we just created, as well as the background-color. We'll also update the text color just in case the disabled field has a value. For this we'll use an alpha of black. Interestingly, disabled fields do not have to meet color contrast requirements.

[5:19] We also will add an extra visual cue of updating the cursor to the not allowed, which we'll see how that works on save. Now, we'll go back into our form-field within our disabled rule. Do an include of that new mixin. On save, we can see those styles applied. If I hover over the field, you'll see that not allowed cursor.

[5:40] The other thing to note is that a disabled input cannot be tabbed into. I'm using my tab key here. While we are providing styles for disabled inputs, it is recommended to simply not include fields that may be disabled, if at all possible.

[5:57] Screen readers are unable to interact with disabled inputs, which means they would not receive any information that you may be trying to present to visual users. You should seek out an alternative way to convey whatever meaning you are trying to provide with the disabled input. I've included it for purposes of completeness in our form styles, and also to be able to discuss the best practices around it.

[6:21] We will continue to create disabled styles for the rest of our fields, as well.

[6:25] In this lesson, we enhanced our theme by adding a color default value, which is applied as the form-field border for the initial state of a form-field. We learned that that means 3:1 contrast with the background. We also added a disabled border and disabled background color. All of these colors we added into our colors map.

[6:48] We then created our form-field class and included our new default color as that border. We also created mixins for the field-focus and the field disabled. In particular, with field-focus we learned that it needs to have a 3:1 contrast ratio with our initial field border-color. Also, that it's important to include at least a transparent outline in order to retain a visible focus for users of Windows high contrast mode.

[7:17] For our disabled field, we learned that it is not beholden to contrast ratio rules, and also, that it is not typically discoverable by users of assistive tech, such as screen readers.

egghead
egghead
~ 23 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