EN 301 549 User Preferences – The New Rule That Isn’t in WCAG

In v4.1.1 of EN 301 549, “user preferences” stopped being a software-only rule. Until now, it lived in a single clause, 11.7, which applied to non-web software. The 2026 revision splits it into three parallel clauses and, for the first time, writes explicit versions for web pages (9.7) and non-web documents (10.7).

That is the change that matters if you work on websites. There is now a named clause in the European accessibility standard about not fighting the settings your users already chose.

One point is easy to get tangled, so let’s put it up front. This change is real, but it is not one of the six new WCAG 2.2 criteria that v4.1.1 also pulls in. It is a separate, structural change.

And because v4.1.1 is published but not yet cited in the Official Journal, 9.7 and 10.7 are forward-prep, not a today-obligation. The criteria that already push you in the same direction (Resize Text, Reflow, Text Spacing) have been mandatory the whole time.

This article covers what the clause actually says, the CSS that satisfies it, and what is due now versus later.

What “user preferences” means in EN 301 549

A user preference is a setting the person chose at the operating system or browser level to make their device usable: high contrast mode, a larger text size, a bigger pointer, a colour filter, reduced motion. The clause is about respecting those choices instead of steamrolling them with your own styling.

The standard names the settings it has in mind. From NOTE 5 of clause 9.7: “Features that might be documented as platform accessibility features include, but are not limited to colour filters, contrast, text size, pointer size, and text cursor.” That is the concrete list to keep in your head: colour filters, contrast, text size, pointer size, text cursor.

The principle behind all three clauses is the same, and it is narrower than people assume. You are not being asked to build anything. You are being asked not to break what the user already turned on, unless breaking it is genuinely essential to the content or function.

The three clauses: 9.7, 10.7, 11.7

The requirement now exists in three places, one per type of ICT. The wording is close, but the “platform” each one refers to differs.

9.7 User preferences for web pages (new in v4.1.1):

Where ICT is, or includes, a web page, the web page shall not block the user agent’s mode(s) of operation that present the web page according to user preference settings, or explicitly override user preference settings for documented platform accessibility features in these modes of operation, unless this is essential to the information or function of the web page.

For web pages, NOTE 3 tells you the platform is the user agent, meaning the browser. Your job is not to block or override what the browser is doing on the user’s behalf.

10.7 User preferences for non-web documents (new in v4.1.1):

Where ICT is, or includes, a non-web document, the non-web document shall not block the user agents mode(s) of operation that present the document according to user preference settings, or explicitly override user preference settings for documented platform accessibility features in these modes of operation, unless this is essential to the information or function of the non-web document.

Same rule, applied to documents like PDFs and office files rendered by their own viewer.

11.7 User preferences (the pre-existing software clause, reworded):

Where ICT is, or includes, non-web software that provides a user interface, and is not designed to be isolated from its platform, that user interface shall follow the values of the user preference settings for documented platform accessibility features unless it is essential to the function of the non-web software to not follow a user preference setting.

For non-web software, NOTE 3 says the platform is usually the operating system. This is the clause that already existed in v3.2.1, now aligned with the other two.

Note the word: it is shall, not “should.” This is a normative, mandatory requirement in all three clauses. Some secondary write-ups soften it to “should,” which is imprecise.

Is this one of the new WCAG 2.2 criteria? No

This is the single most common mix-up, so it is worth being blunt. v4.1.1 does two separate things.

It absorbs WCAG 2.2, which adds six new success criteria (Focus Not Obscured, Dragging Movements, Target Size Minimum, Consistent Help, Redundant Entry, Accessible Authentication). And, independently, it restructures user preferences into 9.7, 10.7, and 11.7.

User preferences is not on that list of six. It is a structural change to the standard’s own clauses, not a WCAG success criterion. If you are briefing a team, keep the two threads separate: “here are the six new WCAG 2.2 checks” and “separately, user preferences now has a web and document version.”

For the full EN 301 549 v4.1.1 change list, including the six criteria and the removal of Parsing, see the update rundown.

