/*
 * First-party accessibility overrides.
 *
 * Loaded last, after the vendored Crafto theme (style.css, responsive.min.css)
 * and after pcadmin's own accessibility panel CSS, so these rules win without
 * needing !important except where the theme itself used it.
 *
 * Rule IDs refer to the Estonian accessibility checklist (accessibility.twn.ee).
 */

/* ------------------------------------------------------------------ *
 * 3.12 — Skip link
 * Off-screen until focused, then pinned to the top-left and clearly visible.
 * ------------------------------------------------------------------ */

.pc-skip-link {
    position: absolute;
    top: -100px;
    left: 1rem;
    z-index: 10000;
    padding: 0.75rem 1.25rem;
    background: #0b1c3f;
    color: #fff;
    font-weight: 600;
    text-decoration: underline;
    border-radius: 0 0 0.375rem 0.375rem;
    transition: top 0.15s ease-in-out;
}

.pc-skip-link:focus,
.pc-skip-link:focus-visible {
    top: 0;
    color: #fff;
    /* !important because the global :focus-visible rule below also uses it;
       the navy ring would sit on the skip link's own navy background. */
    outline: 3px solid #ffd400 !important;
    outline-offset: 2px !important;
}

/* <main tabindex="-1"> is focused by the skip link but is not an interactive
   control, so it must not draw a focus ring of its own. */
main:focus,
main[tabindex="-1"]:focus-visible {
    outline: none;
}

/* ------------------------------------------------------------------ *
 * 8.2, 7.3, 14.7 — Visible focus indicator
 *
 * The theme ships 44 `outline: none` declarations across style.css,
 * vendors.min.css and responsive.min.css. This restores a visible indicator
 * for keyboard users only, so mouse users see no change.
 * ------------------------------------------------------------------ */

:focus-visible {
    outline: 3px solid #0b3d91 !important;
    outline-offset: 2px !important;
    border-radius: 2px;
}

/* On dark backgrounds the navy ring disappears; use the amber instead. */
footer :focus-visible,
.bg-dark-gray :focus-visible,
.bg-base-color :focus-visible,
.accessibility-controls :focus-visible,
[class*="bg-gradient"] :focus-visible {
    outline-color: #ffd400 !important;
}

/* ------------------------------------------------------------------ *
 * 1.7 — Visually hidden, but available to screen readers
 * ------------------------------------------------------------------ */

.visually-hidden {
    position: absolute !important;
    width: 1px !important;
    height: 1px !important;
    padding: 0 !important;
    margin: -0.0625rem !important;
    overflow: hidden !important;
    clip: rect(0, 0, 0, 0) !important;
    clip-path: inset(50%) !important;
    white-space: nowrap !important;
    border: 0 !important;
}

/* ------------------------------------------------------------------ *
 * 7.8, 14.2 — Pointer target size, at least 24x24 CSS px
 * ------------------------------------------------------------------ */

.swiper-pagination-bullet {
    /* 44px for checklist 14.3, up from the 24 that 7.8 / 14.2 asked for. The
       dot stays 8px: the extra area is transparent padding, so the dot itself
       looks exactly as it did. What does change is the space BETWEEN dots, and
       that is the point -- two 24px bullets 8px apart cannot both be pressed
       cleanly, which is the `piisavalt suurte vahedega` half of 14.3. An
       overlay would not have worked here: adjacent 44px overlays would sit on
       top of each other and each bullet would hand the press to its neighbour.
       These need real room, not a bigger claim on the same room. */
    width: 44px;
    height: 44px;
    background: transparent;
    opacity: 1;
    position: relative;
}

.swiper-pagination-bullet::after {
    content: "";
    position: absolute;
    top: 50%;
    left: 50%;
    width: 8px;
    height: 8px;
    transform: translate(-50%, -50%);
    border-radius: 50%;
    background: currentColor;
    opacity: 0.4;
}

.swiper-pagination-bullet-active::after {
    opacity: 1;
}

