Accessibility statement
This statement describes the accessibility of the downpipes documentation site you are reading. It is for anyone evaluating the docs against an accessibility requirement, and for an assistive-technology reader who wants to know what to expect beforehand.
The short version is that this site targets WCAG 2.2 Level AA, that the target is self-assessed 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. The known limitations are listed below.
Conformance target
The conformance target is the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, applied across the documentation, this page included. No page on this site claims Level AAA.
The basis of the claim is self-assessment backed by automated testing. The site has had no external audit, and no one has verified full conformance. Automated tools cannot judge every success criterion, so some criteria are assessed by manual review.
WCAG 2.2 AA is the target. It is self-assessed, 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 |
|---|---|
| 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 |
| Document language | The page declares lang="en-AU" so a screen reader pronounces the content with the right voice |
| 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 |
| 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 |
| 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 element that had focus before it opened |
| 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 |
| 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 |
| Reduced motion | When the reader asks the operating system to reduce motion, animation and smooth scrolling are cut to a near-instant duration |
| 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 |
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). That height comfortably clears 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.
Subresource Integrity is not applicable
Subresource Integrity is not in force on this site, because it has nothing to guard. Every script the site ships is served from the site’s own origin. There is no third-party bundle loaded from an external host, and the Content Security Policy restricts scripts to the site’s own origin.
That policy is part of the security-header set. 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. 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.
Known limitations
The first limitation is the scope of automated testing. Automated testing covers a representative sample of pages, chosen to cover each page type and component pattern, not every page. 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 no tool confirms them.
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. No independent expert has audited the site against the target.
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. 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, 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 accessibility@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. Use that mailbox for accessibility reports on the documentation. The mailbox is kept separate from general correspondence so a report routes and is tracked as accessibility feedback rather than a sales enquiry. We aim to reply within five business days with what we intend to do and by when.
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
For the product’s security properties and their limits, see security properties and their limits. The product’s security assessment 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 .