What’s due now vs. what’s coming

This is the honest timing picture, and it is the part readers most often need spelled out.

v4.1.1 was published by ETSI in September 2026, but it has not yet been cited in the Official Journal of the EU. Until that citation happens, the earlier version, v3.2.1 (which maps to WCAG 2.1 AA), remains the operative reference for the presumption of conformity under the European Accessibility Act.

So clauses 9.7 and 10.7 are published-but-not-yet-binding: real, worth preparing for, but not something an auditor holds you to today. For how EN 301 549 relates to the EAA and the legal timeline, see the full explainer.

Here is the useful part. You do not have to wait to start. Three WCAG success criteria that already apply under v3.2.1 push in exactly the same direction as 9.7:

• 1.4.4 Resize Text (text must scale to 200% without loss)
• 1.4.10 Reflow (content must reflow to a 320 CSS pixel viewport without two-dimensional scrolling)
• 1.4.12 Text Spacing (content must survive user-applied spacing overrides)

These are due now. If you build so that user zoom, text scaling, and spacing overrides survive, you are already most of the way to the spirit of 9.7, and you are doing work that is required today regardless of when v4.1.1 gets cited.

A key nuance: you don’t have to build dark mode

Read 9.7 carefully, and one thing stands out. It never asks you to add a feature. There is no requirement to ship a dark mode, a high-contrast toggle, or a theme switcher.

The obligation is the opposite of building. It is restraint. Do not block the browser’s preference modes, and do not explicitly override the user’s chosen platform settings, unless doing so is essential to the content.

A page with no dark mode at all can satisfy 9.7. A page with a beautiful custom design that hard-codes colours the user’s high-contrast setting is trying to replace can fail it.

So the mental model is not “what accessibility features should I add.” It is “where am I overriding a choice the user already made, and is that override actually essential.” Usually it is not.

Translating the clause into CSS

The clause is written in “user agent” and “platform settings” language, not CSS. Except for one place. NOTE 4 of clause 9.7 names an actual CSS property:

This does not preclude the web page from specifying other values, but it does limit the use of specifications that explicitly override user settings (e.g. ‘forced-color-adjust‘ property in CSS) to cases where this is essential.

That is the standard itself telling you which lever to watch. forced-color-adjust: none is the exact kind of “explicit override” 9.7 restricts. Here are the CSS features that map to the named platform settings.

#1. Forced colors (high contrast)

When a user turns on a forced-colors mode (for example, Windows High Contrast), the browser replaces your palette with a small system-defined set. That is the browser mode 9.7 says not to block.

/* Don't do this: it rips the user out of their chosen palette. */

.card {

forced-color-adjust: none;

background: #1a1a2e;

color: #e0e0e0;

}

/* Do this: let forced-colors take over, and use system color

keywords plus a visible border so structure survives. */

@media (forced-colors: active) {

.card {

background: Canvas;

color: CanvasText;

border: 1px solid CanvasText;

}

}

Reach for forced-color-adjust: none only in the narrow “essential” case the note describes, for example, a colour swatch or a chart where the specific colour is the information. Everywhere else, let the mode do its job.

#2. Reduced motion

If a user set “reduce motion” at the OS level, honoring it is how you avoid overriding a documented preference. The common failure pattern is a parallax scroll, an autoplaying carousel, or a large transition that runs regardless of the setting.

/* Do this: gate non-essential motion on the user's preference. */

@media (prefers-reduced-motion: reduce) {

*,

*::before,

*::after {

animation-duration: 0.001ms !important;

animation-iteration-count: 1 !important;

transition-duration: 0.001ms !important;

scroll-behavior: auto !important;

}

}

A more targeted version is better than the blanket reset above where you want to keep small, essential feedback animations. The point is that motion is opt-in for people who asked for less of it.

#3. Colour scheme (dark mode)

This is where the “you don’t have to build dark mode” nuance turns into code. You are not obligated to provide a dark theme. But if you do respond to the preference, respond to what the user set, do not force one scheme and lock it.

