https://medium.com/airbnb-engineering/rethinking-text-resizing-on-web-1047b12d2881

Open in app

Sign up

Sign in

 
[                    ]
 
Write
 

Sign up

Sign in

[1]

Rethinking Text Resizing on Web

 
Steven Bassett
 
The Airbnb Tech Blog

Steven Bassett

*

Follow

Published in
 

The Airbnb Tech Blog

*
12 min read
*
4 days ago
 

--

2

 

Listen

Share

Airbnb has made significant strides in improving web accessibility
for Hosts and guests who require larger text sizes.

This post takes an in-depth look at:

 1. The problems encountered on mobile web when relying solely on
    browser zoom.
 2. The challenges of introducing changes that would impact the
    workflow of all frontend engineers.
 3. The benefits seen since launching these accessibility
    improvements.

by: Steven Bassett

Improving web accessibility is a critical priority at Airbnb, and we
use the Web Content Accessibility Guidelines (WCAG) to help guide our
compliance efforts. One area that often leads to accessibility issues
is WCAG 1.4.4 Resize Text (Level AA). This guideline, which we'll
refer to as Resize Text, is particularly beneficial for people with
low vision, whether correctable or not (for example with glasses or
prescription contacts). The standard specifies that web content and
functionality must be maintained when text is scaled 200% (2x) of its
original size. Ensuring our site meets this guideline is an important
part of our ongoing work to enhance accessibility for all of our
users.

In this blog post, we'll explore our investigation into the
importance of this guideline, how we analyzed our site issues, the
technical benefits for using rem units, how we decided on an
approach, the cross-browser support issues we encountered, and the
benefits we saw in reducing the number of reported issues for Resize
Text.

Meeting the Needs of Users with Vision Difficulties

    "90 million Americans over 40 have vision and eye problems.
    That's more than 3 in 5."

Looking Ahead: Improving Our Vision for the Future" CDC

To illustrate, consider how the Airbnb homepage might appear to
someone who has experienced a significant loss of visual acuity. As
shown below, the text becomes extremely impossible to read
comfortably.

Airbnb's home page with simulated blurry vision.

Browser Zoom

To better understand the accessibility challenge, let us explore how
browser zoom functionality works. You may already be familiar with
this feature, using keyboard shortcuts like Command / Ctrl + or
Command / Ctrl -- to scale all content within a window. When you
increase the zoom level beyond 100%, the viewport's height and width
proportionally decrease, while the content is blown up to fit the
larger window.

As part of our accessibility testing strategy, we were using browser
zoom to test the usability of our pages both on desktop and mobile
sizes. Desktop testing showed that our pages did relatively well at
the 200% zoom level with our responsive web approach across the site.
We saw fewer issues in the overall user experience when compared to
mobile web.

This works well on desktop, where we serve a smaller breakpoint
(e.g., wide to compact) and the viewport is relatively spacious.
However, the limitations of browser zoom become more pronounced on
mobile web, where the viewport is smaller. If we were to scale the
content in a mobile viewport, it would have to fit into a viewport
that is half the width and half the height of the original. This can
result in significant accessibility issues, as the text and UI
elements become extremely difficult to read and interact with. As
shown in the image on the right, the ability to view even a single
listing within a screen's worth of space is not possible without
scrolling, leading to a frustrating experience.

Airbnb's homepage shown at browser zoom 100% on the left, and the
same screen shown at 200% showing the search and categories are cut
off entirely and not able to even see the first listing.

Font Scaling

Font scaling is the term we'll use to describe the ability to adjust
text size independently of overall page zoom. Unlike browser zoom,
which scales all content proportionally, Font Scaling applies only to
the text elements on the page. This allows users to customize the
font size to their preferred reading size without affecting much of
layout or responsiveness of the rest of the content.

Font Scaling, is also the term we will use for scaling the font based
on a user's preferred size. Unlike zoom, this setting will be applied
to all sites. Below is an example of how the font scaling applies to
just the text on the screen, showing that the only scale of the text
increases, instead of all the content.

