What we set out to do

Add a new palimpsest essay to bythewei.co covering Apple’s 41-year accessibility history. The source material was a research article with 84 citations, already written for bythewei.dev as a flat docs post. The goal was to make the .co version fundamentally different — not just a port, but a page that practices what it preaches.

The two-project confusion

The session started in a different Claude instance on bythewei.dev, where the article was first built with Phosphor icons and a PalimpsestLayout. About 90 minutes in, we realized the article was being built in the wrong project. bythewei.dev and bythewei.co are separate codebases with different page structures, different font stacks, different design systems. The article needed to live on the .co site as a palimpsest essay, not the .dev site as a docs post.

The .dev version shipped anyway as a flat markdown document. The .co version became the interactive one.

The design decision: scroll-driven parchment aging

Every existing palimpsest essay on bythewei.co uses a distinct interaction model: Third Space is a draggable node graph, Sword Linguistics is a slideshow, Chinese Room is an interactive simulation, Sapir-Whorf is a hover funnel. The accessibility article needed its own.

The idea: as you scroll through 41 years of history, the parchment surface itself ages. Jobs era (1984-2011) renders on foxed, aged parchment. Cook era (2011-2024) renders on clean parchment. The AI/spatial era (2025+) renders on the freshest surface. The reader literally scrolls through layers of a palimpsest.

Seven interactions total:

Scroll-driven parchment aging (IntersectionObserver + CSS transitions)
Sticky era ribbon with scroll progress
Reader accessibility detection (detects your prefers-reduced-motion, contrast, font scaling and tells you which section of the article covers that feature)
Five pillar cards that unfold on scroll
iOS 6/7 regression toggle (feel the design failure)
Citation marginalia on wide screens
Jobs/Cook split-pane reveal

The irony

After building a 1,619-line article about Apple’s accessibility innovations, we ran a WCAG 2.2 AA audit on the hosting site. Findings:

No skip link on any page
No global focus indicators
No forced-colors support
20+ contrast failures from opacity stacking on muted colors
Clickable divs without keyboard access
outline:none on inputs with no replacement

The new accessibility article was the only page on the site that already had proper skip links, focus indicators, and reduced-motion support. The audit and fixes that followed touched Layout.astro (fixing every page at once) and raised contrast values across the entire site.

The emoji purge

The manuscript aesthetic doesn’t survive emoji. Colored bitmap characters on parchment look wrong. We replaced every emoji across 31 files with Phosphor duotone SVG icons for template elements and Unicode dingbats for inline text strings. The distinction matters: Phosphor components can inherit CSS color and respond to forced-colors mode. Emoji can’t.

One gotcha: HoleDuotone doesn’t exist in phosphor-astro. The build failed. Always ls node_modules/phosphor-astro/ | grep YourIcon before committing.

The agent orchestration

This session used 16+ sub-agents:

5 research agents (one per accessibility pillar)
2 coherency/voice review agents
5 WCAG audit agents (one per page area)
4 fix agents (contrast, semantic HTML, ARIA, icons)
1 emoji sweep agent

The pattern: launch independent agents in parallel, compile findings, apply fixes sequentially. The research agents confirmed the article already covered their findings with one gap (Headphone Accommodations). The audit agents found the irony.

What shipped

PR #17 merged to master: 31 files, 1,914 insertions
Apple accessibility essay live at bythewei.co/glyphary/palimpsest/apple-accessibility/
Same article as flat docs post on bythewei.dev/docs/apple-accessibility-history
Site-wide WCAG P0 fixes (skip link, focus-visible, forced-colors, reduced-motion)
Complete emoji-to-Phosphor migration

What’s next

The “praxis interactions” — making each section of the article demonstrate the accessibility feature it describes. Web Speech API for the MacinTalk section. A VoiceOver simulation for the screen reader section. A switch control demo. A braille display renderer. The browser already has most of these APIs built in. The page just needs to surface them.

The article describes 45 accessibility features. The page currently demonstrates 7 of them through its interactions. The goal is to close that gap until the page is the argument.