
## 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 not?

Despite some web design tools specifying CSS `height` values for elements like buttons, setting `height` or `max-height` can actually put you at risk for failing [WCAG 2.2 Success Criterion 1.4.4 Resize Text](https://www.w3.org/TR/WCAG22/#resize-text).

This Success Criterion requires:

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

When using fixed values for CSS properties that affect an element's computed height and width, text inside of the element will get cut off when text size is increased.

## Not convinced?

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.

But how? It's easier to handle than you might think!

## Code demos

_Note: For the purpose of these demos, please pretend that we're using `rem` units for `font-size`. I use `px` units here so as to not inherit the base font styles from my website._

### Demo 1

First, let's take a look at what happens when text size is increased while using fixed values for `font-size`, `height`, `line-height`, and `width`. Before the text size is increased, the button looks great! Not so great after increasing the text size though.

<CallOut id="demo-1a" title="Before text size is increased" type="example">

<button style={{
  alignItems: 'center',
  appearance: 'none',
  border: '1px solid black',
  display: 'flex',
  fontFamily: 'Arial',
  fontSize: '16px',
  height: '36px',
  justifyContent: 'center',
  lineHeight: '18px',
  overflow: 'hidden',
  textWrap: 'nowrap',
  width: '82px',
}}>
delete all
</button>

```html
<button style="font-size: 16px; height: 36px; line-height: 18px; width: 82px;">
  delete all
</button>
```

</CallOut>

<CallOut id="demo-1b" title="After text size is increased" type="example">

<button style={{
  alignItems: 'center',
  appearance: 'none',
  border: '1px solid black',
  display: 'flex',
  fontFamily: 'Arial',
  fontSize: '32px',
  height: '36px',
  justifyContent: 'center',
  lineHeight: '18px',
  overflow: 'hidden',
  textWrap: 'nowrap',
  width: '82px',
}}>
delete all
</button>

```html
<button style="font-size: 32px; height: 36px; line-height: 18px; width: 82px;">
  delete all
</button>
```

</CallOut>

### Demo 2

Now let's take the same code and try using no units for `line-height`, and `padding` for affecting the button's `height` and `width`. We shouldn't see the text get cut off at all when the text size is doubled.

<CallOut id="demo-2a" title="Demo 2a: Before text size is increased" type="example">

<button style={{
  appearance: "none",
  border: "1px solid black",
  fontFamily: "Arial",
  fontSize: "16px",
  lineHeight: "1.125",
  overflow: "hidden",
  padding: "8px",
  textWrap: "nowrap",
}}>
delete all
</button>

```html
<button style="font-size: 16px; line-height: 1.125; padding: 8px;">
  delete all
</button>
```

</CallOut>

<CallOut id="demo-2b" title="Demo 2b: After text size is increased" type="example">

<button style={{
  appearance: "none",
  border: "1px solid black",
  fontFamily: "Arial",
  fontSize: "32px",
  lineHeight: "1.125",
  overflow: "hidden",
  padding: "8px",
  textWrap: "nowrap",
}}>
delete all
</button>

```html
<button style="font-size: 32px; line-height: 1.125; padding: 8px;">
  delete all
</button>
```

</CallOut>

## Another approach

One technique the Understanding docs for note is [C28: Specifying the size of text containers using em units](https://www.w3.org/WAI/WCAG22/Techniques/css/C28). In my experience I've found this approach harder to maintain as viewport sizes shrink.

Think of a mobile device with large text size settings. It's possible the text container sized with `em` units would end up wider than the viewport. If the text is cut off by the device size, that means we're at risk for failing not one but two WCAG 2.2 Success Criterion:

- [SC 1.4.4 Resize Text](https://www.w3.org/TR/WCAG22/#resize-text)
- [SC 1.4.10 Reflow](https://www.w3.org/TR/WCAG22/#reflow)

One option for preventing this while using Technique C28 could be to leverage a CSS property like `max-width`, but personally I prefer to use the least number of CSS properties possible (for lower long term maintenance cost). Instead of using `width` and `max-width` it's likely we can just use `padding` and let the browser do it's default magic for making elements fit in a viewport.


Fixed heights and widths risk 'loss of content' when text is resized.

Posts Related to the "sc-1-4-10" Tag