The Importance of Mobile App Accessibility in a Mobile-First Digital Environment
Getty
Although the “mobile first” approach to prioritizing design elements for web content has been around for over a decade, the codification of mobile-specific international guidelines for making smartphone apps accessible to users with disabilities has been slow.
Perhaps former Google CEO Eric Schmidt never imagined it would take this long when he introduced the idea of “mobile first” design back in 2010. But it probably wouldn’t have come as a complete surprise to him that by 2025, 3.7 billion people (72% of the world’s internet users) are predicted to access the internet exclusively via mobile, according to the Global Mobile Communications Association (GSMOA).
Trying to address this design flaw is California-based Evinced, which specializes in building software that tracks and prevents digital accessibility issues. At the CSUN conference, the world’s largest focused on assistive technology and accessibility, held in Anaheim earlier this month, the company unveiled bold plans to kickstart a movement that it hopes will one day lead to official international guidelines for accessible mobile app design.
In fact, rather than just a lofty statement of intent, Evinced has already moved things forward significantly by creating and publishing a draft set of open-source guidelines that the company hopes will serve as a starting point for further collaboration and joint action within the industry. Led by Accessibility Lead Illai Zeevi, the Mobile Content Accessibility Guidelines 1.0 (or MCAG for short) are named after the globally recognized Worldwide Web Consortium Web Content Accessibility Guidelines, which have been around since 1999.
WCAG Gaps
Some may argue that important provisions regarding mobile accessibility were already included in WCAG, which has been updated several times since its inception. This is partly true, and especially with regard to WCAG 2.1, published in 2018, several important issues remain unresolved.
First, the basic WCAG template is over 25 years old and very close to the web-first approach for desktops and laptops, and new technologies such as native touchscreen apps are retrofitted to fit the principles of outdated technologies, rather than given the priority they should have. In fact, mobile app accessibility involves completely different considerations than desktop web accessibility. For example, a target button can usually be precisely activated using a mouse, but for people with poor eyesight, dexterity issues, or simply different finger sizes, it can be much more difficult to navigate on a small phone screen. Similarly, elements such as text spacing to make content easier to read for people with dyslexia can be done via a web browser, but must be coded specifically for a mobile app.
This speaks to a core problem: the current WCAG guidelines provide insufficient guidance to assist many mobile app developers in distinguishing between elements that apply more or less specifically to mobile app accessibility. In addition to this, mobile apps, like their web-based predecessors, will inevitably become more complex and feature-rich in terms of customization over time, so without dedicated guidelines, accessible design will continue to be an obstacle.
Finally, and perhaps most challenging, although born of good intentions, OS manufacturers such as Apple and Google (which run iOS and Android, respectively) provide separate accessibility guidelines on top of WCAG, muddying the waters and adding to confusion for designers. The same goes for various international regulatory bodies, which adopt different interpretations of which aspects of WCAG should apply to mobile apps.
As for the current patchwork of guidelines, Navin Thadani, CEO and co-founder of Evinced, explained in an interview, “For a while, WCAG, Apple, and Google all had different accessibility guidelines. In some areas, they complement each other, but in other areas, they contradict each other.”
He continues, “For a long time, there has been a body of knowledge about mobile app accessibility in the industry, but it was too disjointed and fragmented to be useful to developers. What we’ve set out to do certainly contains some original thinking, but for the most part it’s a combination of what’s in WCAG, Apple and Google.”
Working together
Thadani was equally clear on two very important points: Evinced has no intention of challenging the regulatory oversight of the Worldwide Web Consortium (W3C). On the contrary, Evinced’s ultimate goal is to incorporate MCAG into WCAG with an explicit emphasis on elements that are specific to mobile apps.
He rightly recognises that this mammoth undertaking can never fall under the jurisdiction of any one company, but rather must be a collaborative effort.
“We hope that the industry, our customers, and other players in the space will contribute to the development of MCAG. We don’t see this as an Evinced effort alone. It’s not something we want to have a monopoly on. We’re just putting the idea out there so the community can work on this. If there are any mobile accessibility experts who want to get involved, please join the MCAG group and help us work on this and get it ready to eventually push into WCAG,” Thadani explains.
This is where the contingency of the drafting timeline for web content guidelines may come into play: WCAG 3.0 will be released eventually (hopefully before 2030), but it is already being hailed across the industry as a paradigm shift for both accessibility guidelines and the types of web interfaces and hardware they apply to. This should give MCAG 1.0 both ample runway and a clear destination to take off with purpose.
