Accessibility

What works, what doesn't, and how to report issues

axilog.io aims to be accessible to all readers. The site's brutalist register makes most accessibility fundamentals straightforward — semantic HTML, high contrast, static pages, no JavaScript dependency for reading. Known limitations exist, named below. No formal audit has been performed; this statement is based on inspection at the time of writing.

Last reviewed:

Spey Systems Ltd aims for axilog.io to meet WCAG 2.1 Level AA conformance where the site's content and structure make this verifiable. The framework's specifications are intended to be readable by every auditor and integrator who needs to verify them, which includes readers using screen readers, keyboard navigation, high-contrast modes, or text-zoom settings.

Conformance is not certified by a formal audit at the time of writing. This statement describes the current state based on inspection of the site's HTML, CSS, and rendered output.

  • Semantic HTML throughout. Pages use proper heading hierarchy (one <h1> per page, structured <h2>/<h3> beneath), landmark regions (<main>, <nav>, <section>, <footer>), and labelled navigation regions (aria-label on each <nav>).
  • High contrast in both themes. The light theme renders ink (#0F1115) on paper (#FAFAF7) at approximately 18:1 contrast ratio — well past WCAG AAA's 7:1 threshold for normal text. The dark theme renders ink (#F0EDE4) on paper (#0E1116) at a similar ratio. Secondary text colours (--ax-ink-soft, --ax-grey) remain above the AA threshold of 4.5:1.
  • Static HTML, no JavaScript dependency for content. Every reading surface renders fully without JavaScript. The only inline JavaScript is the theme boot script in Layout.astro which sets the light/dark theme before paint; if it fails, the page falls back to the light theme without breaking.
  • Keyboard navigation. All links, navigation elements, and the theme toggle are keyboard-focusable. No focus-trapping modals or off-canvas drawers; the sticky header is CSS-only and does not steal focus.
  • Text zoom and reflow. The reading column is constrained to 72ch on prose pages and uses relative units (rem) throughout the type scale. Pages remain readable at 200% browser zoom without horizontal scrolling.
  • Theme respects user preference. The theme boot script checks prefers-color-scheme on first load and respects an explicit user choice stored in localStorage on subsequent loads.
  • Self-hosted fonts, no third-party CDN. Inter and JetBrains Mono are served from the site's own origin, so font rendering doesn't depend on a third-party service being reachable.
  • Diagrams as DOM text where possible. The framework layer-stack on /framework/ is rendered as CSS-bordered HTML rather than as an opaque SVG, so the layer names, descriptions, and determinism classes are real text that screen readers, Cmd-F search, and copy-paste all reach.
  • Mathematical notation on /manifesto/. The manifesto page renders mathematical notation using KaTeX, which emits MathML alongside its rendered output for assistive technology. Screen reader support for MathML is uneven across readers; the manifesto's mathematical content may not be navigable in the same way as the surrounding prose for readers using older screen-reader / browser combinations.
  • Search UI on /search/. The full-text search at /search/ uses the Pagefind default UI. Pagefind is generally accessible — keyboard navigable, screen-reader compatible — but the search results panel inherits Pagefind's own accessibility characteristics rather than being authored locally. Reported Pagefind accessibility issues are tracked upstream.
  • Per-spec PDFs. The downloadable PDFs at /specs/<slug>.pdf are generated from the same HTML source as the spec pages and inherit the semantic structure, but PDF accessibility depends on the reader application. The HTML version at /specs/<slug>/ is the recommended primary reading surface; the PDF is for offline archive and audit use.
  • Open Graph card images. The per-spec social-share images at /og/specs/<slug>.png render the spec id, title, and a short metadata strip as a rasterised image. They're sent to social platforms, not displayed on the site's reading surfaces, so their lack of alt-text equivalents does not affect on-site accessibility — but they are not themselves accessible artefacts.
  • No skip-to-content link. The site does not currently provide a "skip to main content" link at the top of each page. With a 4-link primary navigation this is less of an issue than on heavily-navigated sites, but it remains a gap against WCAG 2.4.1 (Bypass Blocks).
  • No formal audit. The site has not been audited by an accessibility specialist or automated WCAG conformance tool against the full AA criteria set. This statement reflects inspection rather than verified conformance.

If you encounter an accessibility barrier on axilog.io, please report it to security@speytech.com. Include the page URL, your assistive technology and browser combination if relevant, and a description of the issue. Spey Systems Ltd aims to acknowledge reports within five working days and to communicate a remediation plan or timeline as part of that acknowledgement.

Reports about specific WCAG criteria (e.g. "the contrast on /roadmap/ fails 1.4.3") are particularly useful, but a plain description of what didn't work is sufficient — the remediation will identify which criterion applies.

UK public-sector bodies are required to meet WCAG 2.1 AA under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. axilog.io is operated by Spey Systems Ltd, a private limited company, and is not subject to those regulations. Spey Systems Ltd voluntarily aims for the same standard because the framework's audience includes regulated-industry readers for whom accessibility is a procurement requirement.

For complaints about how Spey Systems Ltd handles an accessibility report, contact security@speytech.com for an internal review. Visitors with concerns about how their personal data is handled when submitting an accessibility report can refer to the Privacy Policy.

This statement is reviewed at least annually, and amended whenever a known limitation is remediated or a new one is identified. The "Last reviewed" date at the top of the page records the most recent revision. Earlier versions of this statement can be requested by contacting Spey Systems Ltd at security@speytech.com.