Previously in this series, we discussed how to resolve conflicting accessibility best practices, and how we created a custom component library for a new mobile voting app named VoteHub. Here, we’ll talk a bit about the importance of trusting one’s users, and how our team created and iterated on the design for VoteHub’s accessibility settings interface.
VoteHub’s mission is to provide disenfranchised, absentee and UOCAVA (overseas) voters with the means to cast a ballot in an election. For VoteHub to properly serve these communities, our team’s designs had to take into account the various accommodations such communities may require.
At the start of building the system settings screen, where we present to a voter these accommodation options, I made an assumption: I hypothesized that displaying a list of named disabilities a voter could choose from and combine together, each mapped to specific settings values, would provide the most efficient way to quickly configure VoteHub for a voter’s display and interaction needs. For example, the first wireframes draft displayed a series of buttons, one of which was labeled with, “I have low vision,” that, when selected, would adjust a handful of settings to optimize the app for low vision users: font size, content density, contrast, etc.
During our time designing and developing VoteHub, our team had the privilege of several consultations with Whitney Quesenbery of the Center for Civic Design (CCD), a deeply knowledgable voting systems expert and one of the writers of the Voluntary Voting System Guidelines (VVSG).
During the first of our meetings, when reviewing our wireframes draft, Whitney told us, “Don’t name the disability, show [users] the option.”
Whitney’s statement brought problems of how large to set the font size, how much contrast would be needed, etc. to the fore: my UI optimization recommendation had introduced more problems than it solved, and in fact took control away from the voter rather than trusting and empowering the user to make their own selections.
Thanks to Whitney’s advice, we simplified the settings screen design, and its utility was vastly improved. Front and center, the screen shows the option to apply a user’s own system settings, which, for voters using a device already painstakingly set up to work for their needs, makes the rest of the screen’s options nearly unnecessary.
Whitney’s advice came in handy when evaluating other aspects of the Settings screen. A proposed component added to an intermediate draft was the Preview pane, which would show how newly-selected settings might alter the app’s appearance when applied. Ostensibly, its presence would be helpful for a voter using the older “name the disability” draft to evaluate what combination of listed disabilities might work best for them. After hearing Whitney’s "Show, don’t name” principle, however, we realized the pane was unnecessary.
We revised the design to immediately apply a voter’s selections, transforming the entire settings screen (and the rest of the app) into the “preview.” Removing the Preview pane reduced confusion—for one, about whether or not the setting in question had been applied and was just an unnoticeable change—and it had other benefits, too, such as when a voter whose first language is not English toggles the app’s language setting, and is then immediately able to see the screen and its options in their language.
How you present accessibility settings to users is as important as having them in the first place.
