Accessibility statement

Conformance target

WCAG 2.2 Level AAA wherever achievable; Level AA as the minimum for any surface where AAA is genuinely impractical. Where a specific surface falls short, the limitation is noted below.

What this site does

• AAA colour contrast. All body text meets 7:1 against its background; all large text meets 4.5:1; non-text contrast meets 3:1. Verified perceptually via OKLCH lightness pairings; values to be re-verified with a contrast checker as the design evolves.
• Tinted surfaces at constant luminance. The default page surface sits at 95% OKLCH lightness rather than pure white, so prolonged reading is gentler than on a stark white background — the cream-surface, dark-grey-text recommendation from low-vision practice, translated into the site’s palette. Each main-nav landing carries a different hue (mauve for About, rose for Writing, sage for Work, and so on) as a way-finding cue for visitors who can perceive it. Lightness is held constant across every zone, so low-vision users do not need to re-adjust display brightness or contrast as they move between sections — only the hue shifts. The tint is an affordance; no information on the site is conveyed by colour alone.
• Focus appearance meeting WCAG 2.2 SC 2.4.11. A solid 2px outline at the accent colour, offset 3px from the element edge, with a halo box-shadow underneath in the surface colour. The dual-tone treatment ensures the focus ring is distinguishable against any background — including images — and is never confused with a border.
• Type scale capped at 3:1. The largest and smallest text on any page differ by no more than 3:1 in size, so screen-magnifier users do not have to adjust zoom level when moving between headings and body text.
• Honours every prefers-* media query. prefers-color-scheme (light/dark), prefers-contrast (more, less), prefers-reduced-motion, and prefers-reduced-data. No user toggle is provided; the site respects what your browser and operating system already say.
• Native HTML first; ARIA only where native genuinely fails. Real <button>, real <dialog>, real <details>. Custom interaction patterns (combobox, focus management, live regions) appear only on the surfaces that demand them.
• Visible labels for every interactive control (SC 2.5.3). Where a control would otherwise have only an icon or only an image, a visible text label is rendered alongside so voice-control users can speak the same words the screen reader announces. The About page’s image-zoom triggers carry a persistent “View larger” badge; the badge text matches the start of each trigger’s accessible name.
• State indicators are self-contained. Where a control’s visual cue is “this one is current / selected / active” — the pagination current-page indicator, the pill-toggle selected state, the destructive confirm button — the cue is rendered as an enclosed visual property (an outlined box, a background fill, or a heavier border) that is visible on the control itself, not as a typographic comparison against its neighbours. Screen-magnifier users zoomed in on a single control can identify its state without comparing it to siblings they may not see in the same field of view.
• Informative alt text, separate from caption context. Every image carries alt text describing what is visibly in the image. Where a figure also needs contextual information — what the image is, when it dates from, what role it played — that context lives in a visible <figcaption> so it reaches every reader, not only those using assistive technology. Decorative chrome uses alt=“”.
• Structural diagrams are inline SVG, with descriptive <title> and <desc>. Where a page carries a structural diagram — a hierarchy, a flow, a relational network — the diagram is rendered as inline SVG. The root carries role=“img” with <title> and <desc>children supplying the accessible name and a descriptive summary of the diagram’s structure. Every AT engine announces these. Inline SVG also inherits the page’s zone tint and adapts to forced-colors mode automatically, neither of which a raster image provides. (A complete example of the WAI-ARIA Graphics module structure lives inside the SVG markup but is currently overridden by role=“img” because AT support for the module remains uneven; see the colophon for the rationale.)
• Forced-colors mode (Windows High Contrast). Components that rely on colour for meaning carry explicit @media (forced-colors: active) styles that fall back to system colour pairs (Canvas / CanvasText, ButtonText), so dialog chrome, badges and close buttons stay distinguishable when the user’s OS strips the palette.
• Skip link on every page.The first focusable element on every page is “Skip to main content”.
• Semantic landmarks. <header>, <nav>, <main>, <footer> on every page; navigation regions labelled with aria-label.
• Logical properties throughout. inline-size and block-size, margin-block and padding-inline, throughout the stylesheet. The site is structurally ready for languages with right-to-left or vertical writing directions.
• Reading-optimised typography. Body text set in Atkinson Hyperlegible at 19–20px (responsive to viewport) with line-height 1.5 and a measure capped at 60 characters via the universal CSS axiom.
• Progressive enhancement where possible. Site content renders server-side and works without JavaScript; client-side interactivity is layered on top only where it provides genuine benefit (search, the Playground, the Action Language playground).
• Code editors that meet AAA out of the box. Both code-editor surfaces — the analyser Playground at /playgrounds/paradise and the Action Language playground at /playgrounds/action-language — use CodeMirror 6. Tab moves focus out of the editor (no keyboard trap), themes are ordinary CSS (foreground and background overridable per WCAG 1.4.8), and contrast meets the 7:1 floor through the same monochrome tokens the rest of the site uses. Syntax highlighting is rendered with weight and italic rather than colour — the structural cue is non-chromatic by design, so colour-vision deficiencies and high-contrast user stylesheets preserve full information density. The colophon explains the choice in detail.
• Playground simulators for visceral testing. The Playground includes a virtual screen reader, a switch-access simulator (single-switch and dual-switch modes with configurable scan speed), and a session recorder that captures a screen-reader walk for replay later. They are deliberately accurate enough to teach and not so accurate as to be a substitute for the real assistive technology.

Compatibility

The site is tested for compatibility with current versions of the major browsers (Safari, Chrome, Firefox, Edge), with VoiceOver on macOS and iOS, NVDA and JAWS on Windows, and TalkBack on Android. Browser zoom up to 400% has been checked; the layout reflows without horizontal scroll.

Known limitations

• Iframe preview content.The Playground’s preview pane and the simulators that walk it render the visitor’s own HTML / JavaScript / CSS in a sandboxed iframe. The accessibility of what the visitor writes is the visitor’s responsibility — the Playground’s job is to show the accessibility properties of that code, not to fix them. The iframe itself uses appropriate sandbox attributes and the highlight styles injected for the screen-reader and switch simulators honour prefers-reduced-motion.
• Long-form drafts. A small number of long-form drafts in the writing archive contain inconsistencies from being early synthesis attempts on a smaller research corpus. These are being revised in the ordinary writing workflow.
• Speech-synthesis quality.The virtual screen reader can speak announcements aloud via the browser’s Web Speech API. The exact voices, accents, and prosody available are determined by the visitor’s operating system; the simulator surfaces what the platform offers and cannot improve on it. Speech is opt-in for that reason, defaulting to off.

Feedback

If you encounter an accessibility barrier on this site, or an inconsistency between this statement and what the site actually does, please get in touch.

• Email — fastest for narrative feedback or anything that needs a considered reply.
• GitHub Issues — best for specific defects with reproduction steps.

Reports are read; most receive a reply.

How this site is built

The full set of design and implementation decisions is documented on the colophon page, with each decision-log entry linked to its source on GitHub. The site source is public on GitHub under the GNU GPL v3.