Accessible Components Case Study

This case study describes my exploration of alternative dropdown component designs for improved accessibility.

ROLE

UI/UX Designer and Front-End Developer

TIMELINE

February - March 2024

SKILLS

Figma, HTML, CSS

Introduction

In this case study, I examined one UI component and considered an alternative design that could increase the component's accesibility, potentially at the risk of learnability, memorability, or efficiency. The UI component I chose is the dropdown menu. I explored the accessibility of this component across devices and across modes of interacting with the device.

Problem

Many applications use default dropdown components, and many others have custom dropdowns. Regardless of who designed it, many dropdown components suffer from a lack of usability and accessibility, as I will explore. By understanding flaws with dropdown components in use in popular applications, I can practice designing with an alternative approach that prioritizes accessibility.

Input

I began by examining three applications with dropdown menus, including the EdStem website, the Appple Calendar web/mobile app, and the Starbucks website/mobile app. For context, EdStem is a message board platform that facilitates student, TA, and professor interactions in use at Brown University. I first explored how different modes of input, including the mouse/touchpad, keyboard, and touch (on mobile) enabled different interactions with a dropdown menus in these three applications.

EdStem Web App

Mouse/Touchpad

When I hover over "Filter", the button turns from gray to blue. Once I click on the button, the dropdown menu appears below the "Filter" button.
One feature that stood was that the button turns blue on hover, whereas neither Apple Calendar or Starbucks components change color on hover. This makes it easier for a mouse user to see that they are in range to click the dropdown menu button they want to press.

Keyboard

I had to press the tab key until "Filter" was focused, then I used the return key to open the menu. Then, I could use the up and down arrows to change which option was focused. When I pressed return, the focused option was inputted.
With my keyboard, I can't select the text in the dropdown menu. I tried Command + A, but it selected all the other text on the page except the text in the dropdown menu.

Touch/Mobile

On my phone, the dropdown menu comes up from the bottom of my screen, and covers the entire screen. From there, I can click on a filter, which closes the dropdown and applies the filter, or click "Cancel", which closes the dropdown without filtering.
If there are too many filter options to fit the screen height, I can scroll to see more options below.

Calendar Mac App/Mobile App

Mouse/Touchpad

When I hover with my mouse over the dropdown button, it does not change. Once I click the button, the menu appears over the button.
One gap in learnability is that the dropdown menu has an up and a down arrow on the button, while many users would expect only a down arrow. There is no text on this button, which not learnable but is efficient from a space perspective.

Keyboard

With a calendar event open, as I tabbed through the options on the editing window, the dropdown menu button was never focused.
This component not being navigable with the keyboard makes it unusable and inaccessible. This is a mismatch, since the dropdown can only be used with a mouse or VoiceOver.

Touch/Mobile

On my phone, the dropdown menu pulls up and covers the right half of my screen. I can scroll when the options overflow, click to the left to leave the dropdown, or select a calendar option.
This dropdown is more learnable than on desktop because the name of the current calendar is on the mobile dropdown menu button.

Starbucks Web App/Mobile App

Mouse/Touchpad

When I hover with my mouse over the dropdown button, it does not change. When I click it, it turns green and the dropdown menu opens over it.
Something that could improve efficiency would be adding a "Favorites" section at the top of the dropdown where users could save their preferred milk for easy clicking, since repeat customers often have strong milk preferences.

Keyboard

With my keyboard, I used the tab key to focus on the dropdown button, but when I pressed the return key, the menu did not open. I later learned that only with VoiceOver on, I could use the keys Control + Option + Space to open the menu.
Similar to Apple Calendar, I was disappointed that I failed to navigate into the milk dropdown with my keyboard.

Touch/Mobile

On my phone, the dropdown menu comes up from the bottom and covers almost the entire screen. I can scroll when the options overflow, click to the X to leave the dropdown, or select a milk option.
I appreciate that the Starbucks website and mobile app have similar dropdown designs. This makes the platforms more efficient and learnable for users who switch between the website and app.

Output

After exploring inputs, I also explored outputs from the dropdown menus on these three applications. The inputs can change the state of a dropdown component, and the output reflects these state changes to the user. I explored outputs including color, text label, focus order, and screen reader output.

	EdStem Web App	Calendar Mac App/Mobile App	Starbucks Web App/Mobile App
Colors	The "Filter" dropdown button turns blue on hover, which signals that this "Filter" text is clickable. Once the dropdown menu is open, when hovering over an option, it turns blue, signalling that it can be selected.	Each calendar is assigned a color, and the button's color changes to the color of the calendar selected. This increases efficiency, because users learn what color calendar they are looking for without needing to read the text in the dropdown menu.	Hovering over the "Milk" dropdown button on the Starbucks website on Mac, its color does not change. I don't find this color output useful, since when you click the button, the dropdown menu also appears, so you already know you've clicked the button.
Text Label	The button to open this dropdown menu is initially labeled with the text "Filter" and a downward arrow. However, after the user selects a filter from the dropdown, the text label changes from "Filter" to the name of the filter applied, such as "Unread".	On Mac, there is no text label on the calendar dropdown, only the color and the up and down arrows. On mobile, the button does have text (the calendar currently selected for the event). This text output verifies to users that they selected the correct calendar.	The dropdown button is labeled above it with “Milk” and the name of the current milk. The default is 2% milk, but if the user selects a different milk, the text label updates. Instead of a default, it should start as “Not Selected”, and the user shouldn't be able to buy the drink without selecting a milk.
Focus Order	Using the tab key, I can focus on the "Filter" dropdown button, and then use the return key to open the menu. Then, I have to use the up and down keys to switch between options, and the tab key does nothing. In addition to the up and down keys, I think the tab key should also work to switch between these options.	When I use the tab key inside this window, the dropdown menu is never focused on. This sends confusing outputs/signals back to the user. If they cannot focus on the dropdown menu, the application is signalling that it is disabled or not clickable, even though it is (and holds important functionality).	In the input section above, I found that I could focus on Starbucks' dropdown using the tab key, but could not use the keyboard to open the dropdown menu. Since the return key does nothing, the user might be confused and think that they have focused on the wrong component in their effort to customize their milk selection.
Screen Reader	On my Mac, I turned on VoiceOver and focused on the "Filter" dropdown button. VoiceOver reads out "Filter, menu pop up collapsed, button". When I opened the dropdown menu, VoiceOver read out "menu, ..." followed by each of the dropdown options.	When I turned VoiceOver on, I was able to use the tab key to focus on the calendar dropdown button. I turned VoiceOver off again and confirmed that I couldn't without it. This impedes acccessibility, because not all impaired users use VoiceOver, or a screen reader at all.	VoiceOver instructed me to press Control + Option + Space to open the dropdown. I tried this keystroke again with VoiceOver off, which did not work. Like Apple Calendar, Starbucks has created an accessibility problem by mismatching the needs of those that do not use VoiceOver.