.elements-social ul li a,
.pc-target-24 {
    min-width: 24px;
    min-height: 24px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

/* ------------------------------------------------------------------ *
 * 4.5 — 404 page heading hierarchy
 *
 * "Ooops!" is not a heading and the subtitle moved from h4 to h2. Both keep
 * their previous rendered size, in rem against the root -- which now follows
 * the reader's browser font-size setting (1.32). The narrow-breakpoint step
 * down these used to get from the theme's shrinking root is restated in the
 * generated css/breakpoint-scale.css.
 * ------------------------------------------------------------------ */

.pc-eyebrow {
    font-size: 1.75rem;   /* was h6: 24.5px */
    line-height: 1.114;
}

.pc-404-subtitle {
    font-size: 2.375rem;  /* was h4: 33.25px */
    line-height: 1.137;
}

/* ------------------------------------------------------------------ *
 * 1.25, 1.24 — Reduced motion
 *
 * Honours the operating-system preference. The JavaScript-driven carousels
 * are stopped separately in js/accessibility.js; a media query alone cannot
 * stop a slider library's autoplay timer.
 * ------------------------------------------------------------------ */

@media (prefers-reduced-motion: reduce) {
    *,
    *::before,
    *::after {
        animation-duration: 0.01ms !important;
        animation-iteration-count: 1 !important;
        transition-duration: 0.01ms !important;
        scroll-behavior: auto !important;
    }

    /* The entrance animations are NOT stopped here -- they are driven by
       anime.js writing inline styles, which no CSS duration can shorten, so
       js/accessibility.js removes the `data-anime` attribute outright before
       js/main.js binds to it.

       This rule only covers the gap before that script runs: the scripts sit at
       the end of <body>, and `[data-anime] { opacity: 0 }` in css/style.css
       would otherwise leave the blocks blank until then.

       Do not treat this rule as the fix. On its own it un-hides the wrapper
       while anime.js still animates the wrapper's *children* -- which this
       selector does not match -- so the text appears, then visibly replays its
       entrance on scroll. That was the bug. */
    [data-anime] {
        opacity: 1 !important;
        transform: none !important;
    }

    /* Parallax backgrounds are repositioned on scroll by skrollr. */
    [data-parallax-background-ratio] {
        background-attachment: scroll !important;
        background-position: center center !important;
    }
}

/* ------------------------------------------------------------------ *
 * 14.5 — Controls that were <a role="button"> or <i role="button">
 *
 * These are now real <button> elements. The rules below strip the native
 * button chrome so the rendered header is unchanged; they exist only because
 * of the semantic fix.
 * ------------------------------------------------------------------ */

.pc-nav-button {
    background: none;
    border: 0;
    font: inherit;
    color: inherit;
    text-align: inherit;
    cursor: pointer;
}

.pc-nav-caret {
    background: none;
    border: 0;
    line-height: 1;
    cursor: pointer;
    /* 7.8 / 14.2 / 14.3 — the caret is its own target and must be big enough.
       The 1.25rem that used to be margin is padding now, so the 20px of space
       that already sat to the caret's right becomes part of the target instead
       of dead ground beside it. Under border-box that leaves a 24px content
       box, so the glyph stays centred exactly where it was and the navbar is
       laid out to the same width -- 24 + 20 margin before, 44 including the
       padding after. An overlay was the alternative and is wrong here: centred
       on a 24px caret it would reach 10px into the menu link to its left, and
       for the items that ARE links (Meist has both a page and children) a
       press near the end of the word would open the dropdown instead of
       following the link.

       One cosmetic consequence, stated rather than hidden: because the padding
       is all on one side, the :focus-visible ring is 44px wide with the chevron
       10px left of its centre. That is the ring telling the truth -- the whole
       44px is pressable -- and splitting the padding evenly would centre the
       ring only by moving the caret's box 10px LEFT, back into the menu link,
       which is the behaviour this rule exists to avoid. Verified 3px solid and
       visible, so checklist 14.7 is unaffected. */
    padding: 0 1.25rem 0 0;     /* was margin-right: 1.25rem, from .me-20px */
    margin-right: 0;
    min-width: 44px;
    min-height: 44px;
    /* The next menu item's <a> overlaps the last 2px of that padding and, being
       later in the document, takes the press there. Measured, not assumed: the
       caret read 40x44 with its right edge answered by a.nav-link. Raising the
       caret is the right way round -- it is the smaller control and the one
       with a size requirement to meet, while the link it borrows 2px from is
       checklist 7.8's business at 24px and has 60+ to spare. */
    position: relative;
    z-index: 1;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

/* The dropdown caret sits beside the parent link inside a positioned <li>;
   the theme aligned the <i> by baseline, so match that. */
.navbar-nav .nav-item.dropdown > .pc-nav-caret {
    vertical-align: middle;
}

/* ------------------------------------------------------------------ *
 * 13.3 — Live regions must stay in the DOM to be announced
 *
 * The newsletter result used style="display:none" and was revealed at the
 * same moment its text was written, which announces nothing. It is now always
 * present and empty; this keeps the empty state from adding vertical space.
 * ------------------------------------------------------------------ */

#pc-newsletter-message:empty {
    margin-top: 0 !important;
}

/* ------------------------------------------------------------------ *
 * 4.4, 4.5 — Semantic heading level, visual heading size
 *
 * Section templates now take their heading level from the page (see
 * includes/heading.php), so the rendered size must come from a class rather
 * than the tag. style.css already pairs .h1/.h2/.h3 with their tags; .h4-.h6
 * exist only in Bootstrap at different values, so they are restated here to
 * match the theme.
 * ------------------------------------------------------------------ */

.h4 { font-size: 2.375rem; line-height: 1.13684211; }
.h5 { font-size: 2rem;     line-height: 1.1; }
.h6 { font-size: 1.75rem;  line-height: 1.11428571; }

/* ------------------------------------------------------------------ *
 * 14.5 — Slider and accordion controls that were <div> or <a href="#">
 *
 * Now real <button> elements. These rules remove the native button chrome so
 * the theme's own .swiper-button-* and .accordion-header styling still lands.
 * ------------------------------------------------------------------ */

button.swiper-button-prev,
button.swiper-button-next,
button.swiper-button-previous-nav,
button.swiper-button-next-nav,
.pc-accordion-toggle {
    background: none;
    border: 0;
    padding: 0;
    font: inherit;
    color: inherit;
    text-align: inherit;
    cursor: pointer;
}

/* The accordion header link filled its row; the button must too. */
.pc-accordion-toggle {
    display: block;
    width: 100%;
}

/* A <button> may contain phrasing content only, so the label wrapper inside it
 * is a <span> (checklist 1.27). It still lays out as the block the theme's
 * .accordion-title rules were written against. */
.pc-accordion-toggle .accordion-title {
    display: block;
}

/* mission-slider's arrows carry a visible border from the theme. */
button.slider-navigation-style-04 {
    border-style: solid;
}

/* ------------------------------------------------------------------ *
 * 1.24, 9.3 — Carousel pause control
 *
 * Injected by js/accessibility.js into every carousel that autoplays.
 * ------------------------------------------------------------------ */

.pc-slider-pause {
    position: absolute;
    right: 8px;
    bottom: 8px;
    z-index: 20;
    width: 32px;
    height: 32px;
    padding: 0;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    border: 1px solid rgba(0, 0, 0, 0.25);
    border-radius: 50%;
    background: rgba(255, 255, 255, 0.9);
    cursor: pointer;
}

/* Two bars: the pause glyph. */
.pc-slider-pause-icon {
    display: block;
    width: 10px;
    height: 12px;
    border-left: 3px solid #1a1a1a;
    border-right: 3px solid #1a1a1a;
}

/* One triangle: the play glyph, shown once the carousel is paused. */
.pc-slider-pause.is-paused .pc-slider-pause-icon {
    width: 0;
    height: 0;
    border-left: 10px solid #1a1a1a;
    border-right: 0;
    border-top: 6px solid transparent;
    border-bottom: 6px solid transparent;
    margin-left: 0.1875rem;
}

/* 4.2 — the pull quote moved from <h3> to <blockquote><p>; strip the
   browser's default blockquote indent so the layout is unchanged. */
.pc-quote {
    margin: 0;
    padding: 0;
}

/* ------------------------------------------------------------------ *
 * 8.4 — Text on the dark pricing card
 *
 * The body grey was darkened to clear 4.5:1 on white and #f1f1f1. On the dark
 * "popular" card it runs the other way and lands at 3.51:1, so that one case
 * takes a lighter grey. Measured 4.54:1 against #15161d.
 * ------------------------------------------------------------------ */

.bg-dark-gray .pc-pricing-footnote {
    color: #7f7f86;
}

/* ------------------------------------------------------------------ *
 * 1.28 / 5.1 / 14.2 — Header on very narrow screens
 *
 * The accessibility button now sits in the header on small screens too, so the
 * logo, that button and the burger have to share one row. Below about 342px
 * they no longer fit (305px available vs 327px needed) and the burger wrapped
 * underneath the logo. Trim the grid gutters and cap the logo so all three sit
 * on one row again.
 *
 * The burger is also given a real 24x24 target here; the theme ships it at
 * 22x14, which is below the minimum for a pointer target.
 * ------------------------------------------------------------------ */

@media (max-width: 25em) {
    .navbar > .container-fluid > [class*="col-"] {
        padding-left: 0.625rem;
        padding-right: 0.625rem;
    }

    .navbar-brand img {
        max-width: 160px;
    }
}

/* The theme fixes the burger at 22x14 and positions its four lines absolutely
   at top 0/6/6/12, so growing the box pushes the glyph off centre rather than
   enlarging it. Leave the box alone and put the target on a centred
   pseudo-element instead; the lines, and the X animation that repositions them
   when the menu opens, are untouched. 44px for checklist 14.3, up from the 24
   of 7.8 / 14.2. */
.navbar-toggler::after {
    content: "";
    position: absolute;
    top: 50%;
    left: 50%;
    width: 44px;
    height: 44px;
    transform: translate(-50%, -50%);
}

/* ------------------------------------------------------------------ *
 * 1.28 / 5.1 — The accessibility panel on small screens
 *
 * pcadmin hides the panel below 992px with `display: none !important`, which
 * beats the inline style its own JavaScript sets when the button is pressed.
 * With the button now visible on mobile, that made it a control that does
 * nothing. Scoped to the open state (the same body class the component's JS
 * toggles) so the closed panel stays hidden exactly as before.
 * ------------------------------------------------------------------ */

@media (max-width: 61.99875em) {
    body.accessibility-controls-visible .accessibility-controls {
        display: block !important;
        visibility: visible !important;
        opacity: 1 !important;
        /* A full-height bar on a short phone screen has to scroll. */
        max-height: 85vh;
        overflow-y: auto;
        /* The panel's Bootstrap rows carry negative margins that overshoot the
           container by 3px; harmless until the panel becomes a scroll box. */
        overflow-x: hidden;
    }
}

/* 14.2 / 10.4 — the panel's close button.
 *
 * Its icon is `uil uil-times` (Unicons), but that font is not among the ones
 * this site loads, so the glyph resolves to nothing: the button measured 6px
 * wide with an empty ::before and was invisible. Pre-existing on desktop, and
 * more of a problem now the panel opens on mobile too. Draw the cross here and
 * give the button a real 24x24 target. */
#accessibility-close {
    min-width: 44px;
    min-height: 44px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    font-size: 1.5rem;
    line-height: 1;
}

