Complete accessibility, reflow, and adaptive appearance gates

[robinbraemer]

Outcome

Make the composer and running interface understandable and operable with keyboard, assistive technology, zoom, text scaling, reduced motion, compact touch layouts, and every supported appearance throughout the real live-editing journey.

Required behavior

• Keep the primary composer, running canvas, Undo, history, and recovery route reachable in every state and viewport.
• Announce agent progress, tool activity, build status, selected element, applied change, cancellation, capability request, and recovery status without overwhelming assistive technology.
• Preserve logical focus and reading position while the canvas updates, selection overlays appear, history opens, errors occur, or a capability decision is requested.
• Provide a keyboard and assistive-technology alternative for every direct-manipulation action in Add element selection and direct manipulation for targeted UI edits #35.
• Ensure the selection overlay does not intercept app interaction unintentionally and exposes semantic target information without duplicating the full app tree.
• Support 320 CSS px, 200% zoom, text scaling, reflow, forced colors where available, and no unintended horizontal page scrolling.
• Provide deliberate light and dark appearances using the same semantic token and contrast contract.
• Respect reduced motion without removing progress, selection, success, error, or recovery feedback.
• Keep protected capability and recovery controls distinguishable from content created by the agent.

Acceptance criteria

• Automated WCAG 2.2 AA checks run on clean workspace, agent-active, streaming, selected-element, direct-manipulation, build-failure, history, capability-request, offline, and recovery states.
• Recorded keyboard-only and macOS VoiceOver walkthroughs complete the end-to-end journey in [Epic] Prove the Flect 1.0 product experience end to end #17.
• A keyboard or screen-reader user can select an element, request a targeted edit, Undo it, restore history, recover from a failed build, and return focus to the running app.
• Production Chromium covers 320 px width, 200% zoom, increased text, forced colors where supported, reduced motion, high contrast, and both supported appearances.
• Every interactive component has appropriate default, hover, focus, active, disabled, loading, and error behavior.
• Dynamic announcements are deduplicated and tested against long agent/tool streams.
• User-created UI cannot obscure or imitate protected capability, history, or recovery controls.
• Visual review confirms the shell remains calm and first-party without accessibility-only duplicate workflows.
• No test or screen requires Shape/Use, Keep/Reject, candidate, safe-mode, or internal-agent terminology.

Non-goals

• Encoding meaning only through animation, color, or pointer hover.
• Claiming accessibility from automated audits alone.
• Forcing user projects to adopt Flect visual styling outside protected controls.

[robinbraemer]

Accessibility and adaptive appearance implementation is green in the current worktree.

Delivered:

• one atomic workbench announcement for target, candidate, activity/cancel, and recovery state
• keyboard-scrollable named transcript and protected focus restoration
• modal extension/recovery actions so obscured background targets are inert
• safe-mode hit testing outside the docked rail plus a compact protected route
• semantic automatic dark/light appearances and dual-theme Shiki output
• forced-colors, reduced-motion, 640 px zoom-equivalent, 320 px, and 200 percent text reflow

Verification:

• 499 unit/contract tests passed, one intentional skip
• 32 production Chromium tests passed
• pinned Axe WCAG 2.2 A/AA state matrix passed
• 18 Rust tests passed
• fresh ad-hoc-signed Flect.app built and launched
• packaged macOS AX tree exposed named Safe mode, Preview App Agent, conversation, revision decision, Keep/Reject, Diagnostics, composer, role targets, model, and send controls
• dark, light, native, and compact forced-colors screenshots visually inspected

Canonical evidence: docs/verification/2026-08-01-accessibility-appearance-verification.md

Residual: macOS VoiceOver was off and was not enabled because it would take over the user input/audio environment. Keep this issue open only for the bounded spoken VoiceOver ordering/rotor walkthrough; automated WCAG, keyboard, reflow, appearance, and native AX export are proven.

[robinbraemer]

Fresh gate evidence on 2026-08-01 found and fixed two real regressions: the Actions menu placed a live status inside role=menu, violating required children, and the light-theme primary hover pair had 1.84:1 contrast. The status now sits outside the menu role and primary hover uses the cross-theme contrast token. The full five-state production-Chromium WCAG A/AA appearance/reflow matrix passes again. A canonical Git-backed browser reset fixture also replaced localStorage-only setup so accessibility evidence starts from matching revision and repository state.

[robinbraemer]

2026-08-01 complete-gate update:

The production-Chromium accessibility matrix is green after fixing two defects discovered by the gate: Actions no longer places role=status directly inside role=menu, and light-mode primary hover now has a semantic high-contrast foreground. The matrix covers blank, candidate, accepted, safe, Actions, Diagnostics, and model states plus dark/light appearances, keyboard paths, zoom-equivalent reflow, 320 px layout, 200% text, forced colors, reduced motion, and automated WCAG checks.

bun run check:all passed all 58 Chromium journeys alongside 563 unit/integration tests (+1 intentional skip), 18 Rust tests, and local app bundling. VoiceOver and the remaining platform/device matrix stay open.

[robinbraemer]

Pushed verification update — 2026-08-10

The pushed branch passes the full production accessibility matrix: AXE, AA contrast, keyboard/focus, light/dark, forced colors, reduced motion, 200% text, 320 px reflow, and compact 44 px targets. Final AXI Chrome Lighthouse scores are 100 for Accessibility, Best Practices, SEO, and Agentic Browsing. The packaged macOS Accessibility tree also exposes the editable composer, provider actions, standard menus, and native window controls.

Manual spoken VoiceOver and clean packaged-host assistive-technology evidence remain required before closure.