Video Description: Airbnb text is scaled by setting the font size on
arc browser, showing the scaling from 16px to 32xp.

This concept of independent font scaling is similar to the Dynamic
Type feature on iOS, as we discussed in our blog post "Supporting
Dynamic Type at Airbnb". Dynamic Type allows users to set a preferred
system-wide text size, which then automatically adjusts the font size
across all compatible apps.

Considering our existing strategies for accessibility on iOS,
incorporating font scaling (vs zoom scaling) into our web
accessibility approach was a natural next step to help add parity in
approaches across our platforms.

Understanding px, em vs rem

Now that we understand why font scaling is so powerful for mobile
web, we should focus on why we might choose one CSS length unit over
another for supporting font scaling. In this blog post we are only
going to focus on px, em and rem but there are other units as well.
CSS length units are connected to font scaling because they determine
how text and other elements are sized on a web page. Some length
units are fixed, meaning they don't change based on the user's font
size settings, while others are relative, meaning they scale
proportionally with the font size.

Let's take a deep look at 3 CSS length units and how they relate to
font scaling:

  * px units are the most commonly used on the web, theoretically
    they should represent one pixel on the screen. They are a fixed
    unit meaning the rendered value does not change.
  * em units however are a relative unit that are based on the parent
    element's font size. The name 'em' comes from the width of the
    capital letter 'M' in a given typeface, which was traditionally
    used as the reference point for font sizes. 1 em unit is equal to
    the height of the current font size, roughly 16px at the default
    value. em units scale proportionally, so they can be affected by
    their parent's font sizes
  * rem units, short for "root em", are similar to em units in that
    they are proportional to font size, but they only use the root
    element (the html element) to calculate their font size. This
    means that rem units offer font scaling, but are not affected by
    their parent's font size.

The choice between em and rem units often comes down to the level of
control and predictability required for font scaling. While em units
can be used, they can lead to cascading font size changes that may be
difficult to manage, especially in complex layouts. In contrast, rem
units provide a more consistent and predictable approach to font
scaling, as they are always relative to the root element's font size.

This is illustrated in the CodePen example, where the different font
scaling behaviors of px, em, and rem units are demonstrated. In
situations where font scaling is a critical requirement, such as the
Airbnb example mentioned, the use of rem units can be a more reliable
choice to ensure a consistent and maintainable font scaling solution.

Relative units like rem can be used anywhere a fixed unit like px can
be used. However, indiscriminate use of rem units across all
properties can lead to unwanted scaling behavior and increased
complexity.

In the case of Airbnb, the team decided to prioritize the use of rem
units specifically for font scaling, rather than scaling all elements
proportionally. This targeted approach provided the key benefit of
consistent text scaling, without the potential downsides of scaling
every aspect of the layout.

The rationale behind this decision was twofold:

 1. Scaling everything using rem units would have been similar to
    Browser Zoom and potentially introduced unintended layout issues,
 2. The primary focus was on providing a mobile-friendly font scaling
    solution. By targeting font sizes with rem units, the team could
    ensure that the most important content -- the text -- scaled
    appropriately.

Enabling a Seamless Transition for Designers and Developers

Moving from pixel-based values to rem units as a company-wide change
in CSS practice can be a significant challenge, especially when
working across multiple teams. The time and effort required to
educate designers and frontend developers on the new approach, and to
have them convert their existing pixel-based values to rem units, can
be a significant barrier to adoption. To address this, the Airbnb
team decided to focus on automating the unit conversion process as
much as possible, enabling a more seamless transition to the new
rem-based system.

Reducing Friction in Design Iterations

Instead of requiring designers to have to think of new units or
introduce some conversion for web only, we decided to continue to
author our CSS in px units. This reduced the amount of training
required for teams to start using rem units out the gate.

One area we did focus on with our design teams was starting to test
their designs using font scaling by leveraging the Text Resizer --
Accessibility Checker to help simulate what a design might look like
at 2X the font size. This tool helped us spot problems earlier into
the design process.