#accessibility-close .uil-times::before {
    content: "\00d7";
    font-family: inherit;
    font-style: normal;
    font-weight: 400;
}

/* ------------------------------------------------------------------ *
 * 3.5 (WCAG 2.4.8) — the breadcrumb trail in the page header
 *
 * The trail sits inside the page-hero banner, whose backdrop is an
 * author-supplied photograph under a 50%-opaque black overlay. That overlay
 * is enough for the <h1>: large text needs 3:1, and the worst case a
 * photograph can produce -- pure white under 50% black, #808080 -- gives white
 * text 3.95:1. The crumbs are small text and need the full 4.5:1, which the
 * same backdrop does not reach. Since the image is chosen by an editor and can
 * change after this is written, the fix has to hold for ANY image rather than
 * for the ones on the site today, so the trail carries its own backdrop. At
 * 65% black the lightest composite possible is #2D2D2D over a white photo,
 * or #595959 with no overlay at all, so white text measures at worst 6.9:1.
 *
 * No font-size or line-height is declared here on purpose: css/breakpoint-scale.css
 * is generated to be the single owner of those two properties per breakpoint,
 * and it is loaded after this file.
 * ------------------------------------------------------------------ */

.pc-breadcrumbs {
    display: inline-block;
    margin-top: 1.25rem;
    padding: 0.25rem 1.125rem;
    border-radius: 1.875rem;
    background: rgba(0, 0, 0, 0.65);
}

.pc-breadcrumbs ul li,
.pc-breadcrumbs ul li a,
.pc-breadcrumbs ul li a:hover,
.pc-breadcrumbs ul li a:focus-visible {
    color: #fff;
}

/* Underlined, so what is a link and what is the page you are on is not told
   apart by colour alone (checklist 8.1, 7.1). The vertical padding is what
   takes each crumb to the 24 CSS px pointer target of checklist 7.8. */
.pc-breadcrumbs ul li a {
    display: inline-block;
    padding: 0.25rem 0;
    text-decoration: underline;
}

.pc-breadcrumbs ul li [aria-current="page"] {
    text-decoration: none;
}

/* The theme draws the chevron between crumbs with `li:after`, whose glyph is
   U+E844 -- a Private Use Area codepoint that means "chevron" only inside the
   feather icon font. Pseudo-element content reaches the accessibility tree and
   cannot be given aria-hidden, so a screen reader met an unmapped character
   between every crumb. The separator moves into the markup, where aria-hidden
   applies; these declarations restate the theme's rule so it looks the same.
   Checklist 10.2. */
.pc-breadcrumbs ul li::after {
    content: none;
}

.pc-breadcrumbs__separator {
    display: inline-block;
    padding: 0 0.5rem 0 0.625rem;
    vertical-align: middle;
    font-family: "feather";
    font-size: 0.8125rem;
    font-weight: 900;
}

/* ------------------------------------------------------------------ *
 * 8.3 — the menu item for the page you are on
 *
 * The theme has an active state and it is the wrong one. `.nav-item.active
 * .nav-link` is `opacity: .6` (css/style.css:8983), the same declaration it
 * gives `:hover` -- so the current page would be dimmer than its siblings,
 * indistinguishable from whatever the pointer happens to rest on, and closer to
 * the 4.5:1 floor rather than further from it. Nothing ever applied it anyway:
 * js/main.js compares the last URL segment against the whole href and never
 * matches. includes/navbar.php now marks the item server-side instead, so the
 * cue works with JavaScript off.
 *
 * Two signals, neither of them colour: weight, and an underline. Either alone
 * would satisfy a greyscale test; both together also survive `forced-colors`,
 * where font-weight is not a forced property and a text decoration is repainted
 * with the text it belongs to. That is why this is an underline rather than the
 * `::after` bar the same effect usually gets -- a bar's `background` is forced
 * to `Canvas` and disappears, and it would have to be restated at the six
 * widths where css/corporate.css shrinks `.nav-link` padding, down to
 * 0.5625rem. An underline tracks the text at every one of them for free.
 *
 * 700 rather than 600 because css/corporate.css already sets the whole menu to
 * 600; against a 500 baseline this would be a step of nothing.
 *
 * Thickness and offset are in em so they track the reader's font size. No
 * font-size or line-height is declared here -- css/breakpoint-scale.css is the
 * single owner of those two and is loaded after this file.
 * ------------------------------------------------------------------ */

