
## TL;DR

This bookmarklet can help you visually check how well a webpage handles text being resized to 200% of the base/default size. It can also help you test for loss of content when checking compliance for [WCAG 2.2 Success Criterion 1.4.10 Reflow](https://www.w3.org/TR/WCAG22/#reflow).

To add the bookmarklet to your preferred browser:

1. Create a new bookmark
2. Give it a good name (maybe "Toggle text zoom")
3. Copy-and-paste the following code for the URL

```js
javascript: (function () {
  const htmlElement = document.querySelector('html');
  const currentFontSize = htmlElement.style.getPropertyValue('font-size');
  const isZoomed = currentFontSize === '200%';
  const newFontSize = isZoomed ? null : '200%';
  htmlElement.style.setProperty('font-size', newFontSize);
})();
```

Disclaimer: This is experimental and should be used at your own risk! If a webpage is already coded to set the CSS `font-size` property on the `<html>` element, this bookmarklet probably won't work as intended.

## Does WCAG have text size requirements?

The [Web Content Accessibility Guidelines](https://www.w3.org/TR/WCAG22/) has one Success Criterion criterion in particular that talks about text size. [WCAG 2.2 Success Criterion 1.4.4 Resize Text](https://www.w3.org/TR/WCAG22/#resize-text) says:

> Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

## Text resizing is not the same as browser zoom

You might be thinking, "But when I zoom in my browser to 200% the button text looks fine!" This is probably a common misconception with this Success Criterion. I definitely didn't know for a while that browser zoom is only part of the story!

Digging deeper using the [Understanding SC 1.4.4: Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html) docs, it says we (the "authors") have to handle the case when a user only increases the size of their text since their browser (or some other "user agent") might not have zoom capability.

The docs say:

> If the user agent doesn't provide zoom functionality but does let the user change the text size, the author is responsible for ensuring that the content remains usable when the text is resized.

This Success Criterion is one reason why it's good practice to use `rem` units for the CSS `font-size` property and no units for the `line-height` property. Text must be resizeable up to 200% without a mechanism like browser zoom.

## How do I test 200% text size?

The easiest way I've found to test text-only zoom is by setting `font-size: 200%` on the `<html>` element for a web page. This can be done a few ways:

1. Manually adding the CSS property in browser dev tools
2. Running some JavaScript in the browser console
3. Putting the JavaScript in a bookmarklet and running it with one click

I prefer option 3 the most because it's just one click and it's a more accurate user experience test since I can keep the browser dev tools panel closed.

My bookmarklet is set up to **_toggle_** the `font-size: 200%` setting on the `<html>` element when the bookmark is clicked. It checks if the current `font-size` value is already set to `200%`, and adds or removes it based on that check.

To add the bookmarklet to your preferred browser:

1. Create a new bookmark
2. Give it a good name (maybe "Toggle text zoom")
3. Copy-and-paste the following code for the URL

```js
javascript: (function () {
  const htmlElement = document.querySelector('html');
  const currentFontSize = htmlElement.style.getPropertyValue('font-size');
  const isZoomed = currentFontSize === '200%';
  const newFontSize = isZoomed ? null : '200%';
  htmlElement.style.setProperty('font-size', newFontSize);
})();
```


Quickly test your 'loss of content' risk when text is resized.

An Accessibility Bookmarklet for Testing 200% Text Size


## Why are CSS margin and padding so closely related?

The CSS [margin](https://developer.mozilla.org/en-US/docs/Web/CSS/margin#values) and [padding](https://developer.mozilla.org/en-US/docs/Web/CSS/padding#values) properties are often talked about together for two reasons:

1. They both affect whitespace and sit right next to each other in the [CSS Box Model](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model), only separated by a border if one's present.
2. They accept nearly the exact same CSS data types for their values: `length` and `percentage`. (`margin` also accepts `auto`, but that's not important for what we're discussing here.)

## What are the length and percentage CSS data types?

[CSS length](https://developer.mozilla.org/en-US/docs/Web/CSS/length) is one type of a distance value. [CSS percentages](https://developer.mozilla.org/en-US/docs/Web/CSS/percentage) are similar to length, but the difference is that they're always a fraction of something else in a page depending on what property they're being used with. Lengths can either be _absolute_ or _relative_.

## What's the difference between absolute and relative units?

CSS provides us two types of units so we can build flexible websites that work across all kinds of devices and configurations.

- [**absolute length units**](https://developer.mozilla.org/en-US/docs/Web/CSS/length#absolute_length_units) are always the same, and not based on anything else in a page
- **relative length units** units can change, and are based on [font](https://developer.mozilla.org/en-US/docs/Web/CSS/length#relative_length_units_based_on_font) and [viewport](https://developer.mozilla.org/en-US/docs/Web/CSS/length#relative_length_units_based_on_viewport)

## How do I know when to use absolute or relative CSS units?

Most people don't like their questions answered with a question, but that's how I feel like breaking this down right now. (Sorry!!)

When you're deciding between absolute or relative CSS units for a particular CSS property, you need to think about what a user is trying to do.

You may already be familiar with **relative length units** when it comes to text size. It's best practice to use `rem` units for the `font-size` property, because it enables users to customize their viewing experience with settings on their personal device.

**Relative length units** are also commonly used for changing how a page looks based on a user's viewport size. It's how we go about [implementing responsive designs](https://ashleemboyer.com/blog/tags/responsive-design) that will work no matter what device, window size, page zoom, or text size a user has.

So what user actions are we designing for when we use **relative length units**?

- Increasing text size settings
- Resizing a browser window
- Zooming in or zooming out of a page
- Reading from a mobile device

In all of these situations, what does a user care about most? The content, or the spacing between the content? Which of these two things are vital for understanding the web page?

## Why shouldn't I use relative units for margin, padding, or other spacing techniques?

When a user is customizing their viewing experience, they thing that's most important to them and their task at hand is **the content**. Spacing isn't often vital for a user to perform their task, so it doesn't need to grow or scale at the same rate as the content itself.

When spacing between content grows, it eats up vital real estate and becomes harder to manage. You probably know the pain of horizontal spacing if you've worked on a site long enough to add multiple main navigation links over time. You run out of space at double the rate if you scale `margin` and `padding` exactly like text size!

In terms of vertical spacing, you also end up making a user's task harder to complete. There's nothing you can do about text that has to wrap to the next line based on limited horizontal space, but you don't want to make pages _even taller_ because your vertical spacing grows with your text size.

Tall pages mean more scrolling and work for a user that just wants to read content differently, and they'll also be even more limited at how much content they can see at one time.

## Code demo: the difference between absolute and relative units for margin and padding

I'm going to "pick on" a page from Subway's website because it's the first one that came to mind where I've for sure experienced this issue. I don't have anything against them or the developers that made this website! It's just helpful to see a real world example, and it's easier for me than to come up with my own.

<CallOut
  title="Note: This demo's webpage has multiple accessibility issues."
  type="disclaimer"
>

This webpage has other issues besides using `rem` units for `margin` and `padding`. My goal in this demonstration is to show how this approach affects **_content height_**, and thus scrolling and readability. There are still reflow issues that occur on the page that require a little bit more code in addition to swapping `rem` units for `px`.

</CallOut>

### Before increasing text size

At the time of writing (November 2nd, 2023), here's the basic view of one page without increasing text size. At a high level, it has:

- a navigation header with the logo, multiple links, and a few buttons
- a two-column call to action with large text, a description, button, and a Christmas themed graphic
- a three-column breakdown with additional information about the product being sold on the page

<img
  alt=""
  src="https://res.cloudinary.com/ashleemboyer/image/upload/v1702832787/article-images/SubwayBeforeTextSizeIncrease_a9dkuw.png"
/>

### After increasing text size

To test what happens with only a text size increase, I can add one CSS property to the main `<html>` element on the page: `font-size: 200%;`. This works by doubling whatever base font size the website is using, and because they use `rem` units for actually sizing text.

<CallOut
  title="Related WCAG: Success Criteria 1.4.4 Resize Text and 1.4.10 Reflow"
  type="idea"
>

Curious about this `font-size: 200%;` approach? I break down the WCAG requirements related to text resize and this testing approach in a separate post.

👉🏻 Set yourself up for text-size success with one of my favorite custom bookmarklets: [An Accessibility Bookmarklet for Testing 200% Text Size](https://ashleemboyer.com/blog/an-accessibility-bookmarklet-for-testing-200-percent-text-size)

</CallOut>

Unfortunately, they also use `rem` units for `margin` and `padding` in most elements. In the next screen recording, we can see that:

- The navigation header is now extremely tall, taking up almost half of the window height and also covering up the next section of content.
- Less than half of the navigation header content is visible, because most of it is overflowing off the righthand side of the window.
- The two-column call to action section is still two columns, not leaving much horizontal space for all the text it has.
- Within the text column of the call to action section, the space around the text is larger, leaving even less horizontal space to read it. The large text is showing about one word per line, and the smaller text is only showing a couple words per line.

<iframe
  title="Subway's website with increased text size & rem units for margin and padding"
  width="100%"
  height="400px"
  src="https://www.youtube-nocookie.com/embed/4R8t8Z1H4jc?si=DKw62HBVEFXtnI_T"
  frameBorder="0"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
  allowFullScreen
></iframe>

### After updating to px units

To show what this webpage would look like if it used `px` units for `margin` and `padding` instead of `rem` units, I inspected the HTML and CSS using my browser devtools and overwrote some of the CSS values. As we can see in the next screen recording:

- The navigation header still has content cut off to the right but it's much shorter, meaning we have more space to see the main content on the page.
- Since we can see more content at once on the page, the content is easier to understand because there's more immediate context to get information from while reading.
- In what was the two-column call-to-action, I adjusted the padding around and between groups of text to no longer scale, giving more horizontal space to show the text.
- I also made the two-column call-to-action just one column to decrease the height of the text portion. This demonstrates a large benefit of making the media query for this section use `rem` units rather than `px` units (article on this approach coming soon).

<iframe
  title="Subway's website with increased text size & px units for margin and padding"
  width="100%"
  height="400px"
  src="https://www.youtube-nocookie.com/embed/Q_9gOkbWFno?si=LZN1aoiyXnKNnvSz"
  frameBorder="0"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
  allowFullScreen
></iframe>

## How else can I make my responsive design accessible?

It's your lucky day! I've been working on an informal series about accessible responsive design.

- Recently posted: [Don't Use Fixed CSS height or width on Buttons, Links, or Any Other Text Containers](https://ashleemboyer.com/blog/don-t-use-fixed-css-height-or-width-on-text-containers)
- Currently in-progress and coming soon: Why You Should Use `rem` instead of `px` Units in CSS Media Queries


When users increase their text size, they're not trying to make the space around text bigger.

Why You Should Use px Units for margin, padding, & Other Spacing Techniques


I came across some issues on touch screens where I have a navigation menu expanded and the common "shadow" showing on the non-menu portion of the screen. When I tried tapping on the "shadow" to close the menu, way too many things were happening! Here's a quick illustration of what sort of screen I'm talking about:

![Mobile screenshot of a menu and its shadow](https://thepracticaldev.s3.amazonaws.com/i/ql9hc8t6rgeghdx1ikgw.png)

When a user taps on the "shadow" portion of the screen, they expect the menu to close. Nothing else should happen. You can handle this by adding a `touchstart` event listener to the element used for the shadow, but there are a couple of things to watch out for. It won't behave the same as a `click` event listener you use for the desktop version of your app.

It's all about when events are fired. A `click` event doesn't go until after a click is over and a mouse button is released. So, when a user clicks on the "shadow" with their mouse, there aren't any side effects. It's a different story for touchscreens, however.

If the items "behind" the "shadow" are clickable, a user touching the "shadow" to close the menu will also cause fire off the click events on those items. It's a pretty simple fix. In your `touchstart` listener, all you have to do is call `preventDefault` on the event passed into the listener. It might go something like this:

![Screenshot of touchstart event listener code showing call to preventDefault and some example lines of code for hiding the shadow and menu](https://thepracticaldev.s3.amazonaws.com/i/llil1vy7msaoswf3dbtf.png)

It's really that easy&mdash;a one-line fix. It wasn't super obvious to me at first, so I hope this helps clear things up for anyone else in the same boat as me. Have you ever run into similar issues? If so, enlighten us in the comments and save us some pain! :)


The touchstart event in mobile web apps is a little different than the click event. Here's how I solved an issue I've run into frequently.

Posts Related to the "mobile" Tag