Accessibility statement
This statement describes the accessibility posture of the downpipes documentation site you are reading. It is written for anyone evaluating the docs against an accessibility requirement, and for a reader who relies on assistive technology and wants to know what to expect before they start. It describes only the conformance and the checks actually in force on this site, taken from the layout code and the continuous-integration configuration, not an aspiration or a borrowed claim from another product.
The short version is that this site targets WCAG 2.2 Level AA, that the target is self-assessed and enforced by automated checks on every change rather than confirmed by an external audit, and that this page is held to the same Level AA bar as the rest of the site. Where a limitation exists it is named below rather than left for you to discover.
Conformance target
The conformance target is the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, applied across the documentation, this page included.
The basis of the claim is self-assessment backed by automated testing. We do not claim an external audit and we do not claim full conformance. Automated tools find a large share of common barriers but cannot judge every success criterion, so the honest statement is that the site is engineered to meet Level AA, that the gates below fail the build on the violations they can detect, and that some criteria still rest on careful authoring and manual review rather than a tool result.
WCAG 2.2 AA is the target the site is built and tested against. It is self-assessed and enforced in CI, not externally audited.
What the layout engineers in
The accessibility features below are built into the shared layout and the component kit that render every page, so they are present on this page and on every other page in the documentation.
| Feature | What it does | Where it lives |
|---|---|---|
| Skip to content | A keyboard link that is the first focusable element, visually hidden until focused, jumps past the header and navigation straight to the main landmark |
DocsLayout.astro |
| Document language | The page declares lang="en-AU" so a screen reader pronounces the content with the right voice |
DocsLayout.astro |
| Sidebar current page | The active link carries aria-current="page", and the section that contains the current page is expanded on load rather than left collapsed |
Sidebar.astro |
| On-this-page contents | A sticky table of contents tracks the heading in view with an IntersectionObserver and marks it as the active entry, so your place in a long page is always visible | TableOfContents.astro |
| Search dialog | A search dialog marked up as role="dialog" with aria-modal="true" and a labelled heading, opened with Cmd or Ctrl plus K, closed with Escape, with focus trapped inside while it is open and returned to the trigger when it closes |
SearchDialog.astro |
| Tabbed content | Tabs that follow the WAI-ARIA tabs pattern: a roving tabindex, and automatic activation, where the arrow keys, Home and End both move focus and switch the panel in the same action | mdx/Tabs.astro |
| Light and dark themes | A theme that respects the operating-system preference on first visit, remembers an explicit choice, and applies before first paint so there is no flash of the wrong colour | BaseHead.astro, ThemeToggle.astro |
| Reduced motion | When the reader asks the operating system to reduce motion, animation and smooth scrolling are cut to a near-instant duration | global.css |
| Visible focus | Every interactive element shows a visible focus ring under keyboard focus, drawn with an outline and an offset so it stays clear of the element’s own border | global.css |
A note on target size, because it is a WCAG 2.2 addition. The search filter chips set an explicit minimum height of 2.25rem (36 CSS pixels), which is comfortably above the 24-by-24 CSS pixel Level AA minimum target size (SC 2.5.8). Other interactive controls inherit their size from their text and padding rather than from an enforced minimum, which is one of the reasons the site is held to AA by review as well as by the automated gates.
The checks that back this statement
Accessibility on this site is not a one-off pass. The repository runs automated accessibility checks on every change, and several of them fail the build rather than warn. The checks below are what make the conformance claim mechanical rather than aspirational.
The axe-core gate
A GitHub Actions workflow runs the axe-core engine against a representative set of pages on every push and pull request to the main branch (a11y-axe.yml). It builds the site, serves the static output, and audits the page list in tests/a11y/pages.json. The audit runs at the tag set wcag2a, wcag2aa, wcag21a, wcag21aa and wcag22aa, and the run fails the build on any violation axe finds against that tag set, regardless of the impact rating axe assigns it.
This page is audited at the same Level AA bar as the rest of the site, in the same axe-core run. The workflow keeps a stricter AAA pass in reserve for any page explicitly marked as a legal tier, but no page currently claims Level AAA, so that pass has nothing to scan today. Claiming AAA here while the shared layout is engineered to AA would be exactly the kind of borrowed claim this page sets out to avoid.
The page list is kept deliberately tight so the gate stays inside its time budget. It is a representative sample, one page per page type and one per interactive island, not an exhaustive crawl of every page. A clean axe run is strong evidence of accessibility on the audited pages, not a proof of conformance on every page in the corpus.
Pa11y for local triage
A second tool, Pa11y, is wired for local use through run-pa11y.mjs. It walks the same page list and writes an HTML report per page so an author can triage issues before opening a change. It is a developer convenience and not a blocking gate: if Pa11y is not installed, the script prints a hint and exits cleanly so it never blocks a local build. The blocking accessibility gate is the axe-core run described above.
The Lighthouse budgets
Lighthouse runs in CI against the built site and asserts a set of category budgets as the median of three runs (lighthouserc.json). The accessibility category must score a perfect 1.0, and the run fails if it does not. The best-practices and SEO categories are also gated at 1.0, and performance must score at least 0.9. A low accessibility score therefore breaks the build, which keeps regressions from landing quietly.
The render-correctness gate
A render-correctness check loads each page in a headless browser and asserts that the page actually rendered as intended (check-render.mjs). It fails if any Content Security Policy violation fired, if the page came back unstyled, or if the HTML was served in a cacheable way that would desynchronise the per-request security token. This matters for accessibility because a page that loaded with its styles or its scripts blocked is a broken page for everyone, and especially for a reader whose assistive technology depends on the intended structure being present.
The security worker
Every response is served through a Cloudflare Worker that applies the full security-header set and a Content Security Policy with a per-request nonce, so inline <script> and <style> elements run from a freshly generated token rather than a blanket unsafe-inline allowance (worker.ts). Inline style attributes are a separate case: Shiki’s syntax highlighting emits them directly, so the policy permits them through a fixed style-src-attr 'unsafe-inline' rather than the nonce. The script and style element sources are restricted to the site’s own origin. Strong security headers and accessibility are not in tension here, because the same render-correctness gate proves that the policy does not silently break the page.
Subresource Integrity is not applicable
A reader checking the build against a security baseline may expect a Subresource Integrity declaration on the site’s scripts. Subresource Integrity is not applicable to this site, and we do not claim it is in force. Astro compiles and bundles every script the site ships from its own source at build time, and there is no pinned third-party bundle vendored from an external host to protect with an integrity hash. The Content Security Policy already restricts scripts to the site’s own origin, so there is no external script for an integrity attribute to guard. Claiming Subresource Integrity here would describe a control the site does not actually have.
Known limitations
Honesty is the point of this page, so the current limitations are stated rather than hidden.
The first limitation is the scope of the automated checks. The axe-core and Pa11y runs cover a representative page list, not every page, and automated tools detect only a subset of WCAG success criteria. Several criteria depend on judgement, such as whether link text makes sense out of context or whether an instruction reads clearly, and those rest on authoring discipline and review rather than on a tool result.
The second limitation is target size. As noted above, only some controls set an explicit minimum target size. The remaining controls meet the criterion through their text and padding rather than an enforced floor, which is why this site is self-assessed at AA rather than claimed as a fully audited result.
The third limitation is the absence of an external audit. The conformance target is enforced by the gates above and by review, and that is a meaningful and mechanical bar, but it is not the same as an independent expert audit, and this statement does not present it as one.
The fourth limitation is that this is a documentation site, not the downpipes product console. This statement covers the docs you are reading. The console and the engine are assessed separately under their own security work, and a claim made here should not be read as a claim about those surfaces.
Report an accessibility issue
If something on this site is hard to use with your assistive technology, or you hit a barrier the checks above did not catch, please tell us. A clear report is the fastest way to get a fix made, and reports from readers are how the manual share of conformance actually improves.
Write to sales@downpipes.io with the page address, a short description of the barrier, and the assistive technology and browser you were using if you can include them. That mailbox is the canonical contact for the documentation, and an accessibility report is treated as a priority rather than general correspondence.
What to include for the quickest fix
A report is most actionable when it names the exact page address, the specific control or content that was the barrier (for example a particular tab strip, the search dialog, or a code block), what you expected to happen, and what actually happened. If you can add the assistive technology, its version, the browser, and the operating system, that narrows the cause considerably. None of this is required to report a problem; send what you have and we will follow up for anything missing.
Where this fits
This statement sits alongside the wider honesty posture of the documentation. The discipline behind every claim, and the residual risks stated plainly, live on the precise claims and honesty page. The deeper security assessment that informs what the docs and the product will and will not say is summarised in the compliance and evidence overview. If you are new to the documentation, the home page is the place to start, and the troubleshooting reference is the first stop when something does not behave as written.
Last updated .