/* The ancestor of the current page: the dropdown a submenu page sits under.
   It gets the underline but NOT the weight, because the dropdown is closed by
   default and this is the only thing the reader can see -- while, once opened,
   it must still not compete with the page itself. Also undoes the theme's
   dimming, which is what `.active` would otherwise mean. */
.navbar .navbar-nav .nav-item.active > .nav-link {
    opacity: 1;
    text-decoration: underline;
    text-decoration-thickness: 0.125em;
    text-underline-offset: 0.3em;
}

/* The page itself, whether it sits at the top level or inside a dropdown. */
.navbar .navbar-nav .nav-link[aria-current="page"],
.navbar .navbar-nav .dropdown-menu a[aria-current="page"] {
    opacity: 1;
    font-weight: 700;
    text-decoration: underline;
    text-decoration-thickness: 0.125em;
    text-underline-offset: 0.3em;
}

/* ------------------------------------------------------------------ *
 * 7.2 — visited links, and 7.1 / 8.4 — the underline and colour that
 * make an in-content link a link
 *
 * Nothing in this repository styled :visited before, so every link on the
 * site looked identical whether or not the reader had already been there.
 *
 * What :visited is allowed to change is decided by the browser, not by us.
 * To stop a page reading a reader's history out of the layout, only the
 * colour properties apply -- color, background-color, text-decoration-color
 * and the border/outline colours -- and even those are ignored on any
 * descendant of the link. Measured in Chrome on this site rather than taken
 * from the spec: a colour on the <a> itself paints, `a:visited h3` and
 * `a:visited *` do not, and a border-colour that goes transparent -> opaque
 * is dropped because the alpha is taken from the unvisited state. There is
 * therefore no way to make a visited link bolder, or to give it an underline
 * it did not already have. The distinction has to be carried by colour, and
 * the two states cannot be 3:1 apart from each other while both stay above
 * 4.5:1 on white -- that is arithmetic, not a compromise, and it is why
 * browsers' own blue/purple defaults are equally close in lightness.
 *
 * The same restriction means a link whose visible text lives in a child
 * element cannot show the state at all. That is the six whole-card links on
 * the homepage, whose headings carry their own colour class: they are left
 * as they are rather than having the class stripped off every card heading.
 *
 * Contrast, computed against the backgrounds the pages actually use:
 *   #8E24AA on #ffffff                       7.04:1
 *   #8E24AA on #f4f5fa (light-gray section)  6.47:1
 *   #3C2FC0 on #ffffff                       8.90:1
 * ------------------------------------------------------------------ */

/* The exclusions sit in :where() so they cost no specificity: this stays at
   the weight of a plain `a:visited`, which is enough to beat the theme's
   `.nav-link`, `.dropdown-item` and `.pcs-sitemap__link` colours, and low
   enough that the per-context rules below still override it.
   Buttons and the logo are excluded because they are not read as links;
   the skip link because it is a fixed control, not a destination; and
   [aria-current] because the page you are on is already marked as such. */
a:visited:where(:not(.btn):not([role="button"]):not(.navbar-brand):not(.footer-logo):not(.pc-skip-link):not([aria-current])) {
    color: #8E24AA;
}

/* The breadcrumb trail is the only place on any of the 14 pages where an
   in-scope link sits on a dark backdrop, so it is the only per-context
   override needed. Its backdrop is rgba(0,0,0,0.65) over an editor-supplied
   photograph, so the colour has to hold against the lightest composite that
   backdrop can produce -- #595959, over a pure white image. #FFBEFF measures
   4.69:1 there and 9.22:1 over the hero's own overlay at #2D2D2D; the
   #8E24AA above would have been 1.6:1 and unreadable. */
.pc-breadcrumbs ul li a:visited {
    color: #FFBEFF;
}

/* 7.1 — editor-authored prose. The theme strips the underline off every link
   (css/style.css:114) and its hover colour is commented out
   (css/style.css:118), so a link inside a paragraph was separated from the
   text around it by colour alone, at 2.03:1 against the body's #15161D --
   under the 3:1 that 7.1 requires of a link that is not underlined. The
   underline is the fix; it also means the reader is not asked to tell two
   purples apart to know that something is a link at all.
   .pc-rich-content had no link rule whatsoever before this.
   Thickness and offset are in em so they track the reader's font size. No
   font-size or line-height is declared here -- css/breakpoint-scale.css is
   the single owner of those and is loaded after this file. */
.pc-content a,
.pc-blog-content a,
.pc-rich-content a,
.pc-custom-html a {
    color: #3C2FC0;
    text-decoration: underline;
    text-decoration-thickness: 0.0625em;
    text-underline-offset: 0.2em;
}

.pc-content a:visited,
.pc-blog-content a:visited,
.pc-rich-content a:visited,
.pc-custom-html a:visited {
    color: #8E24AA;
}

/* The accessibility panel's high-contrast mode repaints every link #ff0 with
   !important (pcadmin/public/core/components/accessibility/accessibility.css),
   which would erase the visited state for exactly the readers most likely to
   depend on it. pcadmin is a shared submodule, so the override belongs here:
   one class more specific, and !important to match theirs. #FF9BEA measures
   11.13:1 on the mode's black; the unvisited #ff0 measures 19.56:1.
   The second rule restores their white hover, which the first would otherwise
   win by source order. */
body.a11y-contrast-high a:visited {
    color: #FF9BEA !important;
}

body.a11y-contrast-high a:visited:hover {
    color: #fff !important;
}

/* ------------------------------------------------------------------ *
 * 1.32 (EN 301 549 11.7) — the operating system's colour settings
 *
 * Windows High Contrast Mode, and anything else that sets
 * `forced-colors: active`, replaces the page's palette with the reader's own.
 * The browser does most of it: `color`, `background-color`, `border-color`,
 * `outline-color` and SVG `fill`/`stroke` are all overridden, and Chromium
 * also forces `-webkit-text-fill-color` at paint time, so the theme's
 * gradient-clipped headings stay readable (verified by pixel sampling, not by
 * computed style -- getComputedStyle still reports the author's transparent
 * value there, which is misleading).
 *
 * What the browser does NOT do is invent a replacement for something it took
 * away. `box-shadow` is forced to `none` and a translucent background collapses
 * into the forced canvas, so anything whose only visible edge was a shadow, or
 * whose only substance was a tint, simply disappears. Those are the cases
 * below. Everything here uses the CSS system colour keywords, because the point
 * of the rule is to follow the reader's chosen theme rather than to substitute
 * a second palette of our own.
 * ------------------------------------------------------------------ */

