Mhealth apps fail to meet needs of blind users, say Washington University researchers
July 28, 2015
Mobile-health applications are not meeting the needs of people who are blind or have impaired vision, according to researchers at the University of Washington.
In a paper published in the 2015 issue of the Journal on Technology & Persons with Disabilities, they investigated nine common iPhone mhealth applications that upload data from blood pressure and blood sugar monitoring devices. Accessibility shortcomings ranged from improperly labelled buttons to confusing layouts that don’t work well with iPhone VoiceOver or Android TalkBack services that read information on the phone screen.
“We wanted to see if these health applications would be out-of-the-box accessible, and most really weren’t,” said lead author Lauren Milne, a UW computer science and engineering doctoral student. “They made a lot of amateur mistakes that people make when they build apps.”
The researchers also concluded it would take little effort for developers to make mainstream health sensors fully accessible to blind smartphone users – largely by following accessibility guidelines already established by Apple and the US federal government.
“It wouldn’t have been hard to make their apps accessible by making that a priority in the first place,” said senior author Richard Ladner, a UW computer science professor who leads multiple projects to make technologies more broadly accessible. “They could have been heroes from the get-go.”
The research team – which includes co-author Cynthia Bennett, a UW human-centred design and engineering doctoral student – rated four iPhone glucose monitoring apps (iBGStar, Glooko Logbook, Telcare and iGluco) and five blood pressure monitoring apps (iHealth BP Monitor, Withings, iBP, MyVitali and Digifit).
They developed seven criteria for making apps accessible to low-vision users, borrowing from Apple’s guidelines to help app developers take advantage of the phone’s built-in accessibility capabilities and accessibility standards that technologies purchased by the US federal government must meet.
These include buttons that are programmed correctly to tell a user what to do with them, hints that help with navigation and grouping items so they make sense to screen readers that tell blind users what icon their finger is on or describe aloud what’s happening on the screen.
Those typically read from the top left to the bottom right of a screen. If an app hasn’t been laid out with the iPhone’s VoiceOver programme in mind, for example, a blood pressure reading of 120mmHg over 70mmHg and a heart rate of 80 beats per minute taken on September 28 might be communicated to someone who can’t see as “120, 70, 80, September 28, mmHg, mmHg, beats/minute”.
At the time the mhealth apps were tested in March 2014, one blood glucose monitoring app – the Glooko Logbook – met all the accessibility criteria except one. The other apps failed to meet at least half the accessibility guidelines. The study did not examine other accessibility features such as the ability to zoom or the use of large or high-contrast print, and researchers say it’s possible manufacturers have made accessibility upgrades to more recent versions of the apps.
In fact, when app developers simply borrowed standard iPhone operating system elements, the products were more accessible, the researchers found. When they designed custom elements, they rarely included the necessary information to make them work with screen readers that assist low-vision users.
“If people just used the basic widgets and things that Apple provides, they’d have better results,” said Ladner. “But the number of app developers has increased, and most of them are thinking about trying to make things pretty. They’re not thinking about all the users.”