
💡 _This post is part of [my Today I Learned (TIL) series](https://ashleemboyer.com/blog/series/today-i-learned). Each section below describes a thing I learned today and the resources I used to learn it._

## Custom Visual Studio Code Key Bindings (again)

- **Why I learned this:** I originally learned how to add custom key bindings in early 2022 ([see the Gist](https://gist.github.com/ashleemboyer/6509df0445695578e11998b7d064fbd5)). Today, I went to add a new one and discovered a new feature while reading the docs. [Around March 2023](https://github.com/microsoft/vscode-docs/pull/6177) they added a built-in way to run multiple commands! I had been using the [`multi-command` extension](https://marketplace.visualstudio.com/items?itemName=ryuta46.multi-command).
- **How I used this:** I didn't end up adding a new keybinding (found a different workaround for the problem I was having) but I did update my configuration file to use the built-in `runCommands` and removed the previous extension. I'm _super_ minimalist about VS Code extensions so I'm glad I was able to remove one! I was also able to remove a custom keybinding that wrapped selected text in hyperlink syntax. Turns out if you have a URL on your clipboard, select text, and hit cmd+v, a hyperlink is automatically created. I've [published a new Gist](https://gist.github.com/ashleemboyer/5004f1d7a95f3df1b816321f6cf4249d) with my new file!
- **Resource I referenced:** [Running multiple commands - VS Code docs](https://code.visualstudio.com/docs/getstarted/keybindings#_running-multiple-commands).

## CSS property `tab-size`

- **Why I learned this:** On my business website, [Semantic Fish](https://www.semanticfish.com/), I'm working on a series of component demos and writeups. I want to be able to write React code for the interactive part and also have a code snippet shown in HTML. I don't want to have to write both, or write the content in Markdown or MDX. I'm pretty happy at the moment with just writing in JSX. But back to the HTML code snippet&mdash;I also want it to have syntax highlighting. Final thing: I don't want to install a third-party library. So I made it a fun mini project to build a `CodeBlock` component using brand colors for the syntax highlighting.
- **How I used this:** My component parses React `children` passed in the `CodeBlock` to build an array of code lines. It does this recursively, since each element in `children` can have multiple child elements of its own. Each time my recursion function is called, I increment its second argument (called `indentBy`) by 1. Then just before the function returns its lines of code, I add `indentBy` tab characters (`&#9;`) to the beginning of the line. I _could_ use space characters instead, but the width of those isn't customizeable like tab characters. Eventually it'll be cool to add a feature to my `CodeBlock` that enables anyone to customize the tab width to whatever helps them read the code easiest. For now I've set a default `tab-size: 2` on the `CodeBlock`'s `code` HTML element.
- **Resource I referenced:** [tab-size - MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size).

## Void Elements

- **Why I learned this:** Part of working on the aforementioned `CodeBlock` component involved needing to know which HTML elements have end tags or just a `>` character (aka `&gt;` in HTML). Turns out there's a name for these kinds of elements! You guessed it: they're called void elements. Also, self-closing tags (`<tag />`) do not exist in HTML. Today I learned! (bad-dum-tssss)
- **How I used this:** Using the list from MDN, I created an array constant of tag names near my recursive function (mentioned in [the previous section](#css-property-tab-size)). For each line of code I build up in the function, I check if the element's tag name is in the array (using [`Array.includes`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes)).
- **Resource I referenced:** [Void element - MDN](https://developer.mozilla.org/en-US/docs/Glossary/Void_element).


Today I Learned

TIL #4: VS Code Key Bindings, tab-size CSS Property, and Void Elements


## Table of Contents

1. [Disclaimer](#disclaimer)
1. [The Announcement](#the-announcement)
1. [The Marketing and Documentation](#the-marketing-and-documentation)
1. [A Few Quick-ish Tests](#a-few-quick-ish-tests)
1. [Some Accessibility Issues](#some-accessibility-issues)
1. [In Summary](#in-summary)
1. [Related Resources](#related-resources)

## Disclaimer

I'm a neurodivergent and multiply disabled expert in web accessibility. I have a software engineering degree and almost a decade of software engineering experience. I am currently a self-employed consultant in software engineering and accessibility. ([Reach out if you want to collaborate](https://semanticfish.com)!)

This article is a few hours of free labor and close to half of what I'd charge for a 1-week sprint in a contract. This is to say I spent valuable time and limited energy doing work that should paid good money. I'm not saying it has to be _me_, but it should be _someone_ with expertise in accessibility.

## The Announcement

On July 5th, 2024, shadcn/ui Charts were announced on X.

<figure>
  <img aria-labelledby="announcement-caption" src="https://res.cloudinary.com/ashleemboyer/image/upload/article-images/announcement_tcyeih.png" />
  <figcaption aria-hidden id="announcement-caption">X post by shadcn on July 5, 2024, at 6:22 pm. Introducing Charts. A collection of chart components that you can copy and paste into your apps. Built on top of Recharts. Beautifully designed. Open Source.</figcaption>
</figure>

## The Marketing and Documentation

On the shadcn/ui home page, there's a new Charts navigation link and an "Introducing Charts" call-to-action in the main content area.

The first links to the [Charts Library page](https://ui.shadcn.com/charts). It contains a few dozen examples of area, bar, line, pie, radar, and radial charts. There is also a widget for changing the color scheme: default, palette, sapphire, ruby, emerald, daylight, and midnight. There are no mentions of the keywords accessibility, keyboard, or screen reader.

The second links to the main [`Chart` component documentation](https://ui.shadcn.com/docs/components/chart). It has an interactive demo and documents installation, grids, axes, tooltips, legends, theming, and other configurations.

At the very end of the page is an Accessibility section. Through one boolean prop ([a React term](https://react.dev/learn/passing-props-to-a-component)), it states the ability to add "keyboard access" and "screen reader support". It also provides a copy-paste-able short example code snippet.

<figure>
  <img aria-labelledby="accessibility-section-caption" src="https://res.cloudinary.com/ashleemboyer/image/upload/article-images/accessibility-section_jz430y.png" />
  <figcaption aria-hidden id="accessibility-section-caption"><code>Chart</code> documentation Accessibility section. You can turn on the <code>accessibilityLayer</code> to add an accessible layer to your chart. This prop adds keyboard access and screen reader support to your charts.</figcaption>
</figure>

## A Few Quick-ish Tests

### Test 1: "Your First Chart" Documentation Demo

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/iBeMgw7NCgE?si=xtTVM-fI2AzCPqHb" title="YouTube embed: 'Your First Chart' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

### Test 2: "Add a Grid" Documentation Demo

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/XqO5hG75zF0?si=lEhTy9zE4CwNzKQD" title="YouTube embed: 'Add a Grid' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

### Test 3: "Add an Axis" Documentation Demo

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/jVoZYGOVSLw?si=zOX9ep2b1h_jJa07" title="YouTube embed: 'Add an Axis' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

### Test 4: "Add Tooltip" Documentation Demo

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/oKF10Qb2ko0?si=YbS7JkUIIb15cwGo" title="YouTube embed: 'Add Tooltip' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

### Test 5: "Add Legend" Documentation Demo

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/wAnMFmaZgmY?si=h4etkm3y5Meiw3PA" title="YouTube embed: 'Add Legend' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

### Test 6: With and Without VoiceOver's "Quick Nav" mode

Video description coming soon.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/Q8jP3jMaoUc?si=WzkINh1p_TeG-L57" title="YouTube embed: 'Quick Nav' test"  allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen />

## Some Accessibility Issues

1. **SC 1.1.1 Non-text Content (Level A):** The charts tested do not have a text alternative. The only information presented by a screen reader is axis text labels and (sometimes) the tooltip content is reachable.
1. **SC 1.3.1 Info and Relationships (Level A):** When a legend is configured, it has no directly coded relationship to the chart. Since it is placed in the DOM after the chart with `role="application"` there is no inferred relationship. Tooltips are also after the `role="application"` element, so their content cannot be presented by screen readers without moving through the rest of the chart content.
1. **SC 1.4.1 Use of Color (Level A):** Color is currently the only way someone can visually distinguish data in the charts. I have not found documentation for how to make these charts visually accessible with strategies like monochrome palettes, line styles, pattern fills, or extra labels. The tooltips can help, but only if they represent one piece of data at a time. In the videos above, each tooltip represents two bars.
1. **SC 1.4.13 Content on Hover or Focus (Level AA):** The tooltips can be dismissed with the <kbd>ESCAPE</kbd> key, but they are not hoverable or persistent. This prevents _many_ people from perceiving and understanding the tooltip content. They may also accidentally make the tooltip disappear with the slightest cursor movement.

## In Summary

In my quick-ish testing, I found multiple critical accessibility issues with the Chart component. The "keyboard access" claim in the documentation is mostly accurate. The "screen reader support" claim is false. No information is presented about the data by a screen reader when using the left or right arrow keys to navigate the charts.

The documentation also does not describe how keyboard or screen reader interactions _should_ work, which I find irresponsible considering the bold marketing claims this library is "Accessible."

With great popularity comes great responsibility. Web accessibility is becoming more enforced by law and expectations of UI libraries are rising. Most library consumers will take "Accessible" at face value when they trust the maintainers or referrals. Since charts are an "advanced" accessibility topic, many likely don't know how to verify the claim.

As a person who relies on a multitude of accessibility "features" (I don't like the term "accessibility feature" but I can't think of an alternative), it's discouraging to see a popular UI library miss key aspects. When the marketing says "Accessible" but neither the documentation nor the functionality backs it up, it diminishes my trust and the library's credibility.

If the documentation demonstrated effort in it, I would believe accessibility is a priority. But based on my test results, the library's popularity, and my lived experiences: I don't see enough evidence to feel that accessibility is treated as seriously as it needs to be. It feels performative. I'd love for that perspective to change.

## Related Resources

### From the Do No Harm Guide: Centering Accessibility in Data Visualization

- [Summary by Urban Institute](https://www.urban.org/research/publication/do-no-harm-guide-centering-accessibility-data-visualization)
- [Report as PDF](https://www.urban.org/sites/default/files/2022-12/Do%20No%20Harm%20Guide%20Centering%20Accessibility%20in%20Data%20Visualization.pdf)
- Chapter 5: Coding Accessible Data Visualisations (by [Léonie Watson](https://tink.uk/))
- Chapter 6: Creating Better Screen Reader Experiences (by [Sarah Fossheim](https://fossheim.io/))

### From the Web Content Accessibility Guidelines 2.2

- [SC 1.1.1 Non-text Content (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html)
- [SC 1.3.1 Info and Relationships (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships)
- [SC 1.4.1 Use of Color (Level A)](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html)
- [SC 1.4.13 Content on Hover or Focus (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html)
- [Understanding "Text Alternatives"](https://www.w3.org/WAI/WCAG22/Understanding/conformance#text-alternatives)

### By Léonie Watson

- [Accessible SVG line graphs](https://tink.uk/accessible-svg-line-graphs/)
- [Accessible SVG tables](https://tink.uk/accessible-svg-tables/)
- [Accessible SVG flowcharts](https://tink.uk/accessible-svg-flowcharts/)


My personal analysis after a few keyboard & screen reader tests.

A Quick-ish Accessibility Review: shadcn/ui Charts


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


## 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.

Don't Use Fixed CSS height or width on Buttons, Links, or Any Other Text Containers


If you've been on tech twitter in the past week, you might've seen a TypeScript debate that seemingly came out of nowhere. Well, it came from news that [Turbo 8 is dropping TypeScript](https://web.archive.org/web/20230909190042/https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01). There has been all kinds of commentary on this news, but there's one that's almost always left out in discussions about developer tooling: developer accessibility.

Not enough people in software think of developer productivity as effectively being the same thing as developer accessibility. So let's talk about it! Prepare to go through some of the features of TypeScript that can be especially helpful for disabled and/or neurodivergent developers. I'm listing them in alphabetical order.

_If you think something is missing below or want to share the accessibility benefits you experience with TypeScript, [send me a tweet](https://twitter.com/ashleemboyer) or [email me](mailto:hello@ashleemboyer.com)!_

## Code editor tools (code completion, hover tooltips, etc.)

The code editor tools that come with TypeScript are my favorite part of TypeScript. Code completion is probably the top one for me. I can be very easily distracted some days (ADHD) or I might be mentally tired from fighting through distractions. Code completion ends up being a tiny _helpful_ distraction. It keeps me on task and gives me all the options I have at hand as I type. I don't I have to remember every single detail of whatever code I'm working with. TypeScript does it for me and gives me little reminders. It's also a lot less typing, which my hands and brain are very grateful for on high pain days.

The hover tooltips that appear on top of code are also helpful for reducing cognitive overload and increasing productivity. It reduces the scope of understanding a codebase at a high level, rather than having to memorize so many small details and staying on top of changes to them. For example: It's not important to memorize every possible property of an object that fits under your business logic. Those can change easily at any time and without you knowing if you work on a larger team. It's impossible to keep track of everything yourself.

## Maintainable, built-in documentation

I've worked on all sorts of projects in my career already. From brand-new to several years old, from small to medium sized teams - they all go through the same problems in different flavors. One big problem every development team faces is documentation maintenance. I personally _love_ writing documentation, and I still think making it maintainable is the hardest part.

It can't just be about one person's process or system for maintaining documentation, because we all think and work differently. Finding a balance across a team's differing working styles is incredibly important for healthy collaboration. I've found that coupling different types of tasks together with the main task you already have the hang of is fairly successful.

For example: It can be easier to remember to update documentation when it's a co-located code comment vs. when it's in a separate Markdown file. This is because it's right next to where you're already working. It's less time than figuring out where the existing documentation might be, or trying to decide where to put new documentation.

What's even better is that TypeScript is _functional_ co-located documentation. When you make a change to a type or interface (which is already part of the code writing process), the documentation is getting updated at the same time because the types are both code and documentation. You may need to update some neighboring code comments as well, but there's still less steps involved in keeping your codebase's documentation up to date.

## Immediate feedback

TypeScript provides feedback on your code at compile time, meaning you don't always have to wait until you run your code to see if it doesn't work. If you're writing code that needs to be tested in a browser, switching from your code editor to your browser to do so is a mental context switch.

These moments can carry large risk for distraction depending on your ability to focus at the time. They can also be exhausting after a while if you have to fight your brain each time to force it to stay focused. Since TypeScript can help reduce the occurrence of some runtime errors before you even leave your code editor, that means less of these context-switching moments, so less risk for distractions and less energy wasted on what's likely common and minor issues.

Immediate feedback also reduces the cognitive load needed to figure out why a likely common runtime error happened. Who wants to spend time debugging typos or digging into source code to figure out why you couldn't access a property on an object that doesn't actually exist on it? Don't get me wrong, reading code can interesting and insightful. But if I'm trying to write code efficiently, I don't want to read other code that much. Working smarter (not harder) means making computers do the heavy lifting for us wherever possible. 😉

## Onboarding

Onboarding to a new codebase regardless of its age or size is no small task. The questions that come to mind in the process are endless, and that can get overwhelming and discouraging fast. It's also very time consuming, and it can be scary building up the confidence to ask questions to your peers when you're new and getting to know them.

> What tooling does it use? What tooling does it _not_ use that you might be accustomed to relying on? What standards does it follow? Where is the documentation (if any)? Who do you ask questions to? Where can you learn the context of various decisions? What areas are people too afraid to change? Does it use camel case or snake case? What ESLint rules does it have (if any) and why? How do different areas connect to the business logic? What is the business logic? Is this particular business logic still relevant? Why is this code here if it doesn't look like it's used? Does the person that wrote this still work here? Why does the UI do this? Who asked for this feature? Where is this function defined? How was this data computed before it was passed to this function? ...

With TypeScript working as built-in documentation and also having helpful code editor tools for jumping to definitions or showing additional information through hover tooltips, there's decreased cognitive load needed for navigating a codebase. You don't have to guess where to find documentation or definitions. You also don't always have to leave the current file you're in. And when you start writing code, you're given suggestions of what's possible for you to do as you write. You don't have to pause, leave the current file or section of code, or remember what you were doing and where.

TypeScript helps you start writing code that does something more quickly, which is beneficial for the contributors or consumers of a codebase. But this isn't just about the developers that build a product. Developers that are using a software product are going to **_keep using it_** if it helps them do their jobs quickly and successfully. Onboarding developers as users is an important facet of building software as a product.


TypeScript can be a helpful tool for disabled and/or neurodivergent developers.

Ashlee M Boyer

Recommended writings

Most recent writings