@media (forced-colors: active) {
    /* The theme draws most cards, medallions and panels with a shadow and no
       border. `outline` rather than `border` on purpose: it restores the edge
       without overriding a border the element may already have, and without
       adding to the box and reflowing the page. */
    [class*="box-shadow-"] {
        outline: 1px solid CanvasText;
    }

    /* State the focus ring instead of relying on whatever the forced palette
       happens to map the theme's navy to. Highlight is the reader's own
       selection colour, which is the one they expect to mean "you are here". */
    :focus-visible {
        outline: 3px solid Highlight !important;
        outline-offset: 2px !important;
    }

    /* The pagination dots separate current from not-current by opacity, and
       opacity is not a forced property, so in a forced palette both dots end up
       the same solid colour. Give them a filled/hollow difference instead. */
    .swiper-pagination-bullet::after {
        background: Canvas;
        border: 1px solid CanvasText;
        opacity: 1;
    }

    .swiper-pagination-bullet-active::after {
        background: Highlight;
    }

    /* Defensive, and deliberately not load-bearing in Chromium: it already
       paints these correctly. Other engines are not required to force a
       property this far outside the spec's list, and a heading painted with a
       transparent fill over a stripped gradient is invisible rather than merely
       ugly. landing-page.css sets the fill with !important, so this must too. */
    [class*="text-gradient-"],
    .text-sliding-line,
    .image-mask,
    .text-outline {
        -webkit-text-fill-color: CanvasText !important;
        background-image: none !important;
    }

    .nav-link:hover {
        -webkit-text-fill-color: LinkText !important;
    }

    /* 7.2 — the reader's own visited-link colour, which is the one they
       already recognise, in place of the magentas chosen above. !important
       because the per-context visited rules earlier in this file are more
       specific than a bare `a:visited`, and a forced palette has to win
       against every one of them, not just the site-wide default. */
    a:visited {
        color: VisitedText !important;
    }

    /* 13.2 -- `border-color` is a forced property, so the #B3261E below is
       confiscated and repainted as CanvasText, which is also what a valid
       field's border becomes. `border-width` is NOT forced, so 1px vs 3px does
       survive on its own -- but that is a quantitative difference, and at a
       reader's chosen zoom on a 4px-radius field it is easy to miss. solid vs
       dashed is categorical and costs nothing, so state it. The error text
       needs nothing here: `color` is forced and the ::before glyph is text, so
       the browser repaints both without help. */
    input.form-control.is-invalid,
    select.form-control.is-invalid,
    select.form-select.is-invalid,
    textarea.form-control.is-invalid,
    .pc-audit-scope input.scan-input.is-invalid {
        border-style: dashed !important;
    }
}

/* ---------------------------------------------------------------------------
   6.11 -- line spacing that survives the heading it sits on
   --------------------------------------------------------------------------- */

/* The accessibility panel's headings are <h6>, so the theme's h6 rule supplies
   their line-height -- but pcadmin's own .accessibility-heading overrides the
   font-size to 16px and leaves the line-height alone. Once the theme's h6
   line-height became a ratio it started tracking that 16px instead of the
   1.75rem it was written against, and the panel's headings tightened from
   31.2px to 17.8px of leading.
   pcadmin is a shared submodule, so the fix belongs here: state the leading
   these headings actually render at, unitless, as its own declaration. */
.accessibility-heading {
    line-height: 1.95;
}

/* The theme's h6 line-height used to step down with the rest of the small-screen
   type scale, restated per breakpoint in css/breakpoint-scale.css. The font size
   here does not step down -- pcadmin pins it at 16px -- so a single ratio would
   flatten the step and leave the panel's headings looser on a phone than they
   were. These are the two restatements, at the same widths that file uses. */
@media (max-width: 61.9375em) {
    .accessibility-heading {
        line-height: 1.70625;
    }
}

@media (max-width: 47.9375em) {
    .accessibility-heading {
        line-height: 1.4625;
    }
}

/* Editor content headings take their font size from pcadmin's content.css
   (`.pc-content h2 { font-size: 1.85em }`) but their line-height from the
   theme, which wrote those line-heights against its own much larger display
   sizes. The result -- roughly 1.83 to 2.03 of leading on a blog heading -- is
   an accident of the cascade rather than a design, but it is what the site
   renders today, so it is preserved here as a ratio rather than redesigned.
   pcadmin is a shared submodule; the rule belongs in this repository.

   Each ratio is the measured line-height over the measured font size, so the
   rendering is unchanged to within a rounding of the last decimal. The two
   restatements below exist because the theme's heading line-heights step down
   at these widths while the content font size does not -- without them a single
   ratio would flatten the step and leave blog headings looser on a phone than
   they are today. Widths match css/breakpoint-scale.css. */
.pc-content h1 { line-height: 1.96099; }
.pc-content h2 { line-height: 1.83148; }
.pc-content h3 { line-height: 1.96078; }
.pc-content h4 { line-height: 2.03294; }

@media (max-width: 61.9375em) {
    .pc-content h1 { line-height: 1.71587; }
    .pc-content h2 { line-height: 1.60254; }
    .pc-content h3 { line-height: 1.71569; }
    .pc-content h4 { line-height: 1.77882; }
}

@media (max-width: 47.9375em) {
    .pc-content h1 { line-height: 1.47075; }
    .pc-content h2 { line-height: 1.37361; }
    .pc-content h3 { line-height: 1.47059; }
    .pc-content h4 { line-height: 1.52471; }
}

/* The .lh-* scale now means "N/16" -- N px of leading at the default base size.
   That reproduces the old rendering wherever the element really is 16px, which
   covers most of it. These are the shapes where it is not, each one measured on
   the rendered page by scripts/measure-line-height.mjs --propose rather than
   assumed. Every selector pairs the leading class with the size class the same
   element already carries, so the ratio is stated where both are known and no
   markup has to change. */
.fs-14.lh-24 { line-height: 1.71429; }   /* 24px over 14px */
.fs-17.lh-28 { line-height: 1.64706; }   /* 28px over 17px */
.fs-18.lh-30 { line-height: 1.66667; }   /* 30px over 18px */
.fs-14.lh-30 { line-height: 2.14286; }   /* 30px over 14px */

/* The list bullet icons set a 32px line box to centre a 12px or 14px glyph. */
.list-style-02 li i.fs-12 { line-height: 2.66667; }
.list-style-02 li i.fs-14 { line-height: 2.28571; }

/* These two carry no size class: they take the 17px body size, so the scale's
   16px assumption is off by a pixel and a half. Each has exactly one usage
   shape across all 28 pages -- a .fs-* pairing would have nothing to pair. */
.lh-22 { line-height: 1.29412; }         /* 22px over the 17px body */

@media (max-width: 35.9375em) {
    .xs-lh-28 { line-height: 1.64706; }  /* 28px over the 17px body */
}

