Accessibility as a writing preference, not just compliance — what should authors be able to customize?

[qnbs]

Why this exists

Issue #557 is the primary implementation context for making accessibility a durable writing preference rather than a checklist applied after the UI is built. This Discussion explores useful customization without creating an unmaintainable preference explosion.

Product decision space

Consider contrast and themes; font family, font size, and line height; readable text width; reduced motion and transparency; forced/high-contrast modes; keyboard-only operation; focus visibility and restoration; screen-reader announcements for save, offline, and update states; zoom and text scaling; touch-target sizing; caret and selection visibility; and accessible exported documents.

Also consider future Qt accessibility parity, user presets versus system preferences, and which preferences should be inherited automatically from the operating system. Defaults should be coherent, discoverable, reversible, and compatible with long writing sessions across PWA, installed PWA, mobile/tablet, and future native surfaces.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• ♿ Screen-reader/keyboard user: complete operation, clear focus, announcements, semantics, and restoration after dialogs or navigation.
• 👁️ Low-vision/readability: contrast, typography, width, zoom, scaling, caret, selection, and reduced visual noise.
• ✍️ Long-session writer: comfortable reading, predictable editing, low distraction, and presets that do not require constant tuning.
• 📱 Mobile/tablet: touch targets, virtual keyboards, orientation, safe areas, and readable behavior on constrained screens.
• 🖥️ Future native/Qt: preserve the same user intent and accessibility contract across renderers.
• 🧭 Maintainer: prioritize high-value controls, use system preferences where appropriate, and avoid preference explosion.

Questions

• Which accessibility preferences do you configure before every long writing session?
• Which should be global, per-project, per-view, or preset-based?
• Where should system preferences win, and where should an explicit WorldScript choice win?
• Which save, offline, update, and recovery states need a screen-reader announcement?
• What is the smallest useful accessibility preset model?
• Which exported-document accessibility guarantees matter most?
• What must remain consistent between the PWA and future Qt product?

Relationship to implementation

This Discussion is accessibility and workflow design. #557 remains the implementation and acceptance authority; this Discussion does not change its priority, roadmap admission, acceptance criteria, or execution sequencing.