What the Update Forgot: A 2026 Audit Protocol for Accessibility Settings That Vanish in UK Apps

An app update is usually presented as maintenance: a security patch, a performance improvement, a new screen. For some users, it is also a reset. Text returns to a default size, high contrast switches off, reduced motion is ignored, captions default to off, and a carefully arranged reading experience disappears. The user is left to reconstruct settings they may not remember changing, and to wonder whether they imagined the previous version.

This is not a cosmetic inconvenience. In the UK, accessibility settings are part of how people use essential services. A banking app that forgets a larger text preference, a transport app that ignores reduced motion, or a public-service app that resets caption preferences after reinstall creates exclusion at the exact moment a person is trying to complete a task. The fault is rarely announced. It is a silent reset, and silent resets are the hardest kind to audit.

Why an update can undo a user's setup

Accessibility preferences live in several places, and that is the root of the problem. Some are operating-system settings: font size, bold text, display zoom, reduce motion, colour filters. Some are app-level settings: in-app text size, high-contrast theme, caption style, audio description preference. Some are account-level: saved preferences synced to a profile. Some are local-only: a slider value stored on the device.

An update can disturb any of these layers. A new version may change the storage key for a setting and fail to migrate the old value. A reinstall may wipe local storage and treat the user as new. A sign-out may clear preferences that were never attached to the account. A redesign may remove a setting without telling anyone. The app may also stop honouring an operating-system preference it previously respected, which looks less like a reset and more like a regression.

The user experience is the same in each case: the interface no longer fits, and no one has explained why.

The 2026 audit sample and scoring

A practical audit should cover four UK service categories: banking, retail, transport and public service. The exact apps matter less than the test matrix. For each app, record the settings a user can change, where each setting is stored, and what happens after four events: a routine update, a reinstall, a sign-out and sign-in, and migration to a new device.

Test at least five preferences where the app exposes them: larger text, high contrast, reduced motion, captions, and screen-reader-related settings such as reading order, verbosity or focus behaviour. Where the app does not expose a preference, test whether it honours the equivalent operating-system setting. Then score the outcome for each preference after each event.

A simple four-point scale is enough:

• Persists: the preference survives without user action.
• Prompted: the app asks whether to keep or restore the preference.
• Silent reset: the preference returns to default with no notice.
• Unknown: the app provides no way to tell, which should be treated as a failure for critical settings.

Silent reset deserves the lowest score. A prompt is not ideal, but it at least gives the user a chance to recover. Persistence is the standard for settings that affect readability, motion sensitivity, hearing and navigation.

What resets silently

In a small 2026 sample across the four categories, the pattern was familiar. Operating-system text size often survived because the app inherited it, but in-app text-size sliders frequently returned to default after update or reinstall. High-contrast themes were less stable than expected: some apps kept the setting, others reset it when the onboarding flow ran again. Reduced motion was the most inconsistent. Several apps honoured the system setting on first launch but ignored it after an update, particularly where animation was tied to a new splash screen or promotional panel. Caption preferences were often stored locally and lost on reinstall. Screen-reader behaviour was rarely destroyed outright, but custom reading order and verbosity settings were sometimes absent from the new version.

The common thread is not malice. It is ownership. No one on the release team owned preference persistence, so no one tested it. The setting existed in the previous version, the new version shipped, and the gap was discovered by users or support staff rather than by quality assurance.

Four failure patterns to look for

Local-only storage without migration. The app saves a preference on the device using a key that changes between versions. The old value remains but is never read. The user sees a default.

Reinstall treated as a new user. The app has no account-level preference sync, so a reinstall wipes accessibility settings along with cached data. The onboarding flow does not ask whether the user wants to restore previous choices.

Onboarding overwrites existing choices. A new version introduces a welcome sequence that applies default display settings after the user has already set preferences. The user may not notice until a task becomes difficult.

System preference not honoured after redesign. The app previously respected reduce motion or bold text. A new component library ignores the setting. Nothing resets because nothing was stored; the app simply stops listening.

A repeatable checklist for product teams

Preference persistence should be a release criterion, not a post-launch fix. Before shipping an update, product teams should be able to answer the following questions:

1. Have we listed every accessibility preference the app exposes, and every operating-system preference it claims to honour?
2. For each preference, do we know whether it is stored locally, at account level, or not at all?
3. Have we tested the update path from the previous public version, not only a clean install?
4. Have we tested reinstall, sign-out and sign-in, and migration to a new device?
5. Does the app prompt the user before resetting a preference, or does it reset silently?
6. Have we checked that new onboarding flows do not overwrite existing settings?
7. Have we included users who rely on these settings in beta testing, not only internal staff?
8. Have we added support tags for settings-related complaints so that silent resets surface quickly?
9. Have we documented the storage and migration behaviour so that the next release does not repeat the fault?

Making update-day continuity visible

An update should not be a neutral event for accessibility. It is a change to the user's environment, and it needs to be tested as such. The audit output should be a simple matrix: preferences down the side, events across the top, scores in the cells. That matrix gives product teams something they can act on and gives accessibility leads something they can evidence.

The aim is not to shame individual apps. It is to make preference persistence ordinary. A user who has set larger text, high contrast or reduced motion has already done the work. The app's job is to remember it, or at the very least to ask before forgetting.