Accessibility statement.

Accessibility is treated as a first-class design constraint, not a retrofit. New components are reviewed against the relevant Web Content Accessibility Guidelines success criteria before they ship, and existing components are audited each release.

This applies both to this site (which you are reading) and to the doks open-source software that you self-host. Sites built using doks inherit the baseline accessibility of the components but can also be modified by their operators; conformance of any specific deployment is the responsibility of that operator.

We target conformance with:

• WCAG 2.2 Level AA (W3C Web Content Accessibility Guidelines);
• EN 301 549 v3.2.1, the European harmonised standard for ICT accessibility (which incorporates WCAG 2.1 AA and is the conformance basis for the European Accessibility Act, in force since June 2025);
• Section 508 of the US Rehabilitation Act, as revised in 2018, for visitors who rely on it.

Where these standards differ, we apply the strictest requirement.

This site is partially conformant with WCAG 2.2 AA. "Partially conformant" means most of the content meets the standard; specific exceptions are listed in section 5.

What works well

• Semantic HTML (proper headings, lists, landmarks, labels) throughout.
• Keyboard navigability: every interactive element is reachable and operable with Tab, Shift+Tab, Enter, and Space; the burger menu can be closed with Esc.
• Visible focus indicators in the browser default style; not suppressed by site CSS.
• Text colour against background meets the AA contrast ratio (4.5:1 for body, 3:1 for large headings).
• No motion-based content; no autoplaying audio or video; no flashing.
• Page zoom up to 400% without loss of content or function (per WCAG 1.4.10 Reflow).
• Reduced-motion preferences (prefers-reduced-motion) are respected by the burger animation.
• Forms (currently none on this site) would carry programmatic labels and error messaging.

The site is verified to work with the latest two major versions of:

• Browsers: Chrome, Firefox, Safari, Edge.
• Screen readers: NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
• Operating systems: Windows 11, macOS 14+, iOS 17+, Android 13+.

We do not formally test on Internet Explorer (end-of-life), legacy Edge, or browsers that explicitly block JavaScript.

Honest list, updated each release:

Code-block scroll hint

Long code samples are horizontally scrollable but the scroll affordance is currently visual only; we plan to add a programmatic scroll-region role and a tabindex so it appears in the tab order with a visible focus ring.

Watermark contrast

The decorative doks. watermark in the footer is intentionally low-contrast. It is decorative (aria-hidden="true") and does not convey information, so contrast rules do not apply, but we mention it for completeness.

Italic emphasis on headings

The serif italic used for emphasised words in headings (e.g. answer back) is purely visual and may render poorly on very small screen-reader pitch settings. We are evaluating wrapping these in <em> with an explicit aria-label only where it changes meaning.

Items we have ruled out as not issues: dark-on-white text, link colour distinction (we underline on focus; brand colour passes 4.5:1), and the burger menu's animation (which does not contain meaning beyond open/close state).

Each release is assessed by:

• Self-evaluation against the WCAG 2.2 AA checklist by the maintainers;
• Automated testing with axe-core against representative pages in CI;
• Keyboard-only walkthrough of every page on each release;
• Screen-reader spot-checks on the home page, the chat panel, and one docs page using NVDA and VoiceOver.

The next external audit by an independent specialist is planned for Q3 2026. The result will be published here.

If you encounter an accessibility barrier on this site or in the doks software:

• Open a GitHub issue at github.com/getdoks/doks/issues with the label accessibility;
• Or e-mail accessibility@datadistill.co;
• Or post in the Discussions if you'd prefer a thread.

We aim to acknowledge within 5 business days and provide an action plan within 15 business days. If a fix is straightforward, it ships in the next patch release; structural fixes are queued in the public roadmap on the About page.

If a response from the channels in section 7 is unsatisfactory, EU residents may escalate to the relevant national enforcement body for the European Accessibility Act. A list is maintained by the European Commission. UK residents may contact the Equality and Human Rights Commission. US visitors may file a complaint with the Department of Justice under the ADA.