Machine Surface Footer

Updated 2 weeks ago

Accessibility

Target: WCAG 2.2 AA.

Landmarks

<footer> at the page's outermost scope is an implicit contentinfo landmark — it must be the last landmark on the page. The three columns are visually labelled with real h2 headings, which is sufficient structure; no additional ARIA landmarks are needed inside the footer itself.

Not decorative — these are real links

The monospace styling signals "machine-readable surface," but every link in the machine-surface column (/tokens.json, /components, /research, /healthz) is a genuine, navigable link for sighted keyboard users and screen-reader users alike — not a visual flourish. Treat them exactly like the human-facing links beside them: real <a href> elements, included in tab order, with link text that stands on its own when read out of context (a screen reader announces "/healthz link," which is already self-describing — no additional aria-label needed here). None are placeholder # targets — an endpoint listed here that does not resolve is a violation of the pattern's own purpose (see Usage, When not to use), independent of any WCAG criterion.

Monospace is not the semantic signal — use <code>

Font-family alone must never be the thing that tells an assistive-technology user "this text is an endpoint/code token, not prose." A visual monospace typeface applied only via CSS (as the recipe's html currently does — <a href="/tokens.json">/tokens.json</a> with no inline semantic wrapper) is announced by a screen reader identically to any other link text; the "this is code" meaning is lost entirely for non-sighted users, and is lost for sighted users too under any stylesheet override or reader-mode extension that strips font-family. Each endpoint string should be wrapped in a <code> element inside the anchor — <a href="/tokens.json"><code>/tokens.json</code></a> — so the semantic is carried in markup, with the monospace look then simply following from the browser's default <code> styling (or the recipe's own CSS keyed off the element, not a class-only convention). This is a real gap in the recipe as currently authored, consistent with its status: "stub"; it should be closed before promotion out of stub.

Contrast

{semantic.ink-secondary} (link/body text) and {semantic.ink-tertiary} (base-bar text) must each resolve to at least 4.5:1 against {semantic.surface-default} at whatever size the theme renders them (WCAG 1.4.3, AA — the recipe's stated target). recipe.json does not carry resolved color values, so no specific ratio can be asserted here without checking the active theme's token output; verify per-theme at token-resolution time, particularly for the 12px base bar, which is both the smallest text in the component and the one token (ink-tertiary) deliberately chosen to read as de-emphasized — de-emphasis must not be allowed to cross the line into failing contrast.

Keyboard interactions

KeyBehaviour
TabMove focus through brand, machine-surface, and provenance links in column order
Shift + TabMove focus to the previous focusable element
EnterFollow the focused link

Colour independence

Link state (hover/active) is communicated by the interactive-primary colour change alone in the base recipe — consuming pages that need a non-colour signal (e.g. for a forced-colors media query) should add an underline-on-hover fallback, consistent with how the rest of the substrate handles forced-colors elsewhere.

Important Information

Design System disclosure

This site provides open-source design tokens, documentation, and self-hostable software published by Woodfine Capital Projects Inc. Information here is for general reference only and does not constitute an offer, warranty, or a guarantee of fitness for any particular purpose. Statements regarding planned, intended, or targeted future features are forward-looking and subject to change without notice; they are not undertaken to be updated except as required by law.