Duplicate in-app accessibility controls collide with system settings
Aliases: dual settings · in-app accessibility toggle · settings conflict
What it is
The OS already has Larger Text; the app Settings add Reading size. The OS already has Reduce Motion; the app adds Turn off animations. Two switches for the same job, and the user cannot tell whose value wins or what happens if one is turned off. Competing accessibility settings is not “the app ignores the system.” It is two control surfaces claiming the same job with an opaque compose rule.
Typical shapes: system large, in-app small, app wins; both on, type multiplies and blows the layout; in-app default off, covering a system preference that was already on.
Why it happens
Two settings are two state machines and no single compose function. If the app reads local storage before the system, a stored “off” covers a system “on.” The user just finished the OS slider, walks into the app, still sees small type, goes back to twist the system — it will not move, because another copy is in force. The inverse also holds: in-app large type, system still default, other apps snap back to small, and no stable bodily strategy forms.
The second layer is debug cost. Accessibility users already spend attention on making the interface readable. Two switches force a Cartesian experiment: system on/off × app on/off, which of four cells is the one they need. Without a visible “now in force: system 135% + app offset 0,” the experiment has no end. Support becomes “please also turn on the one in the app,” which is an admission that the system copy was voided.
Studying it
Give participants two real switches (system Dynamic Type + in-app size; system Reduce Motion + in-app “less animation”). The task is “make body text readable, stop the motion.” Record the path: which set they touch first, whether they go back and forth, which of the four cells they land in, whether they can explain the compose rule. Add a cell that writes “Following system, currently 135%” on the surface.
Independent variables: presence of a second switch, whether defaults override the system, whether the composed result is shown. Dependent variables: steps to the target state, misattribution (blame OS or app), setting rollbacks.
Where it stops holding
Content preferences are not a collision: type follows the system, but serif versus sans and “darken the content pane only at night” can stay in-app because the OS has no counterpart. An accessibility shortcut that pulls contrast, motion, and type to a safe combo for this app is not a parallel state machine if it is clearly a temporary overlay on system values and restores them on exit. Browser zoom stacked on system type is platform behaviour; the app should not add a third copy. Car and watch OSes expose few items, so an in-app switch may be the only surface; call it a collision only after confirming the system actually offers the same item.
Applying it
- Do not ship a same-named switch for an item the OS already has; if “even larger than the system” is required, make it a visible offset and spell out “current = system × offset.”
- Defaults must be follow-system; do not ship “medium / off” that covers a system item the user already turned on.
- The settings page should read out the system value currently in force, not only the app’s own three-step control.
- How to check: max system type, then install (or clear local storage) and open the app. If body text returns to medium, the default is covering. Then twist the in-app control to minimum and see whether it can beat the system — if it can, with no explanation, the two are fighting. Ask someone outside the team “whose value applies now”; if they cannot answer, the collision holds.
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.4 Apps must respond to system setting changes live, not only on restart
- Nearby: J2.11 Reflow and text resize · J4.11 Consistency as cognitive support
- Search terms:
competing accessibility settings·duplicate settings·follow system