/* Accessibility widget themes (accessibility-ua.md §4). Loaded after
   base.css. */

/* High contrast: redefines the colour TOKENS, not just body/a — every
   component on the page already paints itself from these custom
   properties, so remapping them here reaches everything at once
   (fix round 1, item 1: the old body-only rule left e.g. muted
   neutral-500 text and the primary-500 accent unchanged everywhere
   else on the page).

   Ratios actually measured against #FFFFFF (WCAG relative-luminance
   formula, not eyeballed):
     neutral-950 #070A0D → 19.84:1
     primary-800 #115E58 → 7.59:1  (accessibility-ua.md §4, amended: the
                                     accent was primary-700 5.49:1, which
                                     clears normal-text AA but not the
                                     panel's own ≥7:1 bar)
   Every token below maps to one of those two, so any pairing that was
   text-on-white before is still text-on-white now, just with the
   darker member of the pair — this also covers the reverse case (a
   token used as a dark background, e.g. a dark surface elsewhere on
   the site): mapping neutral-700/800/900 to neutral-950 only makes a
   dark surface darker, and its light text (neutral-50 → white) keeps
   full contrast against it either way. */
html[data-contrast="high"] {
	--color-neutral-50: var(--color-base-white);
	--color-neutral-100: var(--color-base-white);
	--color-neutral-400: var(--color-neutral-950);
	--color-neutral-500: var(--color-neutral-950);
	--color-neutral-600: var(--color-neutral-950);
	--color-neutral-700: var(--color-neutral-950);
	--color-neutral-800: var(--color-neutral-950);
	--color-neutral-900: var(--color-neutral-950);
	--color-primary-500: var(--color-primary-800);
	--color-primary-600: var(--color-primary-800);
	--color-primary-700: var(--color-primary-800);
	background: var(--color-base-white);
	color: var(--color-neutral-950);
}

html[data-contrast="high"] body {
	background: var(--color-base-white);
	color: var(--color-neutral-950);
}

html[data-contrast="high"] a {
	color: var(--color-primary-800);
	text-decoration: underline;
}

html[data-contrast="high"] .c-ticket,
html[data-contrast="high"] .a11y-panel__switch,
html[data-contrast="high"] [class$="__badge"] {
	box-shadow: inset 0 0 0 2px currentcolor;
}

html[data-contrast="high"] img {
	filter: none;
}

/* Footer-Logo__3673-14583.svg (site-footer.css's decorative wordmark, on
   the light --color-neutral-100 footer background) hardcodes fill="#12AD99"
   (primary-500, 2.81:1 on white) on 14 of its paths — a literal hex, not
   `var(--color-primary-500)` like the theme's other icons, so the token
   remap above never reaches it. A CSS `fill` declaration on the <path>
   overrides its own presentation attribute regardless of specificity, same
   as the neutral-800 remap already does for its other 2 paths (unaffected:
   already dark-on-light, no change needed — round 3, item 5). */
html[data-contrast="high"] .site-footer__wordmark svg path[fill="#12AD99"] {
	fill: var(--color-primary-800);
}

/* .site-footer__newsletter and .subscribe (site-footer.css / subscribe.css)
   form one dark band — background: var(--color-neutral-800), remapped to
   neutral-950 above like every other neutral-700/800/900 use, which is
   correct for those files' OTHER (light-on-light) uses of neutral-800 as
   text. Round 1 fixed only the title this way; round 2 (controller ruling,
   critical finding 1) found the same problem on every other token-driven
   colour in the band:
     .subscribe__disclaimer: color: var(--color-neutral-400) → remapped to
       neutral-950 → 1:1 against the neutral-950 band (invisible).
     .subscribe__submit svg (arrow__3058-2161.svg):
       fill: var(--color-primary-500) → remapped to primary-800 → 2.61:1
       against the band, under 1.4.11's 3:1.
   No single accent/neutral shade clears 7:1 (text) or 3:1 (icons) against
   BOTH a light and a dark surface (checked already for primary-500: 7.05:1
   on black, 2.81:1 on white — the same problem mirrored), so scope the
   whole band to the OTHER strategy named in the ruling — dark band, white
   text/icons — via the underlying tokens, not a title-only special case.
   Elements in the band that were already hardcoded white
   (`.subscribe__input`, `.subscribe__submit`, `.subscribe__done-title`:
   rgb(255 255 255), not a token, per site-footer.css/subscribe.css's own
   comments — no token matches Figma's literal #FFFFFF here) are already
   fine and untouched by this. */
html[data-contrast="high"] .site-footer__newsletter,
html[data-contrast="high"] .subscribe {
	--color-neutral-400: var(--color-base-white);
	--color-primary-500: var(--color-base-white);
	--color-primary-600: var(--color-base-white);
	--color-primary-700: var(--color-base-white);
	--color-primary-800: var(--color-base-white);
}

/* Reduced motion: same rules as
   `@media (prefers-reduced-motion: reduce)` in base.css, mirrored
   onto the widget's own switch so it works without relying on the OS
   setting. `!important` is the documented exception for reduced
   motion (global-constraints.md). */
html[data-motion="reduced"] *,
html[data-motion="reduced"] *::before,
html[data-motion="reduced"] *::after {
	/* stylelint-disable-next-line declaration-no-important -- reduced motion */
	animation-duration: 0.01ms !important;
	/* stylelint-disable-next-line declaration-no-important -- reduced motion */
	transition-duration: 0.01ms !important;
}

/* Dyslexia font: swap the body typeface, widen letter/word spacing
   (+20% line-height, +tracking) globally. --a11y-lh-scale and
   --a11y-ls-add (fix round 1, item 9) are read by every line-height
   and letter-spacing token in tokens.css, not just a few hand-picked
   selectors — so a heading, a button label, and a paragraph all get
   the same treatment, not only <body>/<p>/<li>. word-spacing has no
   equivalent token in this system, so it stays a body-level rule. */
html[data-font="dyslexia"] {
	--font-body: "Podil Dyslexia", sans-serif;
	--a11y-lh-scale: 1.2;
	--a11y-ls-add: 0.05em;
}

/* Round 3 (controller ruling R20, item 1): a plain inherited
   `letter-spacing: 0.05em` on `html` (round 2's fix) computes ONCE there,
   at the html element's own font-size — the inherited value descendants
   receive is that fixed px result, not `0.05em` re-resolved against each
   element's own font-size. An h1 at 32–40px then only got the ~16px-em
   equivalent (0.020–0.025em), not 0.05em. `:where(html[...] *)` applies
   the declaration directly to every element instead of relying on
   inheritance, so each one resolves `0.05em` against its own font-size —
   and `:where()` carries zero specificity, so a tokenised component's own
   `letter-spacing: var(--ls-*)` rule (which already includes --a11y-ls-add,
   fix round 1 item 9) still wins the cascade over this wildcard. */
:where(html[data-font="dyslexia"] *) {
	letter-spacing: 0.05em;
}

html[data-font="dyslexia"] body {
	word-spacing: 0.1em;
}