/* The badge drops to 12px at the sm breakpoint while its 30px line box does
   not, so the ratio has to step with it. */
@media (max-width: 47.9375em) {
    .sm-fs-12.lh-30 { line-height: 2.5; }
}

/* ------------------------------------------------------------------ *
 * 12.6 / 12.23 — field help text, and the sentence that explains the
 * asterisk
 *
 * 12.6 (WCAG 2.4.6, 3.3.5) wants the label to say exactly what to type,
 * including the format, and help text beside the field where the label cannot
 * carry it all. Nothing on the public site had any: no input anywhere resolved
 * an `aria-describedby`, and the accepted shapes for the scanner's URL field
 * lived only in js/audit-scanner.js. The hint element the section templates now
 * render is what this styles.
 *
 * Deliberately no font-size and no line-height. css/breakpoint-scale.css is the
 * single owner of those two and is generated, not authored, so a size declared
 * here would sit outside the small-screen scale it restates. Inheriting also
 * keeps the hint at the surrounding body size, which 6.9 puts at 16px or more --
 * the usual "make help text smaller" reflex would have taken it below that.
 * The hint reads as secondary through weight and colour instead: the labels
 * above it are 600, this is 400.
 *
 * #4b4b4b measures 8.7:1 on the white contact and request forms and 8.0:1 on
 * the scanner's #F5F5F5 panel, so it clears 4.5:1 (8.4) on both surfaces with
 * room to spare. `color` is a forced property, so a forced palette repaints it
 * without help from us, and the accessibility panel's high-contrast mode
 * already matches `body.a11y-contrast-high p` at a higher specificity than this
 * rule -- neither needs an override here.
 * ------------------------------------------------------------------ */

.pc-field-hint {
    margin: 0.25rem 0 0;
    font-weight: 400;
    color: #4b4b4b;
}

/* 12.23 wants the asterisk explained before the first field, not after the
   form. It is ordinary prose rather than a hint, so it takes the body colour
   and only needs separating from the fields below it. */
.pc-required-note {
    margin: 0 0 1rem;
    font-weight: 400;
    color: #4b4b4b;
}

/* ------------------------------------------------------------------ *
 * 12.8 / 8.5 — form control border contrast · WCAG 1.4.11
 *
 * 12.8 asks for 3:1 where a field's border is the only thing showing the
 * field is there. Every control on this site met that condition and none met
 * the ratio: each one is `bg-transparent`, or filled with the exact colour of
 * the panel behind it, so there was never a second indicator to fall back on.
 * Measured with scripts/cdp.mjs against the rendered page, worst background
 * first:
 *
 *   #e4e4e4 on the .bg-gradient-white forms  1.18:1   contact, request
 *   #e4e4e4 on white                         1.27:1   footer newsletter
 *   #eaeaea on the white scan card           1.20:1   audit scanner
 *   no border at all                           n/a    intl-tel-input's search
 *
 * audit.css:380 styles a dark-panel `.action-input` at 1.36:1, which looks
 * like a sixth case and is not one: no markup in the repo renders that class,
 * so there is nothing to repaint and no rule for it here.
 *
 * #767676 is 4.17:1 on #F5F5F5, 4.20:1 on the #F6F6F6 end of the gradient and
 * 4.54:1 on white. The 3:1 floor would have allowed #8e8e8e, but only by 0.03,
 * and the two greys behind these fields are a gradient stop and a panel token
 * that a future redesign could move a shade either way; the margin is there so
 * that a background tweak cannot silently reopen this.
 *
 * What is deliberately *not* changed is the --extra-medium-gray variable
 * (#e4e4e4) and audit.css's --pc-aud-line-strong. Both read as form tokens and
 * are not: the same two values draw the footer rule, the section dividers in
 * about-features and pricing-table, the cta-pill outline and a decorative pill
 * in the scanner. 1.4.11 covers controls, not decoration, and darkening a
 * hairline divider to 4:1 would be a visible change to a page that does not
 * need one. So the override is at the control selectors, and the variables
 * keep their meaning.
 *
 * Focus is not touched. `input:focus { border: 1px solid #c2c2c2 }`
 * (css/style.css:1598) never wins on this site -- the utility below carries
 * !important and audit.css is more specific -- so every field holds its
 * resting border while the 3px :focus-visible outline above does the work.
 * That was confirmed after the 0.3s border-color transition had settled, not
 * on the first frame, where the old colour is still painted.
 * scripts/field-border-check.mjs focuses every control and re-measures, so if
 * that rule ever starts winning it fails there rather than in an audit.
 * ------------------------------------------------------------------ */

/* Beats .border-color-extra-medium-gray, which is !important. */
input.border-color-extra-medium-gray,
textarea.border-color-extra-medium-gray,
select.border-color-extra-medium-gray {
    border-color: #767676 !important;
}

/* Controls that take their border from the base rule rather than the utility. */
input,
select,
textarea,
.form-control,
.form-select {
    border-color: #767676;
}

/* The scanner's field is filled with a grey a shade off the white card it sits
   on (1.04:1), so its border really is the whole of it. audit.css is linked by
   the audit section templates and so loads after this file at equal
   specificity, hence !important. Its :focus rule paints #0E0E0C and needs no
   help -- but note that only shows up once the 0.15s transition has run. */
.pc-audit-scope .scan-input {
    border-color: #767676 !important;
}

/* intl-tel-input ships its country search with `border-width: 0` on a white
   dropdown -- a 358x48 field with no edge whatsoever. Its stylesheet is linked
   by the two form templates and so loads after this file, hence !important. */
.iti__search-input {
    border-bottom: 1px solid #767676 !important;
}

/* 8.5, same #e4e4e4 at 1.27:1 on white. These are buttons rather than fields,
   so 12.8 does not reach them, but they are UI components and 1.4.11 does.
   Pairs with the border-style rule further up, which makes the edge render. */
button.slider-navigation-style-04 {
    border-color: #767676 !important;
}

