EN 301 549 11.7 -- User Preferences

For reference only -- not part of a11ybot's automated checks.

What It Is

EN 301 549 v3.2.1 clause 11.7 User preferences says that where software is not isolated from its platform and provides a user interface, that interface shall follow the platform user-preference values for units of measurement, colour, contrast, font type, font size, and focus cursor, except where the user has explicitly overridden them inside the application[1]. The clause is an integration obligation: the application reads settings the user has already tuned at the OS level and renders against them, rather than shipping a hardcoded theme that ignores them.

Two scoping details matter. First, software "isolated from its platform" (sandboxed runtimes with no access to platform APIs) is out of scope -- the clause only binds software that can actually read the preferences. Second, for web content the user agent is treated as the platform, so a browser's exposed preferences (via CSS media features) are the surface the web application must honour.

Why It Matters

A user who has set Windows High Contrast to a custom colour pair, bumped macOS text size up two notches, or picked a dyslexia-friendly system font has already done the accessibility work once. An application that paints its own brand palette over the platform colours, ships its own font stack in place of the system font, or draws its own focus ring instead of the platform focus cursor forces the user to re-tune per application -- or, more commonly, locks them out. Clause 11.7 makes that override the exception (opt-in by the user inside the app) rather than the default.

How It Relates to WCAG

WCAG 2.2 defines outcome-level requirements -- 1.4.3 Contrast, 1.4.4 Resize Text, 1.4.12 Text Spacing -- that a page can meet with its own stylesheet without ever consulting the platform. Clause 11.7 is narrower and more specific: it names six platform settings (units, colour, contrast, font type, font size, focus cursor) and requires the software to follow them. An application can pass WCAG 1.4.3 on its own palette and still fail 11.7 by ignoring the user's Windows High Contrast theme. Note that reduced motion, colour inversion, and animation preferences are not named in 11.7's enumerated list -- treat them as good practice and as obligations under WCAG 2.3.3 and 2.2.2, not as 11.7 items.

The Mechanism Failure

Typical 11.7 failures look mechanistic:

  • A Windows desktop app paints every surface from a hardcoded QSS/WPF theme and never queries SystemParametersInfo with SPI_GETHIGHCONTRAST, so High Contrast mode has no effect inside the app.
  • A web application defines colours with fixed hex values and never sets forced-color-adjust: auto or uses system-color keywords, so Windows High Contrast (surfaced to the browser as forced-colors: active) cannot repaint it.
  • An iOS app draws text with a fixed UIFont.systemFont(ofSize: 15) instead of a Dynamic Type text style, so the user's accessibility text size in Settings -> Display & Text Size never propagates.
  • A cross-platform Electron app ships its own font stack and focus ring, ignoring both the platform font and the platform focus cursor.

The Fix

Read the platform preferences through the platform API and render against them by default. Override only when the user asks inside the app.

  • Web: Use CSS system colours (Canvas, CanvasText, LinkText, ButtonFace) and the forced-colors media feature for High Contrast integration. Use prefers-color-scheme and prefers-contrast for colour and contrast preferences. Inherit font family from font-family: system-ui and size type in rem so the browser's base font size controls the render[1].
  • Windows: Query SystemParametersInfo(SPI_GETHIGHCONTRAST) for High Contrast state, use GetThemeSysColor / GetSysColor for colour, and resolve fonts through SystemFonts rather than hardcoded family names.
  • macOS: Use NSColor semantic colours (labelColor, controlAccentColor), NSFont.systemFont(ofSize: NSFont.systemFontSize), and observe NSWorkspace.shared.accessibilityDisplayShouldIncreaseContrast.
  • iOS: Use Dynamic Type text styles (UIFont.preferredFont(forTextStyle:)), semantic UIColors (label, systemBackground), and traits such as accessibilityContrast.
  • Android: Use sp for text sizing so it follows the system font scale, read Settings.System.FONT_SCALE, and resolve colours through theme attributes (?attr/colorOnSurface) rather than literals.

Related Clauses

Sources

  • ETSI EN 301 549 v3.2.1, clause 11.7 User preferences[1]