Rathe UI

How this was built

Decisions worth defending

Eighteen components. I picked them because each one has an accessibility problem that is actually hard, not to get to a round number.

Accessibility, as a build step

A token file is where a contrast regression hides, because someone nudges a colour to look better in one theme and quietly breaks the other one. So I put a gate on the palette. It reads the token file, resolves every declared pair in light and dark, and exits non zero if any pair misses its WCAG 2.2 target.

  ok   light 18.29:1 (needs 4.5)  body text on page
  ok   light  6.98:1 (needs 4.5)  label on primary button
  ok   light  5.90:1 (needs 4.5)  pitch 1 numeral
 FAIL  light  1.95:1 (needs 3)    input borders (SC 1.4.11)
 FAIL  dark   2.25:1 (needs 3)    input borders (SC 1.4.11)

36 pairs checked across 2 themes.
2 contrast failure(s).

That is the first run, not something I put together afterwards. The border colour on text inputs was sitting at 1.95:1 against the page, well under the 3:1 that WCAG 2.2 asks for on non text contrast. It is 3.27:1 in light and 3.46:1 in dark now, and the gate runs in the pipeline so it cannot drift back.

A second gate walks all 113 stories in the built Storybook, in both themes, because checking a component on its own is not the same as checking what a consumer renders. It found a token I had exempted myself. The faintest ink was held to the large text threshold on my own note that it was only used for display sized timestamps, and it was actually being used at 12px for card class and stat labels. An exemption is a promise about how a token gets used, and 25 call sites is too many to keep that promise by hand, so it is held to 4.5:1 now like everything else.

The check that reported nothing

The scene passed its accessibility tests, and that did not really mean much. axe cannot judge contrast for text sitting over a WebGL canvas, because it has no way to know what colour is behind the glyphs. It does not fail those elements. It marks them incomplete, and I was only checking for failures. Thirty seven elements were in that state, which was most of the text on the page.

So I measured it instead. A script makes every glyph transparent, screenshots the page so the image holds only what is actually behind the text, reads that image back in as pixels, and then for each text run samples every pixel inside its box and keeps the one that gives the worst contrast. I keep the worst one because an average hides the moon passing behind one corner of a paragraph.

The first run put 77 of 233 text runs under their threshold. The footer was the worst of them at 2.78:1, which is the part you notice by eye. The chapter rail measured 1.03:1 against the moon, and the wordmark measured 1.04:1 where it crosses a brazier. Fixing it took four colour changes and five scrims, checked against the composited pixels each time. All 233 runs clear their threshold now.

What the scene costs

The whole scene is procedural. No textures, no models, no video, no external requests. Geometry, materials, and every texture are made at runtime, which is why a full 3D environment fits in one file that is smaller than a typical hero image.

Measured 16 August 2026 in Chromium on an Apple M1 Pro. Two caveats belong with the numbers. The mobile row is a desktop browser at a phone viewport with a device pixel ratio of 1, so it does not stand in for a real handset, and a machine this fast will hold 60 fps on work that would drop frames on a mid range Android. What I can say is that the frame budget is stable and the payload is small, not that it has been proven on constrained hardware.

Pipeline

The pipeline runs type checking, unit and accessibility tests, the contrast gate, the story audit in both themes, and a Storybook build, cheapest first so a type error fails in seconds instead of after a four minute build. There is no branch allowlist on the trigger. Everything quoted on this page came from running those checks rather than from describing them.

That last detail is not a preference. While building this I found that the end to end workflow on this site had never actually run, for two reasons at once. The trigger listed main and develop while the branch I work on is master, so pushes never matched. Underneath that, the repository default branch on GitHub still pointed at develop, which was abandoned in June 2025, sits 133 commits behind, and has no .github directory in it at all. GitHub registers workflows from the default branch, so the repository reported zero workflows and every run died at startup before reading a step.

If I had only fixed the trigger it would have looked fixed and still not run, because green and never ran look the same in a repository list. So a pipeline can be broken in more than one place at once.

What is missing

• No visual regression testing. Storybook plus a snapshot runner would catch the kind of change the contrast gates cannot see.
• No real device lab. The performance numbers need a mid range Android before they mean much.
• The set covers primitives and a few domain pieces. A real estate system would want forms at scale, denser data patterns, and print styles for tournament sheets.
• Tokens are not published as a versioned package yet, so a Django consumer would be copying a CSS file rather than depending on one.