/* ---------------------------------------------------------------------------
 * 13.2 -- an invalid field is visually distinct, and not by colour alone
 * WCAG 3.3.1 Error Identification, WCAG 1.4.1 Use of Colour
 *
 * Before this, three of the four public forms marked nothing at all: the
 * contact and request forms called form.reportValidity() and the scanner wrote
 * a banner, so the field itself was untouched. The fourth -- the footer
 * newsletter, the only control that carried the theme's `required` class, and
 * so the only one js/main.js:2113 ever marked -- changed exactly one property:
 *
 *     resting   1px solid rgb(118, 118, 118)     #767676
 *     invalid   1px solid rgb(220, 53, 69)       #dc3545
 *
 * Same width, same style, no icon (Bootstrap's exclamation SVG is cancelled by
 * style.css:19957 `background-image: inherit`), no shadow, no aria-invalid.
 * That is 1.4.1's textbook failure, and the numbers say how complete it is:
 * #767676 has a relative luminance of 0.1812 and #dc3545 has 0.1819, so the
 * contrast between the two states is 1.003:1. Greyscaled, the "error" border
 * and the resting border are the same colour. Measured in Chrome, not read off
 * this file.
 *
 * So the cue here is geometry, not colour: three times the ink of the resting
 * edge. Width survives greyscale, a monochrome display, dichromacy, and a
 * forced palette (see the forced-colors block above, which also makes it
 * dashed). The red is kept, but only as the redundant second cue 1.4.1 allows
 * -- it is no longer carrying the state on its own. The other half of the cue
 * is .pc-field-error, injected next to the field by js/field-validation.js;
 * text is the one thing no display mode can take away, and it is what carries
 * 13.4's "how to fix it" and 13.5's "next to the field".
 *
 * Uniform on all four sides on purpose. A left accent bar was the tidier-
 * looking option and is wrong here: intl-tel-input absolutely positions its
 * country button over the left edge of both phone fields, so a thick left
 * border would render behind the flag and vanish on exactly the two fields
 * most likely to be wrong.
 *
 * These selectors are (0,2,1) and beat the 12.8 rules above, which are (0,1,1),
 * so the 12.8 block needed no :not(.is-invalid) amendment and is untouched.
 * Confirmed by injecting this rule and reading back `3px rgb(179, 38, 30)`.
 *
 * The field grows 4px taller when marked (measured 50px -> 54px). box-sizing is
 * border-box, but these inputs set no explicit height, so border-box has no
 * fixed size to absorb the extra 2px per edge. Accepted rather than corrected:
 * compensating with padding-block means re-deriving the maths per selector
 * group every time a padding changes, for 4px. The field's top-left does not
 * move, which is what scripts/invalid-field-check.mjs asserts.
 *
 * #B3261E rather than Bootstrap's #dc3545 because one colour has to serve two
 * floors: the border needs 3:1 (12.8, 8.5) and the message text needs 4.5:1
 * (8.4). #dc3545 is 4.0:1 on white and fails the second. #B3261E is 6.53:1.
 * ------------------------------------------------------------------------- */

input.form-control.is-invalid,
select.form-control.is-invalid,
select.form-select.is-invalid,
textarea.form-control.is-invalid,
.pc-audit-scope input.scan-input.is-invalid {
    border-style: solid !important;
    border-width: 3px !important;
    border-color: #B3261E !important;
}

/* Bootstrap's red exclamation SVG is a colour-only cue in a decorative slot,
   the same red as the border, with no text alternative, and it is not painted
   under a forced palette. It is already dead on the newsletter; turning it off
   everywhere makes the geometry the whole of the visual state, so there is one
   thing to guard rather than two. The padding-right Bootstrap adds alongside it
   is left alone -- a slightly wider right gutter on an invalid field harms
   nothing, and restating it here would hard-code style.css:1576's value. */
.form-control.is-invalid,
.was-validated .form-control:invalid {
    background-image: none !important;
}

/* The text half of the cue. ::before rather than a character inside the string
   so a translator cannot drop it, and \FE0E forces text presentation so it does
   not arrive as a colour emoji on macOS -- which would put us back to a cue
   made of colour. */
.pc-field-error {
    margin: 0.25rem 0 0;
    font-weight: 600;
    color: #B3261E;
}

.pc-field-error::before {
    content: "\26A0\FE0E\00A0";
}

/* ---------------------------------------------------------------------------
 * 13.4 -- a failure in the audit report's action cards
 *
 * .action-msg is one region carrying two kinds of news, and audit.css styles it
 * for the happy one: #6BD49F, the same green as the primary button. Rendering
 * "the PDF could not be built" in the success colour says the opposite of what
 * it means, which is 1.4.1 read the wrong way round -- colour carrying
 * information, and carrying it inverted.
 *
 * #FFA396 measures 10.06:1 against the card's #0E0E0C, so it clears 4.5:1 with
 * room to spare (scripts/contrast.mjs). Colour is not asked to do the work
 * alone: the warning glyph is the non-colour cue, forced to text presentation
 * with U+FE0E so it cannot arrive as a colour emoji, exactly as .pc-field-error
 * does it. Specificity beats audit.css's own rule, so load order does not
 * matter here.
 * ------------------------------------------------------------------------- */
.pc-audit-scope .action-msg.pc-action-error {
    color: #FFA396;
}

.pc-audit-scope .action-msg.pc-action-error::before {
    content: "\26A0\FE0E\00A0";
}

/* ------------------------------------------------------------------ *
 * 14.3 — Buttons of at least 44 x 44 CSS px, comfortably spaced
 *
 * WCAG 2.5.5 Target Size (Enhanced), AAA. The sheet asks for two things in one
 * sentence -- `vaehemalt 44 x 44 CSS piksli suurused` AND `piisavalt suurte
 * vahedega` -- and both are measured by scripts/target-size-check.mjs, which
 * hit-tests the box rather than reading it off getBoundingClientRect(). Read
 * that file before changing anything here; several of the choices below only
 * make sense once you know what it measures.
 *
 * Three techniques, and which one a control gets is not a matter of taste:
 *
 *   1. Grow the box, where the control owns its space and nothing else wants
 *      it. Simplest, and the only one that also creates SPACING.
 *   2. Turn neighbouring margin into padding, where the room is already
 *      reserved beside the control and is merely not part of it. Costs no
 *      layout at all -- the caret above and the accordion rows below.
 *   3. A centred pseudo-element overlay, where growing the box would move a
 *      glyph or reflow text. Buys size but NOT spacing, since overlays can lap
 *      over their neighbours, so it is never the answer for controls sitting in
 *      a row (see the bullets above).
 *
 * The bullets, the burger, the caret and the panel close button are handled at
 * their existing rules further up, next to the 24px reasoning they replace,
 * rather than being restated here.
 * ------------------------------------------------------------------ */

/* The header accessibility button ships as .btn.btn-link.p-0, and Bootstrap's
   .p-0 carries !important, so padding cannot grow it. min-* is not a utility
   and lands cleanly. The <i> keeps its 28px font size, so the glyph is
   unchanged and only the pressable area around it grows. */
#accessibility-toggle {
    min-width: 44px;
    min-height: 44px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

/* The dropdown parents in the main menu (Lahendused / Solutions) and the
   language switcher are <button class="nav-link">; the theme gives them 10px
   of vertical padding, which lands them at 36-40 tall. Scoped to button so the
   menu's <a class="nav-link"> items are untouched -- those are links, and
   links are checklist 7.8's business at 24px, not this rule's. The li they sit
   in is 82px tall, so there is nothing to reflow. */
