Supporting the iOS Text Size feature is a fundamental accessibility requirement of both the iOS Accessibility Guidelines and WCAG 2.2. This article will help you design for a broad range of information densities with efficiency.

Mobile devices have small screens. As text grows the number of lines needed to render text grows very quickly. Small changes in text size can result in dramatic changes in layout and appearance.

If you don't think carefully about your designs early on fixing these problems becomes expensive. Customers expect modern looking applications that are consistent with the experiences on their device. You want to set yourself up with a design process that evolves with the platform, not after it, and is accessible.

For those WCAG nerds out there check out Interpreting 1.4.4. The rest of this article is about techniques that can help you design for users who value different text sizes and information densities or have very small or very large devices. Maintaining structure in these situations can be challenging.

We'll cover:

1. An example of scaling from the App Store.
2. Techniques that will help you maintain structure and detail.

Let's go!

A Sample from the App Store

Before we discuss techniques a real life example will help make sure we are on the same page. Consider this these two screenshots of the Apple App store.

Notice the decisions that Apple has made on this screen.

1. They use minimal words. 33 throughout this whole experience.
2. The overall design of the card changes minimally.
3. Things get a little cramped in the Applications List.
4. They utilize text truncation... though it is available in the details later!

To truncate or not is a balancing act in Mobile Applications. Never truncating means losing structure that communicates as much information as the text itself. In this case we think Apple made a good decision to truncate. Particularly since the full text is available when you request details!

Minor mark against for letting the text get cramped on the larger text sizes.

Let's look at other techniques we can use to solve similar problems involving varying amounts of information.

Information Density

It is important to remember the varying motivations people have for Text Size preferences. Some users may want a larger font size because they struggle reading. Another user may prefer a smaller font size because they enjoy dense information with less scrolling. Yet another may just like the way applications tend to look when they use default settings.

Because mobile screens are so small minor changes in font size can result in dramatic changes to application layout. This concept is illustrated in the feature image for this article. Let's discuss it.

• The Left Side of the Image: Notice on the left how neat the Icon, Title, Subtitle lines up. All of the emptiness in the list view cells is meaningful structure that communicates the relationship between those pieces of information.
• The Right Side of the Image: This structure remains, however, many lines of text have been added. Much of this is due to the wasted space beneath the icon. It forces the text to render in more lines than necessary.

This is a simple issue we see in reviewing design systems. There are a few simple solutions you can follow that will simultaneously fix this problem AND allow you to fit more list items per page. Especially at lower information density settings!

Most designers start by considering the default middle ground settings. However, by forcing yourself to think about users on the far ends of the spectrum you save yourself time. The platform will facilitate much of your efforts on the in between Font Sizes if these two extremes are handled gracefully.

This leaves us with needing techniques to handle times when High Information Density and Low Information Density configurations lead to design conundrums.

Solution: Expand/Collapse Control

Expandable controls should be used carefully. Expandable controls are a good example of the mobile design concept of give users the information they need right now, but be careful not to hide necessary information. They also fall apart from a user experience standpoint when details are very long.

It is useful when your information has the following shape:

• Title - A Few Words
• Subtitle - A sentence or two.

A good real life example of this might be the ingredients for a menu item. Most users only care that they're ordering chicken parmesan. Those that care about the ingredients list will expand it to check for ingredients they are allergic to. Both users appreciate the "window shopping" experience of the simpler layout hiding this information brings.

Notice how we have changed the layout subtly for different information densities. You will hear across the ecosystem a slight prejudice against expandable controls. Both groups can be correct! This graphic illustrates that you don't have to pursue the same layout in all scenarios.

• Small Text(Left): We can see an icon, title, and subtitle lining up nicely in a list with 3 such items.
• Large Text(Right): We have opted to display just the title and a button that will expand to more details while fitting the exact same number of cards on screen in almost exactly the same layout.

By modifying our layout for the two Font Size settings we show respect for users preferences in a way that provides an equitable experience, particularly in regards to the amount of scrolling necessary for users with larger text sizes.

Solution: Modify Layout

Another potential solution is to create more space by changing the layout. Say you have cards that fit nicely in a 2 x 2 square, but they start to get cramped or lose their square shape as they grow. Instead of hiding information or converting to expand/collapse controls try changing your layout!

This is useful when there is enough text in your content cards where the 2x2 layout makes the cards very long on larger text sizes. This can mess up the structure of the information. Note that you can use a similar technique in the horizontal direction to support layouts that work well in landscape mode! More on that to come :)

Solution: Master Detail

The master detail solution is very similar in concept to the Expandable Control. However, the details are rendered within a separate experience, such as a modal dialog or even separate screen. This makes it more suitable for situations involving the following shape

• Title - A Few Words
• Subtitle - A Sentence
• Details - Multiple Paragraphs

The multiple paragraphs part is the thing that makes a Master Details flow a preferred solution. Expandable controls break down from a usability perspective when they contain too much text. They start to require a lot of scrolling.

Quick graphic breakdown:

• Small Text(Left): We have a master view with a title and a subtitle. When we activate it the Details modal shows the same title and subtitle on the top of the modal before rendering extended details.
• Large Text(Right): We have a Master view that only shows the title. When open the Details modal the same subtitle is the first thing we see after the main title.

Notice the red box around the subtitle! The trick that allows us to hide the subtitle in the larger Text Size version of this is making sure that subtitle gets emphasized in the Details flow. Otherwise we have saved Low Information density users time in exchange for denying them information, which is not fair.

Solution: K.I.S.S.

Another solution worth mentioning... and my personal preference, is to KISS your designs.

• Keep
• It
• Stupid
• Simple

By keeping your designs simple and saving large sections of text for the final step of the workflow none of these techniques are necessary. Your designs render well in all sizes and orientations... with maybe a need for a layout change here and there.

Focus your experiences on a singular purpose. Remember that mobile application experiences are like window shopping. Give users the information they need in the current experience, show them details when they are asked for.

Conclusion

Responding to Text Size adjustments in Mobile is essential. It serves both users who value larger text for reading purposes as well as those who value controlling the structure and feel of their application experiences.

Respecting the operating system defaults at various font styles and scaling factors is absolutely essential. Designing applications for such scenarios does not have to be difficult! Make it easy on yourself, start thinking about it early.