/* Declare which schemes your page actually supports. */

:root {

color-scheme: light dark;

}

/* Optional: your own dark palette, driven by the user's setting. */

@media (prefers-color-scheme: dark) {

:root {

--bg: #12131a;

--text: #e8e8ea;

}

}

Declaring color-scheme lets form controls, scrollbars, and default backgrounds follow the user’s choice even before you style a single custom token. That alone respects the preference without a full theme.

#4. Contrast preference

prefers-contrast exposes whether the user asked for more contrast. Treat it as a signal to strengthen borders and text separation, not to hard-code a palette on top of theirs.

@media (prefers-contrast: more) {

.btn {

border: 2px solid currentColor;

}

a {

text-decoration: underline;

}

}

[PLACEHOLDER: an OS/browser accessibility settings panel (reduce motion, increase contrast, larger text, colour filter) with arrows to the matching CSS media features](alt: Operating system accessibility settings mapped to their corresponding CSS media features such as prefers-reduced-motion and prefers-contrast)

Mapping table: setting, CSS lever, related WCAG SC, how to test

Here is the mapping in one place. It ties each named platform setting to the CSS feature that respects it, the already-required WCAG criterion in the same area, and a manual test you can actually run.

Platform setting (from the standard)	CSS media feature / property	Related already-required WCAG SC	How to test manually
Contrast / high contrast	@media (forced-colors: active); avoid forced-color-adjust: none	(Forced-colors respect is 9.7 itself; no direct 2.1 SC)	Turn on Windows Contrast Themes or use Edge/Chrome “Forced Colors”. Check nothing disappears and every control keeps a visible border.
Contrast (increase)	@media (prefers-contrast: more)	1.4.11 Non-text Contrast	Set “Increase contrast” (macOS) or the OS equivalent, confirm borders and focus rings strengthen rather than vanish.
Text size	rem/em sizing, fluid layout	1.4.4 Resize Text (200%)	Zoom the browser to 200%. No clipped text, no horizontal scroll for reading.
Text size + spacing	avoid fixed heights on text containers	1.4.10 Reflow (320px), 1.4.12 Text Spacing	Narrow to 320 CSS px and apply a text-spacing bookmarklet. Content reflows and nothing is cut off.
Colour filters/colour scheme	color-scheme, @media (prefers-color-scheme: dark)	(Supports 1.4.3/1.4.11 in both schemes)	Toggle OS dark mode. Confirm the page follows it or at least stays legible, and controls are not stuck in one scheme.
Pointer size/text cursor	avoid overriding native cursor visuals unnecessarily	2.4.7 Focus Visible (for keyboard)	Enlarge the pointer and text cursor in OS settings. Confirm custom cursor styling does not hide the enlarged pointer.
Motion preference	@media (prefers-reduced-motion: reduce)	2.3.3 Animation from Interactions (AAA)	Enable “Reduce motion” in the OS. Confirm parallax, autoplay and large transitions stop or shrink.

Two things to notice. First, several rows have a WCAG criterion that is already mandatory, which is your “do it now” work. Second, forced-colors respect does not have a neat 2.1 equivalent, which is precisely why 9.7 fills a real gap.

How user preferences is tested

Testing user-preferences respect is mostly manual, and honestly the standard does not hand you a tidy pass/fail script. The practical method is to walk the named settings one at a time:

1. Turn on a forced-colors / high-contrast mode and load key pages. Look for content that vanishes, controls that lose their outline, and any element still forcing its own colours.
2. Enable reduce-motion and confirm large or looping animation stops.
3. Toggle OS dark mode and confirm the page follows the preference or stays fully legible.
4. Zoom to 200% and reflow to 320 CSS px, checking for clipping and horizontal scroll (this doubles as your 1.4.4 and 1.4.10 check).
5. Apply a text-spacing override and confirm nothing is cut off (1.4.12).

Write down which pages you checked and the settings you used. That record is your evidence of conformity effort, which matters more than any single automated score here.

FAQs