I wrote about semantic HTML for colors 5 years ago, for when a color’s appearance is important content, not just style:

• Design systems’ available color palettes
• Choosing what color of clothing you would like to buy
• Preview swatches for sites about paint
• Probably lots more — colors are pretty important!

My original post suggested a labeled <input type=color readonly>, but since then I’ve thought about how that falls short:

• Can’t display wide-gamut colors, or managed color in general
• Can’t display semitransparency, gradients, patterns, or other fancy swatches
• Can’t nest inside <a>, <button>, another form field’s <label>, etc.
• readonly still isn’t allowed on <input type=color>… and the color picker/inspection popup isn’t accessible yet anyway

So, my original conclusion’s <svg> is probably a better idea. (I’d use my Edit button on that post… if I had one.)

Now, those issues are important, but the real reason I’m writing this is much pettier: I used Inspect Element on github.com and got mad about it.

GitHub’s hex code swatches

GitHub has a feature where if you type a 6-digit hex code in Markdown files/comments/whatever, it displays a color dot of that hex in RRGGBB format:

For example, GitHub’s HTML output if you type `#aa4400` looks like:

<code>#aa4400
  <span
    class="ml-1 d-inline-block border circle color-border-subtle"
    style="background-color: #aa4400; height: 8px; width: 8px;"
  ></span>
</code>

This has problems:

Not exposed accessibly

Forget text alternatives, right now it’s completely nonexistent to assistive technology

Too easily overridden

By Dark/Light Mode browser extensions, builtin Dark Mode browser support, user styles, etc.

Invisible under forced colors

forced-colors is the standardized name for features like Windows High-Contrast Mode, which turn off background-color altogether

We can fix most of those problems with inline SVG:

<code>#aa4400
  <svg width="8" height="8"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>

A few notes on the above markup:

• I haven’t exposed it accessibly yet, because that turned out to be a whole section’s worth of considerations
• No longer needs the d-inline-block class (<svg> is inline-block by default)
• No style attribute lets it play nice with strict Content-Security Policies

But why stop there when we could be perfectionist

GitHub’s current implementation also has what I presume is a bug, where it looks silly inside larger text:

SVG’s width and height attributes can use ems to scale the dot with the font size:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    class="ml-1 border circle color-border-subtle"
  >
    <rect width="100%" height="100%"/>
  </svg>
</code>

Heck, you could even replace GitHub Primer’s utility classes with SVG’s builtins:

<code>#aa4400
  <svg width=".667em" height=".667em"
    fill="#aa4400"
    viewBox="-9 -8 17 16" stroke="var(--border-subtle)"
  >
    <circle radius="16"/>
  </svg>
</code>

GitHub probably won’t, since once you choose utility classes for something you need to use them everywhere or their core performance promise falls apart¹, but maybe you might?

By the way, GitLab does this too

And as usual, GitLab implemented the feature more thoughtfully than GitHub did². They support more color syntaxes and transparency, it doesn’t have the font-size scaling bug, and the markup is refreshingly simple:

<code>HSLA(540,70%,50%,0.3)
  <span class="gfm-color_chip">
    <span style="background-color: HSLA(540,70%,50%,0.3);"></span>
  </span>
</code>

It still breaks with forced colors and dark mode, so maybe the GitLab peeps would be interested in this article anyway. (I also refactored theirs to be shorter, simpler, and with one less <span>, because I’m insufferable.)

Speaking of accessibility, there’s something I haven’t addressed…

Accessibly exposing the color

So, that <svg>. What’s its role? Its accessible name? Should it be announced at all?

For this specific case, it has a text equivalent right alongside it, and GitHub’s audience is tech-savvier than usual — I can imagine that GitHub may have decided announcing the color dot separately was superfluous.

…but I disagree. Displaying the color adds information for sighted users, hence why the feature exists at all; for the ideal of information parity across disability boundaries, we should try to be equitable.

Since the hex code is already there, a proper text alternative would be the information equivalent of displaying the color dot. Maybe a color name via something like the ISCC–NBS system?³

Trying to explain colors to people who can’t see them isn’t the goal — but naming a color consistently can be quite useful by itself. Not to mention, blind people may want to know for its own sake!

<code>#aa4400
  <svg role="img" aria-labelledby="_Z5jdHi6">
    <title id="_Z5jdHi6">Color: “firebrick”</title>
    …
  </svg>
</code>

• I’m not 100% sure you need the role — the state of the art with inline SVG accessibility has changed a lot recently, as this StackOverflow question, answer, and interspersed comments show.

• Using <title> shows up on hover, which helps colorblind folks disambiguate when they need to.

• I’m using aria-labelledby because aria-label still isn’t machine translated. (Then again, I’m not sure Google/Bing translate inline SVG yet either.)

I don’t have a real conclusion but here’s a fun fact

When I first started learning about color accessibility, the explanations of what each colorblindness variety sees instead of the “real” colors bothered me — how could they be so sure? While normally I’m happy to leave “do you and I see the same red” to the philosophers, this was too important for a hand-wavy justification to satisfy me.

Days later, lost and confused from scientific papers about human retinas, the occipital lobe, signal processing, and other complexities around one of the first skills babies learn, I found an answer that was so prosaic it made me laugh: some people are colorblind in only one eye.

1. Any feature you have to “earn” by adhering to a technology and you shall have no technologies before it is one I distrust. Migrating away from something like Tailwind is suspiciously difficult. (This is my footnote and I can be crankety if I want to.) ↩

2. Using GitHub Actions after working in GitLab CI is like disassembling a perfectly good sandwich and making it into sushi. It all eventually goes where you need, but nobody’s happy. ↩

3. There’s a bunch of color naming systems and even more color naming NPM packages, and I’m not qualified to recommend any of them. ↩