Designing with Dynamic Type, System Styles, and System Color in Play.
As one of the leading smartphone providers in the world, Apple serves a large range of users with a variety of ability levels. As such, Apple has prioritized making sure their systems are inclusive by design, so everyone has access to their technology.
Apple makes it easy to ship accessible products, and Play makes it easy to design and test those accessible products prior to production by tapping into Apple’s own technology.
Why should I care about accessibility?
Apple provides accessibility guidelines for iOS app designers and developers, but the product teams have to choose to implement those guidelines into their apps, which isn’t easy in most design tools. Why should product teams care about accessibility when, in theory, it adds work onto their plate?
Simply put: prioritizing accessibility increases your potential customer base and enhances your users’ experience. Those should be two of the biggest goals for all product teams.
An improved user experience
User testing accessibility early in the design process improves the end-user’s experience. Because you’re testing across ability levels in a personalized way, you’ll hear from more users about how your product works across scenarios. For example, B&W for color blindness or Dynamic Text for the visually impaired.
Tapping into a user’s actual accessibility settings will make your prototype more familiar and authentic to the user. For example, if they’re used to using Large Text for easier readability, having a prototype with the same Large Text is 1:1 with their usual experience.

It’s similar to using real data for user testing—the more familiar you make a prototype, the more authentic it will feel to users. The more authentic the user feels the prototype is, the more genuine (and more helpful!) user feedback will be.
Better for business
Getting insightful, in-depth feedback early is incredibly valuable to a product team. If that feedback is digested and implemented correctly, the product will be noticeably better. That in and of itself is enough of a reason to test accessibility, but let’s not forget about the benefits from a business perspective.
If you forgo early accessibility testing in favor of testing accessibility in production, what happens if users find your product to be inaccessible? You’ll have to change foundational pieces of your product after it has been shipped, leading to delays in shipping important updates as well as possible code refactors. All of that could have been avoided if you prototyped with accessibility in mind from the get-go.
By designing accessibly on day one, you’re saving time, money, and several iterations of testing. You’re also showing the world that you’re committed to creating an accessible product.
Using Apple's System Styles
When you use System Fonts and System Colors in Play, we’ll do the accessibility work for you by default. You’ll design one version using System Styles—or Custom Styles with Dynamic Text—for all your text elements, and when a user opens the prototype on their phone, the text will resize based on their personal device settings. If a user has extra large type turned on, all your different text elements will resize responsively exactly how they will in production.
With Play, designing for accessibility requires practically no extra work from you, the designer, but it makes a massive difference for user.
Apple recently announced even more accessibility features, including Accessibility Nutrition Labels on the App Store, Magnifier for Mac, Braille Access, and Accessibility Reader. We're excited to see how we can incorporate some of these features into Play very soon!
Best Practices
iOS