Text Resizing - Flexible Components for Improved Accessibility
By James Carleton and Kiersten Lammerding
Products that work for everyone
Accessibility is a hot topic in the mobile app world right now. If you’re not familiar, accessibility is a product design and development principle that aims to provide inclusive digital products which work well for everyone, no matter their abilities. A simple example of accessibility in practice is ensuring a high contrast ratio between text color and its background color. Think about grey text on a white background, this combination’s low contrast makes it difficult to read for many customers. Increasing that color contrast will make it more legible. Everyone will benefit from well-designed text in user interfaces but it’s especially important for folks with colorblindness, glasses, or other vision challenges.
Although accessibility is not a new topic, it has recently been given a big boost in the mobile app development community. At this year’s sessions of Apple WWDC and Google I/O these leading companies spoke about new accessibility features in their operating systems and apps with greater emphasis than ever. This is great news for champions of accessibility like us. Instead of treating it as an optional add-on that’s nice to have, app developers are now starting to prioritize it and even use it as a strategic advantage.
According to WHO, 2.2 billion people globally have at least one type of visual impairment and we estimate 20% of our 400 million PayPal customers have some type of disability. Types of disabilities include visual, auditory, motor, neurological, or others. Because this is such a big and diverse audience, the methods we use to support them in our PayPal products are not simple. We can’t address just one aspect of the accessibility needs and call it done.
As we build digital products at PayPal, we iterate features over time. Our recent work has made good strides to improve the accessibility of our native apps (iOS/Android). These include increasing default font sizes, designing with greater color contrast on text and controls, and supporting non-sighted usage. As our team planned for a big new initiative, a redesigned PayPal consumer app, we looked for the next opportunity to improve accessibility for our customers. One feature stood out as a valuable goal we should aim for: supporting text resizing in our apps.
What Is Text Resizing?
Text resizing is the ability for the user to adjust their preferred font size in their device’s operating system preferences. A variety of users make this adjustment to improve their ability to read small text on a small screen. Once this setting is adjusted, the platform and any apps that have built-in support for this feature will resize displayed text. Check out these examples of how to adjust these text and font resizing settings in Android and iOS platforms. Pro tip: If you don’t already use these settings, grab your phone and try it right now. As we all know, it’s good to put yourself in your customer’s shoes. Plus it’ll be good practice because most of us will find the feature helpful eventually.
Discovery in action
Like many apps in the industry, earlier versions of PayPal didn’t support text resizing. When the user adjusted their system settings for font and text size in iOS or Android settings, our app didn’t recognize or respond to those preferences. It was time to fix that!
To start the work we gathered a focused team made of members from our accessibility team, design system team, and product teams whose roles included Product Management, Engineering, UX Design, and Content Design.
We began with an audit to evaluate the landscape. We studied a range of apps from competitors, both in fintech and adjacent industries, as well as those made by the platform makers iOS/Android.
We discovered a wide range of results. Some parts of platform default apps would respond while others did not. For example, the Segmented Controller component on iOS didn’t change when resizing was activated.
We found a few good examples that stood out. A leading superstore’s app dynamically adjusted the layouts to facilitate text resizing, which pointed us to an insight: spacing and container sizing must adapt along with text resizing. When text size is increased, the containers holding it need to adapt to avoid cutting off or truncating text too early.
We also saw bad examples. Popular apps that many of us use daily didn’t support text resizing at all. We hope sharing this story will encourage other apps to improve support as we now have.
Collaborative experiments
Once we understood how text resizing worked in outside apps, we examined our own to identify the scope of our opportunity. We reviewed each section of the app experiences to find which parts of the interface could be potentially resized. These included the obvious text headings and paragraphs but also the more complex controls like action buttons, navigational components, dashboards, and marketing promotions.
Instead of making design decisions in isolation we gathered our team and started experimenting together. Engineers boosted text sizes as a quick test and we immediately saw that text grew outside the borders of the button container. To keep things in their containers we had to remove fixed size constraints that we previously relied on and step into a more flexible and responsive approach. With some adjustments, we defined the flexibility of containers so that when text size increases, the container resizes around it.
With the containers in good shape, we then saw some examples where a single button now had 3+ lines of text inside. This would use too much vertical space on the screen, reducing the quality of the user’s experience. We reached a decision point: do we retain every character of the text at these large sizes or limit the expansion with truncation? Truncation is where a phrase or sentence is abruptly cut off to fit available space, often indicated with three dots. This sentence is truncat …
Considering how large text content flows into additional lines we hit a key insight: We needed a clear rule to decide how wrapping and truncation work together when text is resized. We knew that some cases will require truncation but we wanted to minimize its use because it can severely impact the comprehension of the text. With resizing causing wrapping to multiple lines and translation adding even more length in verbose languages, you can see how things could get messy very quickly. So the team experimented with the balance between preserving text as much as the layouts allowed using wrapping and truncating when the layout would break. We created a guideline that stated that a) text should wrap by default, b) containers should adapt to the multi-line text, and then c) text should truncate only if needed after a and b are applied.
Next, we asked, how big is too big? We needed to set limits on the scaling range. Default thinking might suggest supporting text to get as big as accessibility settings will allow. However, as part of the recent redesign, we had already increased the baseline text sizes. This was a positive and fundamental step toward improved text accessibility with the app at the default settings, 100% text size. As a result, our range of type sizes are overall larger than industry standards. Starting with large sizes raised a challenge specifically with our really big text sizes called “Heading” and “Display.”
When in doubt ask the experts. WCAG (the source for accessibility standards) suggests that text should scale to 200%. However, they don’t explain 200% of what? And if your baseline is already increased, how do you factor in that adjustment?
To set up our default sizes (100%), we used the smallest size in our set Caption (14px) plus our Body text size (18px) and doubled them to establish a max size of 200%. These sizes became the min and max for our resizing scale for most text. We then applied this thinking to ‘Heading’ and ‘Display’ sizes, which are used less frequently when we highlight important titles and numbers but we didn’t like the results. Scaling these to 200% caused a mess. Imagine a word so large only one letter fits on a line.
A quick fix would be to make an exception and not resize these already large sizes, but then the visual balance would be off between the upsized body text and its fixed headline size, reducing reading comprehension. Our proposal was to scale the different font sizes at different proportions. The results were setting our maxes to 200% for the first few sizes (Caption and Body) and then max our heading scaling to 150%, and our largest, Display size to a max of 125%. This proportional scale treatment allowed the range of sizes to grow in a balanced manner while improving readability at the top sizes.
The Nitty Gritty
Collaborating on the design definitions between our design and engineering staff gave us a head start on implementation. Rough specs were provided in our cloud-based design tool, Figma, which enabled us to provide flexible guidance without mocking up every instance in a tedious manner. As the team had conversations and made decisions, the specs became more refined and our documentation was filled out.
Our design system component libraries are built in an atomic structure, meaning simple parts are combined to make the more complicated ones. This enabled us to make decisions about resizing of text in foundational parts, like a text input field, and then quickly reuse those decisions other components like dropdowns, lists, and menus. Pretty soon we had a plan for a wide range of UI elements used in our apps.
As we reviewed engineering builds of the upgraded components, we checked how they looked and performed using demo apps. Since our team was distributed due to Covid work from home protocols, we weren’t able to share our testing phones, as usual, so we utilized the next best thing, simulated devices. Both iOS and Android let you use an emulated phone on your computer which is a valuable tool for testing coded app experiences.
Because we wanted to try our resizing features on a range of devices with different size screens, we were looking for devices that were not available in the emulator. A specific concern was emulating Samsung models, the most common devices used on the Android platform. We found a workaround in a virtual web-based emulator. This helped but getting properly scaled screenshots from it posed further challenges. Although not perfect, we were able to get enough details from these simulated devices to critique and refine the new text resizing features in our UI components.
Our final and critical step will be to apply these new parts to our product experiences. We’ve shared the revised UI components with the feature teams who will apply them to the real layouts and content that make up our consumer app. In addition, each team will be applying our resizing principles to any content built in conjunction with components.
Going forward
We are in the process of designing and building accessible components that improve the way our diverse customers experience PayPal’s products. Once the iOS or Android app versions are updated you will see that the size of text changes with your system preferences.
As a team, we’ve learned a lot along the way, enjoyed working across disciplines in new ways, and built a great foundation together. We know this one feature won't completely solve accessibility for our big and diverse customer base. This challenging work will continue, but improving accessibility is a challenge worth taking on. Even small steps are rewarding when we know that real people will be impacted with each iteration.
Thanks for following along and let us know what you think.
