Legal

Accessibility

How this website, and any site built with Project Broadsheet, aim to be usable by everyone.

Last reviewed: 2026-04-17

Project Broadsheet is designed to meet WCAG 2.2 Level AA. This page describes the standards we target, the accessibility features built into this website and the framework, and how to report an issue if you hit a barrier.

Standards we target

  • WCAG 2.2 Level AA. Perceivable, Operable, Understandable, Robust
  • Section 508 (US federal procurement standard), met through WCAG 2.2 AA conformance
  • EN 301 549 (European accessibility directive), met through WCAG 2.2 AA conformance

Features built into this website

Perceivable

  • Color contrast. Body text is 15.6:1 against the background, more than three times the AA minimum. Muted/secondary text is 7.1:1. Accent colors (vermillion, slate) are 5.2:1 and 6.8:1 respectively. See the full contrast table.
  • Dark mode. Automatic detection via prefers-color-scheme, plus a manual toggle. Contrast ratios are independently verified in both modes.
  • Text alternatives. All meaningful images have alt attributes. Decorative SVGs carry aria-hidden="true".
  • Scalable text. All sizes use rem and clamp(). Zooming to 200% doesn't break layout or clip content.
  • No flashing content. Nothing on this site flashes more than three times per second.

Operable

  • Keyboard. Every interactive element is reachable by keyboard. Tab order follows visual order.
  • Skip link. The first focusable element on every page is "Skip to content", jump past navigation with one key.
  • Focus ring. A visible 2px vermillion outline with 3px offset appears on every focused element. :focus-visible means it only shows for keyboard users, not mouse clicks.
  • Touch targets. Every interactive element is a minimum of 44×44 CSS pixels, meeting WCAG 2.5.5 at AAA.
  • No time limits. Nothing auto-refreshes, auto-dismisses, or requires a timed interaction.
  • Pausable motion. Any motion on this site honors prefers-reduced-motion.

Understandable

  • Clear language. We write in plain English. Technical terms are linked to definitions where available.
  • Consistent navigation. The same header, hamburger panel, and footer appear on every page in the same location.
  • Form labels. Every form field has a visible, associated <label>. Required fields are marked with a visible asterisk and required attribute.
  • Helpful errors. Invalid form fields show clear, text-based error indicators (not color alone).

Robust

  • Semantic HTML. We use the right element for the job. <nav>, <main>, <article>, <button>, <a>, so assistive technology can interpret the page correctly.
  • ARIA where needed. aria-label on icon-only buttons, aria-current="page" on active nav links, aria-expanded on toggles, role landmarks on header, main, and footer.
  • Valid HTML. The site passes W3C validation. No closing-tag drama.

Features built into the framework

Project Broadsheet itself ships with reader-experience features that go beyond WCAG compliance:

  • Font picker. The system default plus nine web fonts, including Atkinson Hyperlegible for low-vision readers
  • Reading ruler, customizable thickness and color to aid line tracking
  • Focus mode, dims everything except the article body
  • Highlights and notes, six colors, persistent per-device
  • Adjustable spacing, tight / normal / relaxed line-height
  • Adjustable word spacing, normal / wide / extra wide
  • Adjustable font size, pixel override from the site default
  • Import/export, take all your reader data with you as JSON

Known issues

We maintain this list honestly. If something breaks, we say so.

  • Pagefind search UI, the third-party Pagefind component renders its own DOM. We apply our focus styles to it, but we cannot verify every internal keyboard path.
  • Third-party embeds, if a page includes a Buttondown form, YouTube embed, or Google Map, those iframes carry their own accessibility profile outside our control.
  • Form error messaging, we rely on native browser constraint validation. Error messages are clear but visually unstyled in some browsers.

If you find anything else, please report it.

How to report a problem

The fastest way:

We aim to acknowledge accessibility reports within one business day and fix confirmed barriers within 30 days. Critical barriers are fixed immediately and deployed the same day.

Assistive technology tested

This website has been tested with:

  • VoiceOver (macOS, iOS)
  • NVDA (Windows)
  • Chrome DevTools Accessibility panel
  • axe DevTools automated scan
  • Keyboard-only navigation (no mouse)
  • 200% browser zoom
  • macOS / iOS Increase Contrast mode
  • Windows High Contrast mode

Technical specifications

This website is built on:

  • Eleventy v3 (ESM), a static site generator
  • Semantic HTML5, rendered as static files
  • Vanilla CSS with prefers-color-scheme and prefers-reduced-motion
  • Vanilla JavaScript, progressive enhancement, site works without JS for read-only browsing
  • No frameworks, no bundlers, no runtime dependencies

The full source is at github.com/jonajinga/project-broadsheet, audit it yourself if you like.

This statement

This accessibility statement was last reviewed on April 17, 2026. It's reviewed every six months and after any significant site change.

Have a look around

Project Broadsheet is free to try on your own computer, or you can see it already running at The Freethinking Times. If you'd rather have a hand setting it up, write to me.

How to start Write to me