State Models

After exploring input and output from dropdowns on EdStem, Apple Calendar, and Starbucks, I had several ideas about how to improve the dropdown components found in all three applications. However, this case study will focus on my redesign of the calendar dropdown menu in Apple Calendar.

Before beginning my redesign, I created state models to display the current interactions with Apple Calendar's calendar dropdown menu. State models show both the available states of the component, as well as the actions that transition between states. Below, the two state models display pre-revision interactions with the touchpad and the keyboard respectively.

Initial Calendar Dropdown Menu Component: Mouse User

Given that this is the state model for mouse interactions, the user's mouse position and clicks cause all transitions between states. Another important note is that "Open" means that the dropdown menu has appeared.
As shown in the state model, the dropdown menu stays visible even when the mouse leaves the area, but disappears if the mouse clicks outside of the dropdown menu area.

Initial Calendar Dropdown Menu Component: Keyboard User

Without VoiceOver, I was unable to focus on the dropdown menu button with only my keyboard on Mac. So, this state model is missing a transition from inactive to focused, although it should be noted that the button can be tabbed into focus when VoiceOver is active.
Once the calendar dropdown menu button is focused, then users can press the return key, up and down arrows, and escape key to transition between states, as shown.

As noted above, there are several areas of improvement for these state models. Below, I present two new state models for my revised calendar dropdown, with mouse and with keyboard. The main design change I made includes adding a "Confirm" button to the dropdown menu. I will explore and justify this choice alongside the Figma models further below.

Revised Calendar Dropdown Menu Component: Mouse User

The main revision I made was introducing a "Confirm" button on the dropdown menu. Now, after a user clicks one of the dropdown options, they also need to click "Confirm" to actually select their chosen option and close the dropdown.
If they do not select "Confirm" after clicking an option, and instead click away, their selection will not be submitted.

Revised Calendar Dropdown Menu Component: Keyboard User

For keyboard interaction, I added a transition from disabled to focused with the tab key, which the initial state model lacked.
This revised keyboard model also adds a "Confirm" button. Once the user has focused on an option, when they press return, their focused option is selected. This also automatically focuses on "Confirm", and the user can press the return key again to submit.

Component Redesign in Figma

This Figma model is my redesign of the calendar dropdown menu in Apple Calendar, which allows users to assign an event to a particular calendar. In the model above, this dropdown is opened with the button with the blue square and the up/down arrows, located in the event editing window. The model contains three frames, described below:

Initial State

The first Figma frame displays the initial state of my revised calendar dropdown menu.
This is the state before the user has interacted with the dropdown, so the dropdown button is visible but the dropdown menu window has not been opened.

Open, Option Highlighted State

When the user opens the dropdown menu and hovers over (or focuses on) an option, they will see the second frame.
Here, the dropdown menu is open and one of the options is highlighted. However, the user has not clicked on their selection yet.

Open, Option Selected State

This is a bonus state that is important to understanding my redesign. After the user clicks on (or presses return on) an option, that option turns dark gray, but is not yet submitted.
Instead, the user still must press "Confirm" to submit their selection and close the dropdown.

While not shown in the Figma models, one way that my redesign increases accessibility is by allowing users to focus on the dropdown with their keyboard but without VoiceOver. This interaction was surprisingly missing in Apple Calendar.

The only way that this change decreases efficiency is by adding one more component that keyboard users need to tab through as they explore the event editing window. However, this is an insignficant loss in efficiency that significantly increases accessibility.

However, in other ways, my revised component does increase accessibility at the expense of efficiency. Adding a "Confirm" button means that frequent users have one more click or key to press before they can submit their dropdown selection. But, this increases accessibility beacuse it means that users with impaired motor control are less likely to accidentally submit their selection. The extra confirmation transition allows users to accidentally select an option, but change their selection without the window closing.

Reflections

This case study was a valuable opportunity to intentionally design a component with accessibility as the main priority. When thinking about making components more accessible, it's useful to think in terms of mismatches, or situations where an interface creates unnecessary barriers for certain users due to a lack of inclusive thinking.

In my redesign, adding keyboard navigability addresses the mismatch where users that only use the keyboard can still interact with this component. Similarly, adding "Confirm" addresses the mismatch where some users may accidentally press or interact with these components, and the confirmation step accomodates accidental clicks.

Generally, the mouse is most often prioritized when designing components, as many designers are fully-abled. But, this means that they may forget to consider the needs of those whose abilities are impaired. So, in this case study, I learned to prioritize the needs of users with abilities different from mine, while considering carefully tradeoffs with usability.