Accessibility

Accessibility is declared in the widget trait and gated in CI rather than added afterwards, and the conformance claim that sits on top of it stays yours.

Teksilo supplies primitives. A conformance claim is an application-level artifact, always, and no toolkit can make one on your behalf. What a toolkit can do is give you pieces that are correct by construction, and be clear about where its job ends and yours begins.

What the framework gives you

• Accessibility is declared in the trait. Widget::accessibility(&self, builder: &mut AccessNodeBuilder) sits beside layout_response and paint, so the assistive-technology tree is built alongside the widget tree rather than reconstructed from it afterwards.
• A real AccessKit bridge on every window. One window constructor, and the platform bindings underneath are real on all three desktop systems: AT-SPI over D-Bus on Linux, identical on X11 and Wayland, NSAccessibility on macOS, UI Automation on Windows.
• An override surface on any widget. .access_label, .access_description, .access_role, .access_live, .access_action and the rest, in the shape of SwiftUI's .accessibility* modifiers, with .access_customize(|b| ...) last as the escape hatch. Labels and values bind at AccessibilityOnly, so a translated string changes what is announced without a rebuild.
• Layout scaffolding does not reach the screen reader. The walker collapses semantically empty containers, so a button wrapping a padding wrapping a stack wrapping a label announces as one node. No annotation needed.
• Contrast is gated in CI. A test computes the real WCAG relative-luminance formula over the default themes and fails the build if text or the focus indicator drops below its minimum. Three of the four theme presets carry such a gate.

Three operating-system preferences are followed rather than left for you to wire: increased contrast, text scale from 80 % to 200 %, and reduced motion. They share one preference pipeline, so they cannot drift apart.

What stays yours

Two things the framework cannot do for you.

Widget::accessibility has an empty default body. The trait supplies the slot; it does not make you fill it. A custom widget of yours that skips it announces nothing, and nothing will tell you.

And the conformance artifact is yours: an ACR in the EN 301 549 template for the EU Accessibility Act, a VPAT for Section 508, a déclaration de conformité for RGAA 4.1. RGAA in particular is audited manually with real screen readers, which is exactly the method that catches correct-looking markup that does nothing, and exactly what a source-level assessment cannot replace.