Inherit OS accessibility settings rather than shipping a parallel stack

What it is

Type size, bold, contrast, reduced motion, whether the screen is spoken — the user already set these once in the operating system. An app’s job is to read those preferences and inherit them: prefers-reduced-motion, prefers-contrast, prefers-color-scheme on the Web; Dynamic Type and Reduce Motion on iOS; Font scale and animator duration on Android. Shipping a second in-app “accessibility” page that recreates the same capabilities asks the user to configure every product again, and the two values diverge from day one.

Inheritance is wider than “a follow-the-system theme toggle.” It treats bodily and situational conditions the OS has already expressed as inputs to layout and motion, rather than inventing a parallel control surface.

Why it happens

The OS exposes accessibility preferences as platform APIs and media queries so every foreground app shares one user model. Turning system type to the maximum is a speech to all apps. An app that keeps font-size: 14px and its own motion timeline drops that model at the door. A reimplemented stack also has to maintain switches, storage, and migration, and will always lag new system items (per-app reduced motion, differentiate without colour, turn off flashing).

The second layer is trust. Accessibility settings are a cross-app contract: change once, walk into any app, still there. A parallel stack leaves the user unable to tell whose value applies. Inheritance keeps one contract; N parallel stacks split it, and any one of them can be wrong.

Studying it

Turn on larger type, reduce motion, and increase contrast in the OS. Open an app that claims to follow the system and one that has its own accessibility page. Record which system items are mapped, which are ignored, and whether in-app defaults equal the current system values. On the Web, emulate media queries; natively, read traits / Configuration from the accessibility inspector.

Independent variables: combination of system preferences, whether the app claims inheritance, whether it also has built-in switches. Dependent variables: whether type/motion/contrast actually follow the system, which OS items are mapped, whether the user can say which set is in force.

Where it stops holding

Games, drawing tools, and maps sometimes must lock viewport units and cannot grow without bound under Dynamic Type; inheritance then means scaling chrome by the system and offering a reading mode for content, not refusing to read the system at all. An embedded WebView may not see preferences the host already read; the host has to pass the values in. Managed enterprise devices may freeze system items; a local override is then an escape hatch, not the default path. Capabilities the OS does not have (plain-language mode) have no source to inherit; an in-app control for those is not a parallel replica.

Applying it

• Wire type to Dynamic Type / Font scale / the browser’s default font, not to locked pixels; gate non-essential motion with prefers-reduced-motion into cuts or shortened durations.
• Follow prefers-contrast, system high contrast, and dark mode for contrast and colour; do not only ship an in-app skin.
• If the app offers “even larger than the system,” implement it as an offset on top of the system value, not a replacement.
• How to check: change only OS settings, do not touch the app, and open it. If type, motion, and contrast have not changed — system large, app still 14px from the mock — it did not inherit. Turn on reduced motion and see whether launch and route transitions still run at full duration.

Related

• Same group: 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 · J5.13.4 Apps must respond to system setting changes live, not only on restart
• Nearby: J2.02 Text resize · J2.15 Dark mode and high contrast compatibility
• Search terms: inherit OS accessibility settings · prefers-reduced-motion · Dynamic Type