Addressing the Complexity of Two CSS-in-JS Systems

Airbnb is in the process of transitioning from React-with-Styles to a
newer approach using Linaria. While the adoption of Linaria was
progressing quickly, we recognized the need to support both styling
systems for a consistent experience. Managing the conversion across
these two different CSS-in-JS systems posed an additional challenge.

Linaria

By leveraging Linaria's support for CSS custom properties, the team
was able to create new typography theme values that automatically
converted the existing pixel-based values to their rem equivalents.
This approach allowed the team to introduce the new rem-based theme
values in a centralized manner, making them available to child
elements. This gave the team the ability to override the rem values
on a per-page basis, providing the necessary flexibility during the
transition process.

import { typography } from './site-theme';

// Loops through the CSS Vars we use for typography and converts them
// from px to rem units.
const theme: css`
 ${getCssVariables({ typography: replacePxWithREMs(typography) })}
 // Changes from:
 // - body-font-size: 16px;
 // To
// - body-font-size: 1rem;
`;
// Use the class name generated from linaria to override the theme
// variables for the children of this component.
const RemThemeLocalProvider: React.FC = ({ children }) => {
 const cx = useCx();
 return <div className={linariaClassNames.theme)}>{children}</div>;
};ty

Although this approach helped us convert most of the font scaling
properties, there were many places in our code that we used pxbased
values outside the theme. Linaria's support for post-CSS plugins made
solving these areas relatively easy. We leveraged postcss-pxtorem to
help target those values more easily. We started by using an allow
list, so that we could carefully apply this change to a smaller set
of early adopting pages.

It was important that we provided an escape hatch when there was some
reason for front-end engineers needing to use px units. Luckily we
were able to provide this by using a different casing for the px
value like shown below.

/* `px` is converted to `rem` */
.convert {
  font-size: 16px; /* converted to 1rem */
}
/* `Px` or `PX` is ignored by `postcss-pxtorem`
   but still accepted by browsers */
.ignore {
  font-size: 200Px;
  font-size: clamp(16Px, 2rem, 32Px);
}

React with Styles

A good amount of our frontend code still uses react-with-styles, so
we had to find another way to support these cases with an easy
conversion. Through this we created a simple Higher-Order component
that made the conversion pretty straightforward. First we created a
wrapper for the withStyles function like below, and gave the ability
to avoid conversion as well.

export const withRemStyles = (
  styleFn?: Nullable<(theme: Theme) => Styles>,
  options?: WithStylesOptions & { disableConvertToRemUnits?: boolean },
) => {
  const disableConvertToRemUnits = getDisableConvertToRemUnits(options);
   // If conversion is disabled, just return the original withStyles function
   if (disableConvertToRemUnits) {
     return _withStyles(styleFn, options);
    }
   // Otherwise, wrap the original style function with a new function
   // that converts px to rem
   return _withStyles((theme: Theme) => {
     if (styleFn) {
     const styles = styleFn(theme);
     const remStyles = convertToRem(styles);
     return remStyles;
   }
   return {};
 }, options);
};

Then the convertToRem will look through the keys and values and map a
converted value for any of the font sizing attributes. This allowed
us to automate the conversion process in a more straightforward way.

Improvements for Testing Components

With these two challenges out of the way, we can start testing our
components to verify if there are any major issues we might need to
resolve before rolling out. In our component documentation and
tooling, we built an internal plugin to allow for easier testing by
setting the font-size on the html element directly to test with font
scaling.

Screenshot testing has helped our teams catch visual regressions.
Adding support to allow for setting additional screenshots at
different root font sizes has helped our product teams review what
the component looks like at different font scales. To do this, we
allow for adding additional font sizes to be set when capturing the
screenshots so you don't have to create new component variations just
for font scaling.

Font Scaling on Mobile Safari

