With Apple having announced this year’s WWDC, it’s time to start getting excited about what the next version of iOS will bring. Macworld has been compiling lists of features we’d like to see, covering (so far) Notification Center, Mail, Calendar and Reminders, and Photos and Camera.
Personally, all this speculation has me focusing on what iOS 8 might mean for the accessibility community. If you believe what Jony Ive said about iOS 7 “defining a new direction” and being “the next step,” then iOS 8 stands to give more clarity to Apple’s vision for its mobile operating system.
Since iOS 7 debuted last September, I’ve spent much time—both writing and on the air—talking about the accessibility ramifications, good and bad, of iOS 7’s visual redesign. My feelings towards it are mostly mixed, as there are several elements of iOS 7 that are markedly worse when it comes to accessibility than in previous iOS versions—for example, buttons. On the other hand, there are also things that are markedly improved over earlier versions—for example Larger Dynamic Type. But it’s time to look ahead to iOS 8, and to point out the accessibility issues that I hope Apple addresses.
Refine interface enhancements
The best way to describe my love/hate relationship with iOS 7’s design would be that it leans too far away from the hyper-realism of iOS 6. iOS 7 is opinionated to the extreme, and I strongly believe Apple would do well to dial it back—to find a happier medium between the disparate design ideologies. As a person with low vision, I’ve found iOS 7 to be more difficult to use due to its penchant for lower-contrast icons and text labels used as buttons. So there are a few things Apple could do to make iOS 7’s UI more visually accessible.
Bring back real buttons. iOS 7’s button design is, without a doubt, my biggest beef with the new design. It takes what appear to be untappable bits of text and turns them into web-link-like buttons. While a case can certainly be made that Apple took off the training wheels, so to speak, with iOS 7’s button design (for example, by doing away with the obvious Back button), this design decision was decidedly more aesthetic than functional.
In accessibility terms, there are two problems with this “buttonless” interface. First, there are no borders or shadowing, which can be problematic when trying to differentiate between the content of an app and its controls. Second, this lack of definition makes it difficult for those with vision impairments to say, Oh, I can tap this, because so many buttons, system-wide, appear to simply be text or text labels.
To Apple’s credit, iOS 7.1 added a Button Shapes option that, when enabled under the Accessibility options in the Settings app, put a shape around buttons. It’s a welcome (re-)addition that attempts to solve the issues with contrast and identification, but it feels like a hacked-on afterthought and belies the elegance of the new aesthetics.
I would rather Apple redraw the buttons so they look like native parts of the UI. Specifically, Apple could take some of the design cues of segmented controls (such as those as seen in the Top Charts section of the App Store) and modify them to work as general navigational controls. Even those thin lines provide enough contrast (for me, anyway) to be able to distinguish buttons from normal text—and I think such an implementation would look nicer than Button Shapes does today.
Make all share sheet icons obvious. iOS’s share sheet—the popover that provides options for sharing content—contains familiar app icons for Messages, Mail, Twitter, and Facebook, but the non-app-specific actions in the bottom row (Bookmark, Copy, Open In, Print, and the like) are barely discernible. The white-and-gray glyphs of these icons use far too little contrast, which, for people with low vision, makes identifying these options extremely difficult—and, thus, not at all accessible. Apple should take a cue from the Settings app, where every major function is denoted by colorized icon preceding a text label, and apply that style to the share sheet
Restore some texture and shadowing. Say what you will about skeuomorphism, but it’s my strong opinion that the design of iOS 6 and before were underrated in one major area: accessibility. There was a lot that the “classic” iOS did right in making the user interface accessible for the visually impaired (even if not always intentionally). For example, button design and iconography stood out, making it much easier to navigate throughout the system. In this respect, iOS 6’s glitz and heavy polish was a benefit for users like me who do better with big, bold buttons and the like.
With iOS 8, I hope we see a bit more more texture and shadowing in the interface. When it comes to accessibility, iOS 7 went a few toes over the line. Apple would do right to find a balance between 6 and 7.
Clean up the accessibility options
You don’t have to be visually impaired to have had issues with iOS 7’s design. In response to criticism levied by customers, Apple added several options to the Accessibility section of the Settings app to placate those with usability concerns. While those settings were welcome, the result is that the Accessibility section has become bloated and a bit unwieldy to navigate.
On the one hand, it’s commendable that Apple is listening to users and acting accordingly. On the other hand, this “throw a setting at it” approach puts Apple in an unfavorable light. By cramming Accessibility chock-full of options to compensate for the user interface, the company is tacitly admitting that the design it so championed last summer isn’t as grand as claimed. (Button Shapes, in particular, is the most damning, because it shows that Apple realizes text alone does not a button make.) The plethora of options here also makes iOS a more confusing to use.
So I’d love for Apple to not only tweak iOS’s user interface to make it better for everyone, but to subsequently trim some of the fat from Accessibility. That would be a win-win.
Make accessibility more of a design principle
iOS and the devices on which it runs epitomize the phrase “mass market.” On the other hand, when it comes to sales, the accessibility community epitomizes (for better or worse) a niche market. While Apple’s done extraordinarily well in serving the needs of its disabled users, the fact of the matter is that iOS 7, in a number of ways, alienated many in this group. It’s untenable to be all things to all people, but the starkness of iOS’s redesign made the user experience considerably worse—I know I’ve struggled with and lamented iOS 7 more than any previous version.
Simply adding more accessibility features, and expecting those with special needs to find and enable them, misses the forest for the trees. Broad and deep though they may be, Accessibility options alone can’t and shouldn’t fully compensate for the inherent problems of a design. I don’t want to rely on a bunch of settings as a crutch because the out-of-the-box presentation is riddled with problems. At some point, you turn on so many features that, in my opinion, you lose much of the original user experience—and you can’t solve every accessibility issue by posthumously adding new settings.
The bottom line is that accessibility should be a major part of the design process from the start. Make the interface the best it can be from the get-go, and you won’t need to later capitulate by throwing everything but the kitchen sink into a screen full of settings (and hoping it works out). As a bonus, while not everyone user needs a fully accessible interface, many interface elements that made a device more accessible also make it easier to use for everyone.
Bold but rough
On the whole, I love Apple’s new vision and direction for iOS. But the first step, iOS 7, was more bumpy than I would have liked, and I believe that it would behoove Apple to keep in mind the needs of the accessibility community in future updates. More than any features wish list, I personally hope that at WWDC next month, Craig Federighi previews a significantly tweaked UI that takes into consideration feedback like this—and like so much other I’ve given over the past year.