Often as digital product designers we consider our job to be entirely tied to the visual medium, and spend most of our time gauging the proportions of elements on the screen, what kinds of tactile actions a user can or should be able to perform, and how best to optimize our product’s intended function, look and feel.
In designing a mobile app meant to be optimized for use with screen readers, however, a different design paradigm fast becomes a necessity: to at times treat the app as much a temporal or verbal script as a visual one. Thinking in terms of duration, syntax, and narrative was essential in Nearform’s work designing and building the beta version of VoteHub, an app that provides disenfranchised, absentee and UOCAVA (overseas) voters with the means to cast a ballot in an election.
If you missed the other articles in this series, we’ve already discussed how to resolve conflicting accessibility best practices, how the presentation of accessibility settings to users is as important as having them in the first place, and how simple language is a tool for designers, not just users. For more information about how our team’s engineering work addressed accessibility, take a look at Eli Zibin’s article explaining how we fast-tracked accessibility for VoteHub by way of a UI primitives component library built in React Native.
And if you’re still following along, listed below are some lessons we learned working on VoteHub, about how, where, and when to introduce information for working modalities like screen readers.
Be careful about order
The order in which text is presented is in some cases of higher accessible concern than the visual hierarchy in which it’s presented.
Take the humble and ubiquitous input for example. We’ve learned that it’s important for inputs to have labels; that those labels should be distinct from placeholder text; and that oftentimes it’s very helpful to have hint text accompanying an input so the user knows what format or type of content to enter. They should appear to be tappable, and have distinct styles applied when focused or active.
After a series of trials with users that rely on screen readers to aid them in using their phones, we discovered that for a screen reader user to know what to enter into an input, it was far more efficient to place the input label before the input area.
Following the same principle, we placed input error messages after the input label and above the input, so that when read aloud, a screen reader user would hear, for example, “Select State; Error, your state is required; No state selected” — or put differently, “Here’s the request; There’s an error in fulfilling the request; Here’s what you’ve done to fulfill the request.” In some ways, this pattern parallels a lesson we learned in workflow wayfinding, where to best orient a user, we state what the user has done so far, what the current state is now, and what the user can expect to come next.
Using the input label example to draw a more general conclusion about designing for screen readers, it’s very helpful to frame the exercise in terms of a narrative spoken track (or even musical score). Ask yourself the following questions to help get yourself into the mindset of a screen reader user:
- What will the user hear next?
- Have we sufficiently prepared the user to perform the next task?
- Are all primary user actions placed in a top-level position, and are they in a meaningful order?
- Will the user know they’ve encountered an error or are running out of time to perform a task?
Be careful about text length
In the third piece of this series, we touched on the importance of clear, concise language. An obvious and important note worth mentioning here: Every bit of text in an app can or will be read by a screen reader, so the more to the point the text is, the less time it takes to traverse that text.
Be careful about the duration of tasks
With VoteHub being a proposed true alternative to mail-in and/or absentee ballots, it’s unsurprisingly a fundamental concern of the product to ensure voter anonymity and security.
The Voluntary Voting Systems Guidelines (VVSG) are a set of security, usability and accessibility standards, that any system designed to be used to cast and record a vote in a U.S. election is tested against. As part of its security requirements, the VVSG outlines a timeout feature necessary for any voting system, wherein if a voter performs no actions with the screen for more than a given period of time (they strongly recommend only 1-2 minutes!), the voter must restart the process. This is of course meant to protect the voter against any malicious actions performed in their name—and a serious constraint on the duration of any given task performed after a voter has confirmed their identity and, in our case, authenticated themselves with a One-Time Access code. So we got creative.
By reorganizing the workflow into two parts, into screens requiring authentication and those that didn’t, and placing the unauthenticated parts first, we helped guarantee that, at the stage when a voter might be looking for ten minutes for valid forms of identification, they won’t lose their place or entirely abandon voting. The concept of “barriers to entry,” where we clear an individual for voting by asking all the “dealbreaker” questions up front, was recommended in part to resolve the frustratingly brief timeout window we had to enforce during the authenticated workflow sections of ballot marking, affidavit signing and ballot casting.
In addition, by breaking larger user tasks into smaller pieces, we helped ensure the voter was interacting with the app sufficiently to reset the timeout feature.
Do your best for the user, even when the ideal isn’t possible
One unavoidable risk of abandonment by way of the timeout is a rather complicated checking feature a voter can opt to perform to confirm the authenticity of their ballot (that it’s been recorded as they marked it), which requires the voter to use a browser either on their device or preferably on a separate one. During a ballot check, the app is left running in the background, and could time out at a critical point of the voting process if the check takes longer than the timeout’s duration.
As stopgaps in what seems to be a bit of a functional detente between usability and security, we implemented a warning notification that informs the voter their session is about to time out, and when timed out, place them at a workflow re-entry point for re-authentication that’s nearer to ballot marking. Not perfect, but good enough.
Conclusion
Good accessible design will look different for every product, and requires not just application of best practices, but evaluating those practices against the product users’ needs and making adjustments if necessary. In other words, accessibility assumptions about your product and its users will only go so far. Getting designs, prototypes, and builds of your product-in-progress into the hands of people—especially those with disadvantages—is the best way to save time, energy and money, get answers to your assumptions, and most importantly, produce something that truly serves your actual users.