Supporting font scaling for Mobile Safari was more difficult. Unlike
other browsers, there is not a font size preference available in
Mobile Safari. However, they have released support for their own
font: -apple-system-body but there are some important considerations.

Since macOS High Sierra (10.13), desktop Safari also supports the
font preference, but there is not an easy "font size" configuration
available in MacOS. Because there can be unexpected behavior on
desktop Safari, so we used a @supports statement to prevent this. The
code below will only target Mobile Safari.

// Apple's Dynamic Type requires this font family to be used
// Only target iOS/iPadOS
@supports (font: -apple-system-body) and (-webkit-touch-callout: default) {
  :root {
    font: -apple-system-body;
  }
}

Another consideration is that the "100%" default font size selected
does not equal the standard font size of 16px, but rather 17px. This
is a very subtle difference, but it is critical for the design
quality bar we aim to achieve at Airbnb. So to resolve this issue, we
ended up using an inline head script to normalize the value, by
placing it early into the page execution we avoided seeing a change
in font size.

(() => {
  // don't do anything if the browser doesn't match the supports statement
  if (!CSS.supports('(font: -apple-system-body) and (-webkit-touch-callout: default)')) return;
  // Must create an element since the root element styles are not yet parsed.
  const div = document.createElement('div');
  div.setAttribute('style', 'font: -apple-system-body');
  // Body is not available yet so this has to be added to the root element
  documentElement.appendChild(div);
  const style = getComputedStyle(div);
  if (style.fontSize === '17px') {
    documentElement.style.setProperty('font-size', '16px');
  }
  documentElement.removeChild(div);
})();

Then when the page loads we use a resize observer to detect if the
value changes again to unset or set the font-size property on the
html element. This helps us still support scalable fonts, but not
have a significant impact on the default font size (100%).

Impact

Supporting scalable fonts is an investment that should make a
dramatic difference for our Hosts and guests with low vision and
anyone who benefits from larger font sizes and control over their
browsing experience. Below are two examples of the home page showing
how the default font size (16px) appears to someone who has blurry
vision and what it looks like by doubling the font size (32px). The
second image is far more legible and usable.

Font size comparison for Airbnb listing readability with blurred
vision: 16px vs. 32px.

Choosing font scaling as the product accessibility strategy brought
about a range of significant benefits that notably enhanced our
platform's overall user experience. Making that change using
automation to convert to rem units made this transition easier. When
looking at our overall issues count after these changes were site
wide, more than 80% of our existing Resize Text issues were resolved.
Moreover, we are seeing fewer new issues since then.

To conclude, our journey to enhance Resize Text on the web has been
filled with valuable, practical lessons. From how we strategically
apply rem units, to the role of tooling and automation, each lesson
has been a vital step forward in elevating our user experience on
Airbnb. We hope that by sharing our journey, we can help others
navigate this transition more seamlessly. Our work is ongoing, and we
are committed to continuously advancing Airbnb's accessibility. If
you're passionate about such challenges, we invite you to explore
career opportunities at Airbnb.

Thanks to:

  * Alan Pinto Souza, Dennis Wilkins, Jimmy Guo, and Andrew
    Scheuermann for advice and technical review.
  * Sterling DeMille, Riley Glusker and Ryan Booth for being early
    product partners.
  * Jordanna Kwok, Sarah Alley and JN Vollmer for supporting the
    approach.
  * Veronica Reyes and Jamie Cristal for providing design support.

All product names, logos, and brands are property of their respective
owners. All company, product and service names used in this website
are for identification purposes only. Use of these names, logos, and
brands does not imply endorsement.

 
Web Accessibility
 
Accessibility
 
Front End Development
 
Web
 
Web Development
 

--

 

--

2

 
 
Steven Bassett
 
The Airbnb Tech Blog
Follow
 

Written by Steven Bassett

11 Followers
*Writer for
 

The Airbnb Tech Blog

Follow
 
 

Help

 

Status

 

About

 

Careers

 

Press

 

Blog

 

Privacy

 

Terms

 

Text to speech

 

Teams