Potato Code

When I was a Junior in college, I heard the term Spaghetti Code, which (if you are unfamiliar) means something to the effect of:

Spaghetti Code, noun:

Code that, should you attempt to organize, you will spend all weekend refactoring with nothing to show at the end but regret and a terrible mess.

I found this hilarious, as I was all-too-familiar with the concept in my own side projects. Even as a student, I had written modules that instead of attempting to touch after 6 months, I would have rather rewritten from scratch.

Later in my career, I became aware of another term: Ravioli Code, which you may be familiar with as well:

Ravioli Code, noun:

Code that is well organized, but in order to find something lost in the "filling", you will have to open up every pouch and look inside.

Which also brings me a little chuckle thinking about.

A little over two years ago, I found a new type of food-code which I am calling...

🥔🥔🥔 Potato Code 🥔🥔🥔 (defined later)

Some context

One thing I do regularly is meet with a number of Blind patrons to elicit feedback and identify issues they face when using our products.

In one of these meetings, we were speaking with a woman who works in the support department and often takes the calls to assist other Blind patrons.

That week she started seeing a new issue, and so she shared her screen so that we could see (or hear*) what was happening. (In case you aren't aware, the way a Blind user interfaces with a computer is via a tool called a "screen reader" that, simply put, takes the graphical information displayed on screen and reads it audibly to the user as they navigate.)

The issue she found was on one of our most popular pages, which has this kind of layout:

The issue she found was at the very bottom of the sidebar. But as she was navigating her way over to it, we heard the screen reader say something intriguing...

And she just skipped over it like it wasn't a big deal!

We interrupted her and said, "Wait, go back. Did that say 'potato'?"

She said: "Oh yeah, it did. When people ask me about it, I've been telling them it's just a character that the screen reader doesn't understand. So it gets confused and says 'Potato' - but it's not really a potato so they can ignore it."

Bless her! She had so much trust in the engineers that she assumed the screen reader was the problem and not our code.

I immediately started looking through the code base, and eventually found this little gem:

import React from "react";
import { BaseIcon } from "@components/icons";
 
export function ListItemIcon({ children }) {
  return (
    <BaseIcon
      size="sm"
      role="img"
      aria-label="potato" // <-- wut??
    >
      {children}
    </BaseIcon>
  );
}

As you can see, someone hard-coded an aria-label of "potato" onto an icon.

If you are unfamiliar, aria-label is a special attribute that tells the screen reader to ignore all other text it sees and use this value instead. Most of the time that's a great thing to do to make something clearer for the user. But it can go wrong if you don't use it right.

This is what I now like to call, "Potato Code":

By the way, it was one of my best friends who wrote this code.

No ARIA is better than bad ARIA

If you've ever been to the ARIA Authoring Practices Guide (also known as the APG), then you have, for sure, seen a banner which reads, "No ARIA is better than Bad ARIA"

This story is a prime example of why that is true.

Had my friend done nothing, the screen reader would have simply read the code as a "Graphic, Link" and moved on.

But no, my friend had heard me talk over and over about accessibility, so he said to himself "Kyle's told me that images should have appropriate labels; I don't know what to put here right now, so I will come back to it later."

And then he went along, finished what he was working on, but forgot to come back. A junior dev did the review, it got merged, and it went along its merry way to patrons.

Luckily, the fix for this was easy, and it was out the afternoon we found it. Not a big deal in the end, thankfully. You can hear the different possible solutions and what we landed on in my ReactSummit talk, My Heart is in the Right Place, but the DOM isn’t.

Lessons Learned

Nothing new actually, just that we should try a little harder to do what we know is right.

You should probably test your code before merging. That includes any a11y work. As a general rule, if you put role, aria-*, or any semantic HTML on a page, then be sure to try it out with a screen reader to make sure that you know it's doing what you intended. Taking five minutes to navigate your UI with VoiceOver (Mac/iOS), JAWS/NVDA (Windows), or TalkBack (Android) can save your users from confusion or worse.

Don't merge on the basis of trust alone. Smart people make mistakes too, but the whole reason we do code reviews is to prevent those mistakes from making it to patrons. When reviewing code with accessibility attributes, take a moment to ask: "What would a screen reader say here?" Even better, actually test it if you can.

I've seen a lot of "temporary" code that became permanent. My friend intended to come back and fix that potato later, but the code made it to production anyway.

Lastly, If you find potatoes buried in your code, dig them up and get rid of them as fast as you can. Your users (especially those relying on assistive technologies) will thank you for it.