As a workforce management app, Assembled has an incredibly diverse user base. Customer support teams can be international, multilingual, and remote-friendly. Many agents work night shifts. Some may work with older or smaller devices than the ones used by developers who make the tools they rely on. They can also have a range of abilities that influence how they interact with technology.
Fortunately, inclusive design principles are baked into Assembled’s design system. Accessibility, in particular, routinely informs the UX team’s decisions about color palettes, component APIs and interactions, and even content guidelines. These tools help product engineers create inclusive features more efficiently, and they’re the building blocks behind many new features Assembled has released in the past couple years.
But some areas of Assembled predate its UX team, and part of our work involves replacing design patterns that inadvertently overlooked accessibility best practices.
This past quarter, Assembled’s UX Engineers improved the app’s compliance with accessibility standards as defined in the Web Content Accessibility Guidelines. Retrofitting an app is a big endeavor, so we handled it like we would any other project: delineating iterative milestones with mindfully scoped deliverables.
There was greater need for accessibility improvements on agent-facing workflows, so we prioritized the following features for the first milestone:
UX Engineers used Microsoft’s Accessibility Insights auditing tool to conduct automated and manual accessibility tests.
Here are some examples of the issues we detected and how we addressed them:
Not all users can navigate an app with a trackpad or mouse. Some may have limited dexterity, either temporarily or permanently, and rely mainly on a keyboard to interact with apps. Try using only your keyboard — press the Tab key to move between interactive elements on a page, and use Enter to select them, just like you would with a mouse. This simple exercise highlights how crucial it is for all elements to be keyboard accessible.
During our audit, we found links inside tooltips that weren’t accessible by keyboard; users could only interact with them by hovering over the link and clicking with a mouse. It’s easy to take these actions for granted until you're faced with something like a wrist brace or an arm cast!
Tooltips provide additional details about app features, and those should be made available to anyone who needs them. We updated our tooltips to ensure users can trigger them and click on any links they contain using the keyboard alone.
App content that doesn’t meet color contrast requirements may not be readable to those who find it difficult to perceive differences between certain colors.
Color vision deficiency affects around 350 million people worldwide (including 1 in 12 men). Some web browsers include tools to simulate different forms of color vision deficiency, and this is how we discovered that the “current time” indicator — which was just a thin red line — on agent schedules might be difficult for users who are unable to see shades of red.
We replaced it with a more prominent indicator that uses other design elements besides color to ensure it remains visible in lower contrast situations.
Accessibility best practices also consider the needs of people with cognitive disabilities. Designing for neurodiversity involves making it easier for users to process information. One of the improvements we made in this area was providing more descriptive error messages for email inputs.
Previously, we displayed a catch-all “This email address is invalid” message if the email entered didn’t match the correct format. Now we show messages that specify whether the email address is missing the @ symbol or a domain name.
People with visual impairments often use screen readers to interact with text content on electronic devices. This is why it’s important for inputs, buttons, and links to have descriptive labels.
There are many examples of interactive elements that do not have visible text labels. In these cases, engineers should programmatically provide accessible labels that are not displayed on the web page, but can be registered by screen reader software.
During our audit, we found text inputs that were missing both visible labels and hidden accessible labels. As a general rule, inputs should at least have one or the other. Otherwise, screen readers will announce a vague “Edit text” prompt when they reach these inputs. A user who’s experiencing vision loss may not be able to perceive visual cues, like layout or iconography, that signify what the input represents.
UX Engineers resolved this issue by giving these inputs accessible labels that identify the expected values to anyone relying on a screen reader to navigate the app.
Many of these updates have curb cut effect, meaning their benefits extend beyond the groups they were originally designed for:
Our next milestones include creating more accessible graphs and timelines. We’re also continuing to raise organizational awareness about accessibility.
Prioritizing accessibility makes apps more usable for everyone, but that responsibility shouldn’t be centralized within the UX team. The most scalable way we can make Assembled accessible in the long term is by equipping product engineers with the knowledge to build inclusive experiences themselves — and helping product leads understand why it’s important.