Select dropdown

Okay, let’s talk about selects and what you need to know about making a select right now. Notice this lesson isn’t entitled accessible selects. It’s called select, because if you make a select that isn’t accessible, you just made decoration, and that’s not what we’re here to do today. This information is adapted from atomically.com and thebookonaccessibility.com. Now, you’re not going to learn everything about accessibility today. What we’re going to discuss is just you need to know about select so that you can become alert to the fact that there is a right and a wrong way to approach these. And if you have questions, rather than trying to do something clever or strange that doesn’t work for anybody, you will seek out good information. By absorbing this video, we will create pathways in your brain that remind you for later that there is a good and a weird way to do this, and you want to choose the good way to do it. Just to be sure that we’re talking about the same thing, when we’re talking about a select. A select is a pop-out or drop-down menu that allows you to make a single selection from multiple options.

A navigation popover menu is not a select. These are different ideas entirely. A select relies on the operating system, styling and look and feel to create the pop-out menu. So it’s necessarily going to look a little bit different when it’s open if you’re on iOS or macOS or Windows or Android devices, they’re all different form factors, and That’s okay. The default experience is not a bad experience. We’ll talk more about that later. It’s important that we design our Select for everyone. We start by thinking about people with low vision. The reason why we start with low vision instead of screen reader, and I know everybody wants to talk about screen readers first because they saw that once and think it’s cool, and it is, is because so many accessibility issues begin at design and would be solved if we simply designed for people who don’t see that well, for people maybe who even would say they don’t have a disability, but they just increase the font size on their phone so they can see it better. Your text in the labels and in the input itself must have a 4.5 to 1 minimum contrast ratio against its surroundings.

Secondly, text must be able to resize up to 200% with no loss of information. Now, this is different from hitting Command+ on your browser and zooming in in that way. We’re talking about actually changing the font size in your device or browser 200% larger and still being able to consume all of the information. It’s also important that we design it for people with differences in color perception. For the rest of your life and career, you will be designing for people who can’t see all colors the same way. We can’t use color as the only means of conveying state, like selected or unselected, focused or unfocused. We have to look for other ways to convey that information. When we’re talking about people with motor disabilities, the first thing we want to think about is making sure that autofill attributes are documented. This is super important for people with severe motor disabilities who might be using their keyboard or a Switch device, which is something akin to a game controller, to control their device or computer. Autofill attributes allow things to autofill. It’s like when you go to fill out a shipping form and your information automatically fills into all of those slots, it’s because the autofill attributes are present in those inputs, your browser was able to inject all of that information automatically for you and you didn’t have to type it.

The Click and tap target area must include the label, and it must be no smaller than 24 by 24 pixels. That’s the minimum requirement to meet WCAG AA. If you want to be a good designer, you can make the Click or Tap target area include the label and be no smaller than 44 by 44 pixels. Now, the minimum requirement for making a Select meet AA requirements for focus is that the focus indication is visible in some way. But it’s much, much easier to focus on AAA requirements and have a focus indication that has a three to one minimum contrast ratio against default and adjacent elements. The reason for that is if you’re trying to do something subtle just to meet AA requirements, you have to create styles individual to every single input and decide how every single input looks in your design system. It’s much, much easier to make a blanket style that covers every single control or form input that meets AAA requirements. When we’re designing for people who are blind or very low vision, we’re generally talking about people who are using a screen reader. And so as a designer, it’s very important that you document the name, role, and any state for a select because those must be declared by the screen reader when the screen reader encounters your select.

And it must meet all of these criteria across platforms, devices, and viewports. Everything from a iPhone 5S with a 320 pixel wide screen to a 27-inch 5K monitor is included in devices and platforms that it must work on. For people using assistive technology like their keyboard or their screen reader in combination with a keyboard means that they’re going to use the tab key to move focus visibly to the input. They will then use the arrow keys to move focus to and choose the options within the select. The escape key closes the select and moves focus back to the select out of the options menu. The screen reader will output the name, which is going to be the label of the select. The select will identify itself as a select popup or menu submenu, a list box or combo box. If there are any hints or errors related to the Select, they will be automatically read after the label and the name and role and state of the Select. Each option within the Select menu will indicate whether it is selected or are disabled. A SELECT must have a visible label. Here you can see that the SELECT has a visible label with a for attribute pointing to the unique ID of this SELECT.

Do not rely on the first option as a label because once you have selected an option, that first option is no longer visible. This is problematic for people who might have a hard time remembering what the purpose of this input is. We need to talk about custom drop-down Select. It’s a popular idea to create a custom Select with a drop-down menu that you have complete design control over. While it seems like an attractive option to control the drop-down, instead of letting the device display the options menu, just don’t. If you don’t believe me, believe Sarah Higley. It is actually impossible to recreate the native behavior of a select. The reason for that is because, one, the semantics differ across platforms. It’s read differently in iOS, macOS, Android, Windows. The keyboard behavior is also inconsistent across platforms, and its presentation and behavior is completely different on mobile and desktop. When you make a UI control that’s custom and doesn’t use the native select, you’re taking upon yourself the responsibility of defining all of those semantics, presentation, the behavior. I have never seen a team successfully pull it off. You might launch with something accessible. However, given a few sprints later, someone will modify it and break it every single time.

Just don’t. Don’t try to create a custom drop-down select. Recognize use cases for Selects. Selects are good for logically sequenced options, things that are in, say, alphabetical or numerical order, or things that are logically sorted, like a filter. But don’t use Selects for items that are not in a logical sequence, that are unpredictable or difficult to sort. For example, if you have something like this ID number select, this is very, very difficult to find the ID that you’re looking for. Because the information from the select is hidden until it’s open, it’s very difficult to reference other material on screen. In this case, you might consider radio buttons instead of a select. It’s much easier to look at these radio inputs to find the the correct ID number because it doesn’t close, it doesn’t go anywhere. You can see them all at once and nothing is hidden by default. Okay, let’s discuss reasons to break the rules. When is it okay to deviate and use a different pattern for a select? Well, maybe you saw Apple or Google do this. Look, just because Apple or Google do something doesn’t mean that it’s a great user experience for people with disabilities.

In fact, it doesn’t even mean that they had people with disabilities in mind when they built it. Maybe your manager thinks it looks cooler this way, but if you’re not advocating for all users as a designer, as a professional, you’re not being a good designer. Maybe you’re on a tight deadline, but that’s also not an excuse to create something that’s not accessible. It doesn’t take any longer to make something accessible than to make something that is merrily decoration that looks like a select. If your devs tell you that it’s not possible to create an accessible select, I 100% guarantee you they are wrong. Now, with Select, it’s very tempting to use them because they do compact a lot of information into a small space, and it does allow you to get more above the fold in the view. But this is a very, very old idea. The idea of cramming everything above the fold comes from a time when users didn’t know how to scroll on the web back in the early 2000s. Look, I guarantee you your customers and users know how to scroll. Give people some credit, let your design breathe, and don’t use Select for places that they’re not meant to be used in.

You can reference this material more in-depth on atomically.com, and if you are looking for a place to learn how to create an accessibility program at enterprise scale, thebookonaccessibility.com is for you. Thank you. The end. Go forth.