button.nav-link {
    min-height: 44px;
}

/* The FAQ rows.
 *
 * The toggle is 27.5 tall inside a header that is 58.5, because the header
 * carries 15px of padding above and below it. That padding is already there
 * and already looks pressable; it simply was not part of the button. Moving it
 * from the header to the toggle takes the target to 57.5 and leaves every
 * measurement of the accordion exactly where it was -- no row grows, no page
 * gets longer. Growing the toggle with min-height instead would have added
 * 16.5px to every FAQ row for no visual reason.
 *
 * Both selectors carry the theme's own specificity for the property they
 * override, and accessibility.css is loaded after style.css. */
.accordion .accordion-item .accordion-header {
    padding-top: 0;
    padding-bottom: 0;
}

.pc-accordion-toggle {
    padding-top: 0.9375rem;     /* the 15px that was on .accordion-header */
    padding-bottom: 0.9375rem;
    min-height: 44px;           /* for a row whose question is unusually short */
}

/* The carousel pause control.
 *
 * A 32px circle, sitting on its own with 48px of clear space around it. The
 * circle is a designed element and there is no reason its visible size has to
 * be the pressable one, so this is the overlay case: the button still draws at
 * 32px and answers across 44. Nothing is near enough for the overlay to lap
 * over. .pc-slider-pause is already position: absolute, so the overlay needs no
 * further positioning context. */
.pc-slider-pause::after {
    content: "";
    position: absolute;
    top: 50%;
    left: 50%;
    width: 44px;
    height: 44px;
    transform: translate(-50%, -50%);
}

/* intl-tel-input's country selector, 42px wide and 2px short.
 *
 * Overridden here rather than in css/intlTelInput.min.css: that file is vendor
 * and any edit to it is lost on the next update, which is the same reason the
 * 13.2 work left the theme's own stylesheets alone. The button is absolutely
 * positioned inside .iti__country-container, which is itself absolutely
 * positioned inside a 50px-tall field, so the 2px comes out of the field's own
 * left padding and moves nothing. The phone inputs carry ps-12 / ps-lg-10, far
 * more than the 2px needed, so the typed number cannot collide with it. */
.iti__selected-country {
    min-width: 44px;
}

/* The five "open the chat" buttons that sit inside running sentences.
 *
 * WCAG 2.5.5 has an Inline exception that would let these stand at 26-29px
 * tall, and it was deliberately not taken: they are grown like every other
 * button. What they are NOT given is vertical padding, which is the obvious
 * way and the wrong one -- it would push the lines of the paragraph apart and
 * move the line boxes pinned by checklist 6.10-6.13 in .line-height-baseline.json,
 * and it would drop the .text-decoration-line-bottom underline away from the
 * text it underlines. A centred overlay gives the same 44px of thumb without
 * touching the text: the sentence reads and measures exactly as before.
 *
 * Selected on the data attribute the chat handler already binds to
 * (includes/scripts.php), not on the .btn-link / .btn-link-gradient utility
 * classes these happen to carry -- those are shared with #accessibility-toggle
 * and #accessibility-close, which are not inline and are handled above.
 *
 * The overlay does reach about 8px above and below the line the button sits
 * on. Whether that lands on a neighbouring target is not a thing to reason
 * about: target-size-check.mjs measures every button on the page after this
 * rule is applied, and a swallowed neighbour shows up there as a failure. */
[data-action="open-chat"] {
    position: relative;
}

[data-action="open-chat"]::after {
    content: "";
    position: absolute;
    left: 0;
    right: 0;
    top: 50%;
    /* 46, not 44, and the extra 2px is not slack for its own sake.
       `top: 50%` on an absolutely positioned box resolves against its
       containing block's PADDING box, while the target has to be 44 tall about
       the centre of the BORDER box -- and these buttons carry a border-bottom
       (.text-decoration-line-bottom, 1px, and -medium, 2px) and no border-top.
       The two centres are therefore half a pixel to a pixel apart, and a 44px
       overlay came up exactly that much short on the low side: measured, the
       probe 21.5px above centre answered with the button and the one 21.5px
       below answered with the section behind it. A pixel of margin on each
       side absorbs any border these buttons wear. The requirement is a
       minimum, so clearing it by 2px is meeting it, not padding the number. */
    height: 46px;
    transform: translateY(-50%);
}

/* 14.3 — room for the two controls in the mobile header.
 *
 * Below lg the header carries exactly two buttons, the accessibility toggle and
 * the burger, and at 44x44 each they no longer fit the space the theme left
 * them. Measured at 375px before this rule: the toggle's target ran 289-333 and
 * the burger's 332-376, so they overlapped by a pixel AND the burger's ran a
 * pixel off the right edge of the screen -- the burger sat 10px from the edge
 * and a 44px target needs 22.
 *
 * Both are moved left rather than shrunk. There is no shortage of room to take
 * it from: the logo ends at 170px and the two controls need 88 of the 205 that
 * are left. The gutters trimmed by the <=25em rule above stay trimmed; this
 * only reserves the space the two targets actually occupy.
 * ------------------------------------------------------------------ */

@media (max-width: 61.99875em) {
    /* Half the burger is 11px, so 12 of padding puts its centre 23 from the
       screen edge and the whole target on screen. */
    .navbar > .container-fluid > .menu-order {
        padding-right: 0.75rem;
    }

    /* And this clears the burger's target of the toggle's, with room between
       them rather than the pixel of overlap they had. */
    .header-icon {
        margin-right: 0.75rem;
    }
}

/* And the one place the overlay above gets clipped before it can do its job.
 *
 * The chat buttons in the CTA pill and the FAQ sit inside
 * `.feature-box ... overflow-hidden`, theme boilerplate carried along by the
 * section templates. Where that box is taller than the overlay it costs
 * nothing; where it is not, it silently trims the target. On /en/about-us the
 * pill's feature box is 36px tall, so the 46px overlay was cut to 36 and the
 * button measured 36.9 instead of 46 -- the only control still failing after
 * everything above.
 *
 * The clip guards nothing here: the pill's rounded corners, background and
 * border are on the outer column, not on this box, and its 20px of vertical
 * padding leaves ample room for the overlay to sit in. Lifted only for the
 * boxes that actually contain a chat button, so every other feature box on the
 * site keeps the theme's behaviour untouched. `!important` because
 * `overflow-hidden` is a Bootstrap utility and carries its own.
 * ------------------------------------------------------------------ */

.feature-box:has([data-action="open-chat"]) {
    overflow: visible !important;
}