Apps must respond to system setting changes live, not only on restart

What it is

Users rarely finish accessibility settings before installing an app. They twist type size, turn on reduced motion, switch high contrast mid-use — often because of light, fatigue, or vestibular discomfort right now. An app that reads system values only at launch, and then needs a process kill to catch up, freezes “now” into “as of open.” Runtime accessibility setting observation means: when the preference changes, the foreground UI changes in this session. No restart.

This is not whether to inherit. It is which beat inheritance happens on. A launch-time read with no runtime listener still feels like “the setting did nothing.”

Why it happens

Platforms expose the change as events: matchMedia listeners on the Web, traitCollectionDidChange / accessibility notifications on iOS, Configuration and UiMode on Android. Layout, motion timelines, and colour have to subscribe and invalidate their caches. Many apps bake type into a theme object computed at launch, or store animation duration in a singleton; the subscription fires, the singleton does not invalidate, the UI stays old. List cells that froze font at creation time will not rebind when the event arrives.

The second layer is when the user changes the setting. They are often inside the app, jump to system Settings and back, or hit the OS accessibility shortcut in place. A foreground app still showing old type is read as a bug or as “this app does not support it.” Requiring a restart has a harder cost: a screen-reader buffer, unsaved form content, session state — restart throws them away. Live response does not buy elegance; it avoids a destructive process lifetime.

Studying it

Keep the app in the foreground or round-trip through Settings without killing it. Change system type, reduced motion, and contrast one at a time. Record which frame after return starts to change, which surfaces change (nav / list / open modal / WebView), and whether a process kill is required. On the Web, toggle media queries in developer tools. Measure two round-trips: the Settings app versus a Control Center shortcut; latency can differ.

Independent variables: whether the change happens in the foreground, cache layer (theme singleton / cell / WebView), platform. Dependent variables: fraction of surfaces that align without restart, regions still frozen after the round-trip, whether an unsaved form is destroyed.

Where it stops holding

Some engines (game loops, custom text rasterisers) treat a type change as a new resource pack; live may be impossible, in which case say “takes effect on next launch” and do not pretend it already followed. Multi-window, Picture-in-Picture, and CarPlay scenes may miss the main window’s trait events and need their own subscriptions. For the few seconds the user is in system Settings the app is suspended; the event arrives on resume — “live” on mobile is often “the beat of becoming foreground,” not a millisecond push, which still does not license a cold start. Server-built CSS with breakpoints frozen at compile time cannot be saved by a runtime listener; that is a build-chain problem.

Applying it

• Subscribe to the platform preference-change events and, in the callback, invalidate theme, type tokens, and animation duration, then relayout visible surfaces.
• Do not freeze font onto list cells and modals at creation; reread the current system value on reuse.
• On the Web, use matchMedia(...).addEventListener('change'); do not read once at DOMContentLoaded.
• How to check: open the app, do not kill it, twist system type one notch, turn on reduced motion, come back immediately. If the main list, an already-open dialog, and the nav title are still old, it was launch-only. Fill half a form, change a setting, and confirm a restart policy does not destroy it.

Related

• Same group: J5.13.1 Inherit OS accessibility settings rather than shipping a parallel stack · J5.13.2 Ignoring system font size, reduced motion, or contrast splits the experience · J5.13.3 Duplicate in-app accessibility controls collide with system settings
• Nearby: J2.02 Text resize · J2.15 Dark mode and high contrast compatibility
• Search terms: runtime accessibility setting observation · matchMedia · traitCollectionDidChange