It’s time to make sure your app’s on-the-go experience is just as accessible as its desktop one, writes Seth Holladay (@SethHolladay)
‘Is your app accessible?’
This is a question you will hear at some point, perhaps from a potential customer, or a new hire, or even a lawyer. Developers have been working this problem since the early days of computers. But only recently have viable standards and best practices really come into their own. Now suddenly mobile traffic has taken off, exceeding desktop globally for the first time in November 2016, according to web analytics firm StatCounter, who among other things provide a free plugin for WordPress. Do we have to throw everything out the window and start over?
In principle, most of what you have already done to make your app accessible still applies to mobile. VoiceOver can make use of the tab order even though there is no physical keyboard. Proper page markup, such as using heading tags, will still make it easier to navigate. But the priorities, what works well and what doesn’t, are entirely different stories on mobile compared to on a desktop.
In practice, some key mobile accessibility issues include the size of tap targets (padding on anchor tags, for example), having a ‘Scroll to Top’ link where necessary, and even using the tel: protocol for phone numbers. Each fixes issues caused by small screens, or enhances UX by taking advantage of device capabilities.
There are also new patterns to avoid. Fixed positioning is a mess on mobile; it can cause content to go offscreen where it cannot be scrolled to.
Developers are abusing the ‘viewport’ tag to disable zoom, too. Please do not do this! In a survey I performed at Ai Squared, 49 percent of people reported being unhappy about some sites disabling zoom on mobile. It is rare, outside of games and maps, to need the user-scalable feature of the meta tag. You probably only need width=device-width and maybe initial-scale or minimum-scale . Zoom is crucial for people with low vision, and best left to the user and their device.
Notice that these topics are not as prevalent when discussing desktops, and documents such as WCAG and Section 508 have little or nothing to say about them. An app can pass an accessibility checklist and be in compliance with disability laws but still be hard to use. Mobile has widened this divide by introducing new situational challenges (sun glare, vibration and noise on a train) and new technology to misuse (high-DPI screens). By paying special attention to mobile, we can keep users happy and they’ll spend more time with us. Then we can proudly say that everyone wins.
“Section 508” refers specifically to Section 508 of the Rehabilitation Act of 1973, as amended by the Workforce Investment Act of 1998. The law requires Federal agencies to purchase electronic and information technology that is accessible to employees with disabilities, and to the extent that those agencies provide information technology to the public, it too shall be accessible by persons with disabilities.
AI Squared does Accessibility
Seth (@SethHolladay) is a full-stack software engineer and entrepreneur working to make the web a simple, happy place through open source.
– .net March 2017
Jim Thatcher wrote an excellent piece on the WACG and Section 508.
Section 508 of the Rehabilitation Act of 1973
The Web Accessibility Initiative Guidelines (WCAG)
A post on ACAT – The facial recognition program Stephen Hawking uses.