Tim Cook started the most recent Apple event with a bold claim that “Technology should be accessible to everyone.” He then unveiled a new accessibility site that allows you to explore all the accessibility features built into Apple’s many products. They show you what these tools look like in the real world. You get to see the people whose imaginations are set free from the confines that traditional keyboard/touchscreen inputs would place on them. To quote from one of these powerful videos, “When technology is designed for everyone, it lets anyone do what they love.” Apple really believes apps should be for everyone. They have invested heavily making this not just a talking point, but a reality. More than anyone, they pay special time and attention to making sure their own apps are completely accessible to all audiences.

And yet many developers only think about accessibility (AX) as an afterthought. Some just assume that it probably just works fine as is (and Xcode does try its best). Some think that implementing accessibility seems too daunting a task. Others just put that idea in the icebox of “nice to have” feature ideas. The truth though, is that implementing app accessibility does not have to be hard. In fact, just like localization, it is much easier to do as you go.

Do the work when it’s still easy

My wife and I don’t see eye-to-eye on when to comes to cleaning the dishes, and the following story is used with her kind permission. She will make the macaroni and cheese for the kids and then portion it out on plates. And then, despite my best efforts, leave that pot sitting on the stove to become a hardened mass of yellow noodles. I take a more enlightened approach. When I start to portion out the molten cheese mess, I get an extra paper plate, and put whatever is leftover on that plate. Then I immediately rinse out the pot of the sticky cheese-like substance while it’s still warm. It’s so easy. It rinses right off. No scrubbing needed. Nothing to come back to later. Make your life easier. Do the work when it’s easiest to do. Your future self will thank you.

The same is true when it comes to accessibility. If you put off just basic support of localization and accessibility features, there is a good chance that it is going to get real messy when you get around to it. It’s going to require a few hard to explain sprints, and you’re going to be scrubbing through every bit of your code to make those checks. Implement it as you go. It will be so much easier.

First, let’s cover the mindset that you need to be thinking through as you go through your code that will help you in covering a large percent of the cases that are easy to mess up. Keep these ideas running in the back of your head to keep your code from turning into that inflexible mass of cheese-covered starch.

A few simple questions to keep in your run loop

credit to Chris Morris

• Do I have a fixed number of lines? Can I defend that? Why isn’t it 0?
• Can text wrap, truncate, etc.? Think about the large text.
• Can the screen scroll vertically? It probably will when the text gets large.
• Did I just change the normal behavior of a system object? You will need to set the UI AX Traits.
• Was there an update to some part other part of the UI? Make sure to update Voice Over.

Your new best friend, the Accessibility Inspector

Keep these ideas in mind as you do development. They will help you flag places where you might need to do some AX work. Often times, these are places you just need to make your design more flexible and be able to handle larger fonts. An easy way to see how your designs break is to use the new Accessibility Inspector.

New for iOS 10 and Xcode 8, Apple developed a tool to help us check that the properties on screen are being set consistently with their intended usage. Use it to make your fonts slightly larger. Does that break everything? Is it a design problem? Or is that an opportunity to be a bit more creative and relative with your constraints? Usually what you’ll find is that it breaks things in very helpful ways. Things that were probably too fragile.

You don’t always have to fix it for all the edge cases, and perhaps due to time and budget constraints you can’t address the issue. That might be OK, but you are far better off knowing your own issues than being ignorant of them.

Over the next few blog posts, we’re going to give some tips to get 80% of AX done on the way as you go, and then some helpful code for tackling that tricky last 20%.

Those tips will take you toward Apple-Like Accessibility Zen in your app. Maybe that’s all you can do for now. That’s great! You are way ahead of most developers. Then, when your team is ready to tackle that last 20%, we’d like to offer a few bits of code that we’ve used to simplify implementation of some of the more edge cases and rough spots that still exist in Apple AX implementation. Stay tuned for Part 2!