/* <editor-fold desc="A11Y TOOLBAR | Header trigger"> */
.a11y-widget { position: relative; }

.header-icon-btn {
    display: flex;
    align-items: center;
    justify-content: center;
    flex-shrink: 0;
    width: 40px;
    height: 40px;
    padding: 4px;
    border: none;
    border-radius: var(--radius-6);
    cursor: pointer;
}
.header-icon-btn > * { width: 24px; height: 24px; }

header .a11y-widget .a11y-toggle { background: var(--color-grey-20); }
header .a11y-widget .a11y-toggle:hover { background: var(--color-grey-40); }
header .a11y-widget .a11y-toggle:active { background: var(--color-grey-60); }
/* aria-expanded, а не перевірка класу .opened, бо це єдине, що JS
   завжди тримає синхронізованим на кожному шляху відкриття/закриття - і десктопний dropdown,
   І мобільний popup (JS перемикає клас `.opened` лише
   для випадку десктопного dropdown). */
header .a11y-widget .a11y-toggle[aria-expanded="true"] { background: var(--color-grey-60); }
header .a11y-widget .a11y-toggle-icon {
    width: 24px;
    height: 24px;
    background: var(--color-black-100);
    mask-image: url(../images/a11y-toolbar/icon-inclusivity.svg);
    -webkit-mask-image: url(../images/a11y-toolbar/icon-inclusivity.svg);
    mask-repeat: no-repeat;
    -webkit-mask-repeat: no-repeat;
    mask-position: center;
    -webkit-mask-position: center;
    mask-size: contain;
    -webkit-mask-size: contain;
    pointer-events: none;
}
/* </editor-fold> */

/* <editor-fold desc="A11Y TOOLBAR | Desktop panel"> */
.a11y-panel-desktop {
    display: none;
    position: absolute;
    top: calc(100% + 7px);
    left: 0;
    width: 367px;
    background: var(--color-white);
    border-radius: var(--radius-6);
    box-shadow: 0px 8px 12px 0px rgba(225, 225, 225, 0.5), 0px 0px 1px 0px #ccc;
    z-index: 9;
}
.a11y-panel-desktop .a11y-options { padding: 24px; }
/* </editor-fold> */

/* <editor-fold desc="A11Y TOOLBAR | Shared options content (rendered twice — desktop dropdown + mobile popup) "> */
.a11y-options {
    display: flex;
    flex-direction: column;
    align-items: flex-start;
    gap: 16px;
}
.a11y-section-label {
    width: 100%;
    margin: 0;
    color: var(--color-black-80);
    font-size: var(--font-size-16);
    font-weight: var(--font-weight-regular);
    line-height: var(--line-height-22);
}
.a11y-options-row {
    display: flex;
    align-items: flex-start;
    gap: 32px;
}
.a11y-option {
    display: flex;
    flex-direction: column;
    align-items: center;
    gap: 12px;
    width: 85px;
    padding: 0;
    background: none;
    border: none;
    cursor: pointer;
}
.a11y-swatch {
    display: flex;
    align-items: center;
    justify-content: center;
    width: 80px;
    height: 80px;
    padding: 9.6px;
    background: var(--color-white);
    border: 1px solid var(--color-grey-60);
    border-radius: var(--radius-16);
    pointer-events: none;
}
.a11y-swatch .a11y-icon-font-size {
    background: var(--color-black-100);
    mask-repeat: no-repeat;
    -webkit-mask-repeat: no-repeat;
    mask-position: center;
    -webkit-mask-position: center;
    mask-size: contain;
    -webkit-mask-size: contain;
}
/* У Figma різний розмір гліфа для кожної опції (24/32/40px) усередині того самого
   свотча 80px, а не один розмір, розтягнутий на весь свотч - збігається з тим, як "Aa" росте
   помітно більшим у Звичайний/Середній/Великий. */
.a11y-option[data-a11y-font-size="regular"] .a11y-icon-font-size { width: 24px; height: 24px; mask-image: url(../images/a11y-toolbar/icon-font-size-regular.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-font-size-regular.svg); }
.a11y-option[data-a11y-font-size="medium"] .a11y-icon-font-size { width: 32px; height: 32px; mask-image: url(../images/a11y-toolbar/icon-font-size-medium.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-font-size-medium.svg); }
.a11y-option[data-a11y-font-size="large"] .a11y-icon-font-size { width: 40px; height: 40px; mask-image: url(../images/a11y-toolbar/icon-font-size-large.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-font-size-large.svg); }

.a11y-swatch .a11y-icon-contrast {
    width: 26px;
    height: 26px;
    background: var(--color-black-100);
    mask-repeat: no-repeat;
    -webkit-mask-repeat: no-repeat;
    mask-position: center;
    -webkit-mask-position: center;
    mask-size: contain;
    -webkit-mask-size: contain;
}
.a11y-option[data-a11y-contrast="normal"] .a11y-icon-contrast { mask-image: url(../images/a11y-toolbar/icon-contrast-normal.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-contrast-normal.svg); }
.a11y-option[data-a11y-contrast="bw"] .a11y-icon-contrast { mask-image: url(../images/a11y-toolbar/icon-contrast-bw.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-contrast-bw.svg); }
.a11y-option[data-a11y-contrast="wb"] .a11y-icon-contrast { mask-image: url(../images/a11y-toolbar/icon-contrast-wb.svg); -webkit-mask-image: url(../images/a11y-toolbar/icon-contrast-wb.svg); }

/* Свотч Біло-Чорна у спокої показується як суцільна чорна плитка з білим гліфом (як
   у Figma в стані спокою) замість спільного вигляду біла/сіра рамка/темний гліф -
   після вибору повертається до спільного вигляду, див. нижче. */
.a11y-option[data-a11y-contrast="wb"] .a11y-swatch {
    background: var(--color-black-100);
}
.a11y-option[data-a11y-contrast="wb"] .a11y-icon-contrast { background: var(--color-white); }

.a11y-option-label {
    margin: 0;
    color: var(--color-black-100);
    font-size: var(--font-size-16);
    font-weight: var(--font-weight-regular);
    line-height: var(--line-height-22);
    text-align: center;
    pointer-events: none;
}

/* Вибраний стан - одне послідовне зелене оформлення для всіх 6 кнопок-опцій,
   зокрема Біло-Чорна (перевизначає власне чорне "preview"-оформлення вище; у Figma-
   файлі цей стан не описано, див. доповнення до плану a11y-збірки). */
.a11y-option[aria-pressed="true"] .a11y-swatch {
    background: var(--color-green-10);
    border-color: var(--color-grey-60);
}
.a11y-option[aria-pressed="true"] .a11y-icon-font-size,
.a11y-option[aria-pressed="true"] .a11y-icon-contrast {
    background: var(--color-green-100);
}

.a11y-reset {
    display: flex;
    align-items: center;
    justify-content: center;
    gap: 8px;
    width: 100%;
    height: 52px;
    padding: 8px;
    background: var(--color-white);
    border: 1px solid var(--color-black-60);
    border-radius: var(--radius-6);
    cursor: pointer;
    transition: background-color .3s, border-color .3s;
}
/* Стан "є що скидати" - перемикається JS (клас .-active, syncA11yState())
   щоразу, коли будь-яка опція розміру шрифту/контрасту відхилена від значення за замовчуванням, незалежно від
   hover/press. В інших випадках стан спокою лишається сірим/приглушеним (як у Figma); саме
   це насправді сигналізує, що кнопка зараз щось робить. */
.a11y-reset.-active {
    border-color: var(--color-black-80);
}
.a11y-reset.-active .a11y-reset-label { color: var(--color-black-100); }
.a11y-reset.-active .a11y-icon-reset { background: var(--color-black-100); }

/* Статичний експорт Figma не має hover/active-стану для цієї кнопки - її стан
   спокою (сіра рамка + сірий текст, без акцентного кольору) виглядає як disabled без жодного
   зворотного зв'язку. Додано hover/active-оформлення за наявним у цій кодовій базі
   патерном контурної кнопки .btn-white (style.css), а не
   вигадано новий. */
.a11y-reset:hover {
    background: var(--color-black-10);
    border-color: var(--color-black-100);
}
.a11y-reset:hover .a11y-reset-label { color: var(--color-black-100); }
.a11y-reset:hover .a11y-icon-reset { background: var(--color-black-100); }
.a11y-reset:active {
    background: var(--color-black-20);
    border-color: var(--color-black-100);
}
.a11y-reset .a11y-icon-reset {
    width: 24px;
    height: 24px;
    background: var(--color-grey-400);
    mask-image: url(../images/a11y-toolbar/icon-reset.svg);
    -webkit-mask-image: url(../images/a11y-toolbar/icon-reset.svg);
    mask-repeat: no-repeat;
    -webkit-mask-repeat: no-repeat;
    mask-position: center;
    -webkit-mask-position: center;
    mask-size: contain;
    -webkit-mask-size: contain;
    pointer-events: none;
}
.a11y-reset-label {
    color: var(--color-black-60);
    font-size: var(--font-size-18);
    font-weight: var(--font-weight-bold);
    line-height: var(--line-height-24);
    pointer-events: none;
}
/* </editor-fold> */

/* <editor-fold desc="A11Y TOOLBAR | Mobile popup"> */
#popup-a11y.popup {
    display: none;
    padding: 18px 16px;
}
#popup-a11y .a11y-mobile-title-row {
    display: flex;
    align-items: center;
    gap: 12px;
    width: 100%;
}
#popup-a11y .a11y-mobile-title {
    flex: 1 0 0;
    margin: 0;
    color: var(--color-black-100);
    font-family: var(--font-family-base);
    font-weight: var(--font-weight-black);
    font-size: var(--font-size-18);
    line-height: var(--line-height-24);
}
/* .a11y-options сам має align-items:flex-start (спільно з десктопним dropdown,
   де ширина панелі 367px уже точно збігається з шириною власного ряду options -
   три свотчі по 85px + два проміжки по 32px = 319px, плюс padding панелі 24px×2 =
   367px - тож flex-start там ніколи не лишав видимого запасу). Мобільний popup натомість
   на всю ширину viewport, тож той самий блок ряду фіксованої ширини + кнопки скидання притиснутий
   ліворуч зі змінним проміжком праворуч залежно від телефона. Тут центруємо
   його; .a11y-section-label за замовчуванням вирівняний ліворуч, тож він
   теж центрований - інакше підпис плавав би ліворуч над тепер відцентрованим рядом. */
#popup-a11y .a11y-options {
    margin-top: 16px;
    align-items: center;
}
#popup-a11y .a11y-section-label { text-align: center; }

/* спільний брейкпойнт повноекранного popup - 719px (style.css), але власний
   мобільний брейкпойнт хедера (коли тригер стає доступним поза десктопним dropdown)
   - 1180px - без цього перевизначення є прогалина 720-1180px, де тригер показується, але
   popup ще не на весь екран. */
@media (max-width: 1180px) {
    #popup-a11y.popup {
        width: 100%;
        height: 100%;
        padding: 18px 16px;
        border-radius: 0;
    }
}
/* </editor-fold> */

/* <editor-fold desc="A11Y TOOLBAR | Font-size mechanism"> */
html.a11y-font-medium { --a11y-font-scale: 1.15; }
html.a11y-font-large { --a11y-font-scale: 1.3; }
/* </editor-fold> */

/* <editor-fold desc="A11Y TOOLBAR | Contrast mechanism"> */
/* Перевизначення токенів, а не лише filter:grayscale(1) - звичайний фільтр лише знімає
   насиченість, але не компенсує того, що прибирання насиченості
   з акценту середньої світлоти робить його вицвілим (реальна проблема: наш власний
   --color-green-100 має лише 2.57:1 контрасту з білим навіть у повному
   кольорі - самого grayscale недостатньо, бо він зберігає сиру яскравість).
   Значення нижче виведені так само, як це робить чорно-біла схема еталонного
   сайту (порівняно їхні світлу тему + bw палітри поруч, прогнано
   реальну математику контрасту WCAG): майже нейтральні токени лишено без змін
   (вони й так слабконасичені, виправляти нічого), бліді фонові відтінки мапляться на
   так само блідий наявний сірий токен, а насичені акцентні кольори мапляться на
   сірий ТЕМНІШИЙ, ніж підказала б їхня сира яскравість - підвищуючи контраст
   понад оригінальний, а не лише повторюючи його - із перевикористанням наявного сірого
   токена, де він справді достатньо близький, і лише двома новими разовими hex-
   значеннями (green-80/green-60), де нічого з наявної палітри не підійшло.
   Відносний порядок збережено (green-100 найтемніший/найсильніший, далі до
   green-60 найсвітліший, що відповідає початковій прогресії спокій → hover).
   Це чисті сірі R=G=B, тож filter: grayscale(1) нижче на них нічого не змінює -
   він усе одно потрібен як універсальний захист для кількох кольорів, які цей
   прохід по токенах свідомо лишив літералами (box-shadow rgba, кілька
   декоративних разових значень). */
html.a11y-contrast-bw {
    --color-green-100: var(--color-grey-400);      /* #707070, 4.95:1 проти білого (було 2.57:1) */
    --color-green-80: #808080;                     /* .btn:active - 3.95:1 */
    --color-green-60: #949494;                     /* .btn:hover - 3.03:1 */
    --color-green-10: var(--color-grey-100);        /* #f5f5f5 - блідий відтінок лишається блідим */
    --color-green-20-light: var(--color-grey-200);  /* #eeeeee - блідий відтінок лишається блідим */
    --color-red-700: var(--color-black-80);         /* #4e4c4c, 8.54:1 проти білого (було 4.19:1) */
    --color-link: var(--color-black-60);            /* #7a7979, 4.34:1 проти білого (було 3.43:1) */
    --color-link-active: var(--color-grey-500);     /* #9a9a9a - короткий спалах :active, нижча планка допустима */
    filter: grayscale(1);
}
/* Ні `html`, ні `body` не мають явного background будь-де в цій темі
   (assets/css/style.css) - видимий білий колір сторінки - це лише власний
   дефолтний canvas браузера, що просвічує крізь прозорий root, а не намальований піксель.
   filter може діяти лише на те, що справді намальовано, тож без цього "білий"
   фон сторінки лишався білим під Біло-Чорна.

   Окрема реверсована палітра, а не filter:invert() - відповідає тому, як
   це робить власна схема білого на чорному в еталонному сайті (порівняно їхню
   нейтральну шкалу світлої теми з їхньою білою-на-чорному: найсвітліший↔найтемніший
   поміняні місцями від краю до краю, напр. їхній світлий neutral-0 #ffffff парується з
   їхнім wb neutral-360 #ffffff - те саме значення, протилежний кінець шкали - підтверджено
   по всій 31-кроковій шкалі, а не лише по краях). invert() спершу пробували
   і відкотили: він однаково торкається кожного намальованого пікселя, зокрема
   фото, що дає справжній вигляд фотонегатива, а підхід через токени
   такої проблеми не має, бо торкається лише того, що справді стилізоване
   через ці змінні.

   Кожен базовий токен нейтрального/сірого/чорного нижче впорядковано за реальною
   яскравістю WCAG (а не за назвою) і віддзеркалено від краю до краю навколо середини цього
   списку, напр. --color-white (найсвітліший) отримує значення --color-black і навпаки,
   --color-grey-20 (2-й за світлотою) отримує значення --color-black-100 (2-й
   найтемніший) і так далі - той самий прийом дзеркалення, підтверджений в
   еталоні. --color-grey-300 стоїть рівно посередині впорядкованого списку,
   тож не має перевизначення (дзеркалиться сам на себе).

   8 акцентних токенів (green/red/link) отримують свіжі значення, підібрані саме під темний
   фон, а не просто свої значення для bw,
   використані навпаки - колір, що добре читається на білому, автоматично не
   читається добре на чорному. Той самий принцип, що й у bw: підібрати те, що
   справді добре контрастує з (тепер темною) сторінкою, а не просто
   знебарвити на місці, перевикористовуючи наявні значення токенів, де одне вже підходить.

   filter: grayscale(1) лишено, хоча ніщо тут уже не має лишатися
   насиченим - те саме універсальне міркування, що й у bw, для box-shadow rgba та
   кількох декоративних разових кольорів, які прохід по токенах цієї теми не покрив.
   Він НЕ розв'язує повністю проблему справжніх фото: grayscale прибирає колір, але не
   перевертає світлоту, тож справді багатотонове фото лишається темним-на-тепер-темній
   -сторінці - той самий компроміс, який приймає й сам еталон (їхній власний
   блок білого-на-чорному теж не має invert()), і не те, що можна виправити без
   окремого асета для темного режиму саме для того фото. (Логотип хедера/футера
   раніше теж потрапляв під це застереження, але виявився плоским
   одноколірним знаком після реального семплінгу - див. його власне правило нижче,
   яке інвертує його як будь-яку іншу плоску іконку.) */
html.a11y-contrast-wb {
    /* базова шкала нейтральних/сірих/чорних, повне наскрізне дзеркалення за яскравістю */
    --color-white: #000000;
    --color-black: #ffffff;
    --color-black-100: #f6f8fa;
    --color-black-80: #f5f5f5;
    --color-black-60: #ebedf2;
    --color-black-40: #d1d5dc;
    --color-black-20: #cad3da;
    --color-black-10: #9a9a9a;
    --color-grey-20: #221f1f;
    --color-grey-40: #7a7979;
    --color-grey-60: #d3d2d2;
    --color-grey-100: #4e4c4c;
    --color-grey-200: #707070;
    --color-grey-400: #eeeeee;
    --color-grey-500: #e9e9e9;
    --color-grey-border: #a7a5a5;
    /* --color-grey-300 (#d2d2d2) - власна середина шкали - без перевизначення */

    /* акцентні токени, підібрані під контраст із новим темним фоном,
       а не перевикористані з мапінгу bw (значення bw розраховані на контраст із білим) */
    --color-green-100: #9a9a9a;      /* 7.47:1 проти чорного - основний акцент */
    --color-green-80: #7a7979;       /* .btn:active - 4.84:1 */
    --color-green-60: #707070;       /* .btn:hover - 4.24:1 */
    --color-green-10: #4e4c4c;       /* блідий фоновий відтінок → темний фоновий відтінок (використання в style.css) */
    --color-green-20-light: #4e4c4c; /* наразі не використовується жодним живим правилом, лишено
       узгодженим із темним відтінком green-10 на випадок змін */
    --color-red-700: #f5f5f5;        /* помилки потребують максимальної читабельності незалежно від теми */
    --color-link: #a7a5a5;           /* 8.63:1 проти чорного */
    --color-link-active: #cad3da;    /* короткий спалах :active, світліший за посилання в спокої */

    background: var(--color-white);
    filter: grayscale(1);
}
/* Скоуплені перевизначення для ВИБРАНОГО свотча саме в режимі WB. Правило
   вибраного стану насправді читає background --color-green-10 (а не
   --color-green-20-light, як помилково припустив попередній прохід) - а
   green-10 також використовується на звичайних сторінках як блідий фоновий відтінок секцій
   (style.css), де він правильно має лишатися темним/непомітним на новій
   темній сторінці. Це протилежне тому, що потрібно самому ВИБРАНОМУ СВОТЧУ
   (він має виділятися на панелі, а не зливатися) - та сама категорія
   конфлікту "дві ролі хочуть протилежної світлоти", що й green-100 нижче, те саме виправлення:
   скоуплене перевизначення тут, а не змушувати спільний токен обслуговувати обидві ролі. */
html.a11y-contrast-wb .a11y-option[aria-pressed="true"] .a11y-swatch {
    background: var(--color-grey-60);       /* #d3d2d2 */
    border-color: var(--color-grey-border); /* #a7a5a5 */
}
/* --color-green-100 (колір вибраної іконки, виставлений вище) теж не можна просто
   перевернути на світлий - він також використовується як світлий на чорному ТЕКСТ деінде (напр.
   посилання "see more" у пошуку), який має лишатися світлим, щоб читатися на
   сторінці. Але те саме світле значення на тепер світлому фоні вибраного свотча
   (одразу вище) мало б ледве помітний контраст зі своїм
   свотчем. */
html.a11y-contrast-wb .a11y-option[aria-pressed="true"] .a11y-icon-font-size,
html.a11y-contrast-wb .a11y-option[aria-pressed="true"] .a11y-icon-contrast {
    background: var(--color-grey-20); /* #221f1f */
}
/* Той самий конфлікт "дві ролі хочуть протилежної світлоти", що й у вибраного свотча вище,
   цього разу на самій кнопці-тригері в хедері (.a11y-toggle-icon використовує
   --color-black-100 для заливки скрізь - секція тригера в хедері, початок
   цього файлу). У спокої власний фон кнопки - --color-grey-20, який
   дзеркалиться ТЕМНИМ під wb, тож майже біла іконка там читається нормально без перевизначення.
   Але стани :active / [aria-expanded="true"] перемикають фон кнопки
   на --color-grey-60, який дзеркалиться СВІТЛИМ (#d3d2d2) - поєднання його
   зі ще майже білою іконкою падає до ~1.4:1 контрасту, тобто іконка
   майже зникає саме тоді, коли панель відкрита. Фіксуємо іконку темною
   лише для цих двох станів зі світлим фоном, те саме виправлення, що й для свотча вище. */
html.a11y-contrast-wb header .a11y-widget .a11y-toggle:active .a11y-toggle-icon,
html.a11y-contrast-wb header .a11y-widget .a11y-toggle[aria-expanded="true"] .a11y-toggle-icon {
    background: var(--color-grey-20); /* #221f1f */
}
/* Inline <svg> іконки, вставлені напряму з експортів Figma (пошук у хедері, соцмережі
   у футері, кнопки закриття попапів, іконки повідомлень docs/legal тощо - перевірено
   по всьому сайту 2026-08-24), захардкоджують власні fill/stroke ("#221F1F" майже
   скрізь, бо це і є звичайне значення --color-black-100, плюс "white"
   контр-заливка на двоколірних іконках на кшталт хрестика закриття попапа). Жодне з цього
   не токен, тож нічого вище до цього не дістає, а контейнери цих іконок (поле
   пошуку, футер, попап) усі стають темними під цією схемою - темне на темному.

   Замість перевизначення fill/stroke для кожної іконки (попередній підхід тут,
   і причина, чому звичайний аудит path[fill] не масштабується: кожен майбутній
   експорт іконки потребував би власної копії цього правила), інвертуємо
   відрендерені пікселі іконки цілком. Звичайна 2-кольорова іконка (будь-який темний знак, зокрема на прозорому
   фоні) чудово переживає filter:invert(1) - вона просто стає тією самою
   іконкою світлою на темному замість темної на світлому, а наявний
   filter:grayscale(1) вище вже обробляє все, з чим invert() сам не впорався б
   (випадковий насичений колір, що прослизнув у "мав би бути нейтральною" іконку). Це
   той самий invert(), який на початку пробували й відкотили для *всієї сторінки*
   (див. обґрунтування wb вище) - проблема там була в тому, що фото і логотип
   ставали фотонегативом; обмежено лише простими векторними іконками, ця проблема
   не застосовується, і це саме той обхідний шлях, що дозволяє не правити
   вручну кожен SVG, який дизайнер експортуватиме надалі.

   За замовчуванням інвертуємо *все* під svg, а потім виносимо відомі
   винятки нижче - іконки/графіку, де інвертувати неправильно, а не бракує:
     - .post-meta / .author-name (single-post.php) уже використовують fill="currentColor"
       і успадковують власний (уже правильно перевертаний) токен кольору тексту сторінки -
       інверсія поверх перевернула б їх вдруге, тобто знову зламала.
     - .share-buttons (single-post.php) - це брендові іконки соцмереж для поширення
       (Telegram/Facebook/LinkedIn/X) - інверсія перетворює офіційні брендові кольори
       на безглузді відтінки.
     - .page-404 - це ілюстрація маскота 404 - декоративна графіка, та сама категорія
       "не можна чіпати без окремого темного асета", що й логотип.
     - .notice-icon (single-rp_knowledge_base.php, single-rp_legal.php) - це
       помаранчева іконка попереджувального трикутника - її колір семантичний (попередження = помаранчевий),
       а не декоративний, і помаранчевий працює і на світлому, і на темному.
     - .payment-page .branding-block - це самодостатнє демо "кастомізація
       брендингу чекауту" з ВЛАСНИМ перемикачем світлої/темної теми, що вже підключений
       (svg.colorable path.c-b/.c-w, style.css), плюс реальні логотипи платіжних брендів
       (Google Pay, Apple Pay, Mastercard тощо) - інверсія боролася б із його
       наявним механізмом і спотворила б брендові знаки.

   Нові іконки для роботи під wb нічого додаткового не потребують. Лише майбутній брендовий логотип чи
   ілюстрація потребує явного обхідного шляху `.no-a11y-invert`, як і
   винятки вище. */
html.a11y-contrast-wb svg:not(.no-a11y-invert) {
    filter: invert(1);
}
html.a11y-contrast-wb .post-meta svg,
html.a11y-contrast-wb .author-name svg,
html.a11y-contrast-wb .share-buttons svg,
html.a11y-contrast-wb .page-404 svg,
html.a11y-contrast-wb .notice-icon,
html.a11y-contrast-wb .payment-page .branding-block svg {
    filter: none;
}

/* Та сама першопричина, що й в інверсії svg вище, але для гліфів ACF icon-picker -
   повторюваного патерну "маленька іконка по центру власного тонованого квадрата", що перевикористовується
   по всьому сайту під багатьма різними назвами (mission-block, audience-block,
   solutions-block, payment-methods-block, cards-block, forwhom-cards,
   contacts-v4-item, cost-block, step-header, kb-cards, search-state тощо -
   template-parts/feature-card-block.php плюс кілька саморобних двійників, що
   копіюють його точну структуру .icon-wrapper/img), які лежать у
   боксі var(--color-grey-40)/--color-grey-20/--color-green-20-light, і всі вони
   правильно стають темними під wb згідно з таблицею дзеркалення вище. Але
   wp_get_attachment_image() (lazy_get_attachment_image(), helpers.php) завжди
   рендерить <img>, ніколи не inline <svg>-розмітку навіть для .svg-вкладень, тож жоден
   із них не потрапляє під правило svg-invert вище і лишається початкового кольору на
   тепер темному боксі.

   Проте не кожне зображення в цій родині - справді плоский гліф: перевірено кожну
   іконку .feature-card по всьому сайту (about-us-v4, acquiring, business-breakfast,
   buy-with-rpay-v4, ecommerce, fiscalization-v4, fop-from-zero-v4, front-page_v4,
   horoshop, invoicing-v4, payment-installments-v4, rates-page, webinar-single-v4)
   шляхом завантаження кожного файлу: кожна справжня іконка в цій кодовій базі - незалежно
   від відтінку, напр. icon-internet.svg в installments-v4-conditions світло-блакитна, а не
   звичайний #221F1F/#4E4C4C - це справжнє .svg-завантаження, тоді як кожен випадок, який
   зламався б під суцільною інверсією (container-1/2/3.png та
   benefit-icon-manual-work.png в acquiring, benefit-icon-*.png/previewcrm*.png в horoshop,
   ілюстрація папки quick-start-block в ecommerce, справжні фото-портрети спікерів у
   business-breakfast/webinar-single-v4) - це растрове завантаження - попри те, що
   в кількох із цих імен файлів теж є "icon". Спершу brightness(0) (а не
   звичайний invert(1)) робить відтінок неважливим для справжніх SVG: він примусово дає
   чистий чорний незалежно від точного початкового кольору перед інверсією в білий -
   той самий прийом, що вже використовують hover-стани .kb-card/.legal-card у цій кодовій базі -
   тож будь-яка плоскокольорова іконка стає чистим білим гліфом. Той самий brightness(0)
   якраз і нищить растрову ілюстрацію: стискає її до суцільного чорного
   силуету (руйнуючи її справжні градієнти/деталі фото) і після інверсії робить
   порожнім білим блоком.

   [src$=".svg"] - отже, справжній розрізняльний сигнал, а не ім'я файлу чи
   колір - обмеження селектора ним автоматично виключає кожен поточний растровий випадок,
   а будь-яке майбутнє завантаження іконки має лише справді БУТИ
   .svg, щоб отримати цю обробку безкоштовно, без ручного обхідного шляху на кшталт .no-a11y-invert
   (на відміну від правила для inline-<svg> вище, де кольоровий
   брендовий знак усе ще потребує його, бо в inline <svg> немає аналогічної ознаки
   "хибного формату", за якою можна фільтрувати).

   Іконки бонусів/CTA-hero (.get-guide-block, .cta-banner-block та споріднені, виправлені
   вище, .bonuses-block .bonus-card - вибірково перевірено одну, вона вже попередньо забарвлена в білий
   у вихідному SVG) - це інша, ілюстраційна родина і поза
   обсягом тут; це правило покриває лише патерн "маленька іконка в тонованому квадраті"
   у feature card. */
html.a11y-contrast-wb .feature-card .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .about-us-v4 .values-block .value-card .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .contacts-v4-item .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .fiscalization-v4 .cost-block .card .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .installments-v4-conditions .step-header .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .kb-cards .kb-card .icon-wrapper img[src$=".svg"],
html.a11y-contrast-wb .search-page .search-state .icon-wrapper img[src$=".svg"] {
    filter: brightness(0) invert(1);
}

/* Та сама проблема "іконка ACF/теми, відрендерена як <img>, ніколи не потрапляє під правило svg-invert",
   що й у родини feature-card вище, лише для власного патерну іконок hero-v4.css -
   .hero-v4-stat-icon (template-parts/hero-v4.php, повторно використовується
   головною/acquiring/fiscalization-v4/horoshop/invoicing-v4/business-breakfast/
   hero single-rp_webinars + секцією business-breakfast "Де і коли", яка
   повторно використовує ту саму розмітку hero-v4-stats удруге згідно зі своїм коментарем у
   template_business-breakfast.php) лежить у власному боксі var(--color-grey-40),
   так само, як усюди. Перевірено кожну іконку на кожній сторінці, що використовує цю
   розмітку (головна, acquiring, horoshop, business-breakfast разом із повторним використанням "Де і
   коли") - усі .svg, усі стабільно #221F1F. [src$=".svg"] додано
   все одно, з того самого захисного міркування, що й для родини feature-card вище: нічого не
   коштує при поточній реальності "усе SVG" і не дозволяє майбутньому растровому
   завантаженню тут мовчки повторити поломку типу container-1.png,
   знайдену (і виключену цим самим захистом) у тій родині. */
html.a11y-contrast-wb .hero-v4-stat-icon img[src$=".svg"] {
    filter: brightness(0) invert(1);
}

/* Той самий розрив img-не-svg знову, цього разу в головній навігації хедера - іконка кожного
   пункту випадного підменю (get_header_submenu() у helpers.php, що використовується і звичайним
   меню хедера, і меню хедера rp_documentation, керується через ACF
   $options_fields['header_menu']/['documentation_header_menu']) рендериться
   через ту саму структуру img-wrapper по всьому сайту, лежачи в
   боксі var(--color-grey-40) у спокої та var(--color-green-20-light) при
   hover/.current - обидва стають темними під wb так само, як і деінде. Перевірено кожну
   іконку в головному меню хедера (усі 19, з двох різних сторінок) - усі .svg,
   усі #221F1F; доступного поста rp_documentation, щоб так само перевірити його
   окреме documentation_header_menu, не було, але воно рендериться через цей
   самий селектор через той самий get_header_submenu(), тож [src$=".svg"] покриє
   і його, щойно його перевірять - те саме міркування про захист у глибину, що й вище. */
html.a11y-contrast-wb header .header-menu ul li.has-submenu .submenu ul li a .img-wrapper img[src$=".svg"] {
    filter: brightness(0) invert(1);
}

/* Третій патерн рендерингу для тієї самої родини "іконка ніколи не потрапляє під правило
   svg-invert" - звичайний CSS background: url(file.svg) на псевдоелементі,
   а не <img> і не inline-елемент <svg>, тож жодне з двох виправлень
   вище теж до нього не дістає. submenu-icon-2.svg (fill="#221F1F", файл перевірено
   напряму) перевикористовується для обох власних шевронів головної навігації хедера:
   маленької стрілки, що з'являється при hover усередині пункту підменю (span:after),
   і шеврона розгортання/згортання мобільного/планшетного акордеона (верхній рівень
   > a:before, власний блок @media у style.css). filter працює на background-image
   так само, як на <img>, тож виправлення те саме - воно лише
   має націлюватись на елемент/псевдоелемент, що несе фон напряму,
   бо окремого дочірнього вузла для вибору немає. */
html.a11y-contrast-wb header .header-menu ul li.has-submenu .submenu ul li a span:after,
html.a11y-contrast-wb header .header-menu > ul > li > a:before {
    filter: brightness(0) invert(1);
}

/* Брендовий логотип хедера/футера (header.php/footer.php, wp_get_attachment_image()/
   lazy_get_attachment_image() з того самого вкладення custom_logo, два різні
   зареєстровані розміри зображення одного .svg) - це "від природи темний логотип", який, за коментарем
   таблиці дзеркалення wb вище, самим grayscale(1) не виправити без "окремого
   асета логотипа для темного режиму" - загалом це правда (справжній багатотоновий фото-/
   ілюстраційний логотип не можна безпечно перефарбувати), але саме цей логотип виявився
   плоскою єдиною заливкою скрізь ("ROZETKA Pay", #06BA52 - через canvas пройдено кожен
   піксель реального файлу, щоб підтвердити, що в ньому не ховається другий колір,
   попри те, як він може виглядати в малих/стиснутих розмірах). Тому він нічим
   не відрізняється від звичайних одноколірних родин іконок, що вже оброблені
   brightness(0) invert(1) деінде в цьому файлі - окремий асет зрештою не потрібен,
   принаймні доки логотип лишається таким простим. */
html.a11y-contrast-wb .header-logo img,
html.a11y-contrast-wb .footer-logo img {
    filter: brightness(0) invert(1);
}

/* Той самий розрив img-не-svg ще раз, для акордеона сайдбару knowledgebase.css і
   його власних результатів пошуку (.kb-cards вище вже покриті - це два його
   споріднені елементи в тому ж файлі: ліва навігація по категоріях і випадний
   список AJAX-пошуку). Виправлення нотатки, залишеної біля виправлення feature-card вище ("іконки-обгортки
   сайдбар-навігації KB/legal та результатів пошуку... неперевернутий сирий hex-фон,
   окрема помилка") - це було правдою для legal-pages.css (.legal-sidebar/
   .legal-search-results, досі не виправлено, досі окрема помилка), але хибним для
   knowledgebase.css: перевірено тут повторно, і .kb-sidebar/.kb-search-results .icon-wrapper
   обидва вже використовують var(--color-grey-40) (перевірено вживу: іконка #221F1F на
   правильно перевернутому під wb боксі #7a7979), той самий безпечний токенізований патерн, що й
   скрізь в цьому файлі.
   .kb-search-results .kb-empty .icon-wrapper img навмисно виключено - на відміну від
   своїх темних плоских побратимів, цей (kb-search-empty-icon.svg) - багатоколірна
   ілюстрація "нічого не знайдено", уже fill="white" плюс власний внутрішній лінійний
   градієнт, перевірено вживу - інверсія зіпсувала б обидва. */
html.a11y-contrast-wb .kb-sidebar .nav-list .item .icon-wrapper img,
html.a11y-contrast-wb .kb-search-results .kb-result-item .icon-wrapper img {
    filter: brightness(0) invert(1);
}

/* Той самий третій патерн, що й власні шеврони головної навігації хедера вище - звичайний
   background: url("data:image/svg+xml,...fill='%23221F1F'...") на
   псевдоелементі розгортання/згортання has-child, а не <img> чи inline <svg>, тож
   він невидимий для обох правил invert деінде в цьому файлі. Ця єдина прогалина
   існує, хоча решта knowledgebase.css уже правильно
   токенізована - fill у data-URI взагалі не може посилатися на CSS custom property,
   тож це ніколи не був недогляд типу "треба було використати токен", як
   решта кольорів цього файлу, а просто інша техніка, що потребувала іншого
   виправлення. filter на ній усе одно працює так само. */
html.a11y-contrast-wb .kb-sidebar .nav-list li.has-child > a:after {
    filter: brightness(0) invert(1);
}

/* хаб legal-pages.css (.legal-sidebar/.legal-hub/.legal-search/.legal-cards) -
   це оригінал ще до токенів, від якого пізніше відділили і токенізували хаб knowledgebase.css (.kb-sidebar/.kb-hub-content/
   .kb-search/.kb-cards, обидва виправлені вище) -
   у його власному верхньому коментарі так і сказано ("Split off from legal-pages.css... Legal Info stays
   untouched"). Кожне значення нижче все ще той самий літеральний hex, який еквівалентне
   правило knowledgebase.css замінило на var() - підтверджено порівнянням двох
   файлів правило за правилом, а не вгадано - тож кожне перевизначення тут просто підставляє той самий
   токен, який knowledgebase.css уже довів як правильний для того самого місця.

   Це більше, ніж "іконки": інверсія лише іконок без перевертання
   їхніх контейнерних боксів і тексту зробила б гірше, а не краще - до
   цього .legal-cards/.legal-search-results/.legal-hub .hero-icon були самоузгодженими
   світлими островами (світлий бокс, темна іконка, темний захардкоджений текст, усе
   не зачеплене wb), які цілком читалися як є; лише icon-wrapper у .legal-sidebar
   (уже var(--color-grey-40), як у сайдбарі KB) та .legal-hub .hero-title/
   .hero-subtitle (color:#221f1f захардкоджено, лежить прямо на власному фоні
   сторінки, який ПЕРЕВЕРТАЄТЬСЯ на чорний) були справді зламані вже до цього. Перенесення
   решти хаба у відповідність тепер змушує кожну частину рухатися разом, а не лишає
   одні частини перевернутими, а інші ні.

   .legal-hub .hero-icon img та .legal-search-results .legal-empty .icon-wrapper
   img навмисно виключено з інверсії, з тих самих міркувань, що й їхні
   двійники в knowledgebase.css: legal-hero-icon.svg - двотонна ілюстрація
   (заливки #DFFEDD + white, перевірено вживу), а іконка "нічого не знайдено" буквально
   той самий спільний асет kb-search-empty-icon.svg (white + внутрішній градієнт), що
   використовується станом порожнього KB вище - жодна з них не плоский гліф. */
html.a11y-contrast-wb .legal-sidebar .nav-list .item .icon-wrapper img {
    filter: brightness(0) invert(1);
}
html.a11y-contrast-wb .legal-hub .hero-icon { background: var(--color-green-20-light); }
html.a11y-contrast-wb .legal-hub .hero-title,
html.a11y-contrast-wb .legal-hub .hero-subtitle { color: var(--color-black-100) !important; }
html.a11y-contrast-wb .legal-search .legal-search-input {
    background: var(--color-white);
    border-color: var(--color-grey-60);
}
html.a11y-contrast-wb .legal-search .legal-search-input:focus-within { border-color: var(--color-black-100); }
html.a11y-contrast-wb .legal-search .legal-search-input .legal-search-spinner { border-color: var(--color-black-80); border-right-color: transparent; }
html.a11y-contrast-wb .legal-search .legal-search-input input { color: var(--color-black-100); }
html.a11y-contrast-wb .legal-search .legal-search-input input::placeholder { color: var(--color-black-80); }
html.a11y-contrast-wb .legal-search-results { background: var(--color-white); }
html.a11y-contrast-wb .legal-search-results .legal-result-item { color: var(--color-black-100); }
html.a11y-contrast-wb .legal-search-results .legal-result-item .icon-wrapper { background: var(--color-grey-40); }
html.a11y-contrast-wb .legal-search-results .legal-result-item:hover .icon-wrapper { background: var(--color-green-20-light); }
html.a11y-contrast-wb .legal-search-results .legal-result-item .icon-wrapper img { filter: brightness(0) invert(1); }
html.a11y-contrast-wb .legal-search-results .legal-result-item .result-title { color: var(--color-black-100); }
html.a11y-contrast-wb .legal-search-results .legal-result-item .result-snippet { color: var(--color-black-80); }
html.a11y-contrast-wb .legal-search-results .legal-empty .icon-wrapper { background: var(--color-grey-20); }
html.a11y-contrast-wb .legal-search-results .legal-empty .empty-title { color: var(--color-black-100); }
html.a11y-contrast-wb .legal-search-results .legal-empty .empty-subtitle { color: var(--color-black-80); }
html.a11y-contrast-wb .legal-cards .legal-card { background: var(--color-grey-20); }
html.a11y-contrast-wb .legal-cards .legal-card:hover { background: var(--color-green-20-light); }
html.a11y-contrast-wb .legal-cards .legal-card .icon-wrapper { background: var(--color-grey-40); }
html.a11y-contrast-wb .legal-cards .legal-card:hover .icon-wrapper { background: var(--color-green-100); }
html.a11y-contrast-wb .legal-cards .legal-card .icon-wrapper img { filter: brightness(0) invert(1); }
html.a11y-contrast-wb .legal-cards .legal-card .card-title,
html.a11y-contrast-wb .legal-cards .legal-card .card-desc { color: var(--color-black-100); }

/* .tarif-card-header (template-parts/tarif-cards-block.php, спільний для сторінки
   Тарифи, Головна v4, Інвойсинг та Internet Acquiring) виставляє свій фон із
   сирого hex-значення просто з ACF-поля color-picker через inline-атрибут
   `style` - не токен, тож нічого вище не може його перевернути. Кожне значення, яке редактори
   реально обирали, - світлий/пастельний відтінок (це смуга заголовка, що лежить поверх
   інакше білої картки), а grayscale(1) лише знебарвлює його на місці без
   перевертання світлоти, тож він і тут лишається світлим. Текст заголовка/опису всередині,
   однак, не стилізується локально - він успадковує звичайний колір тексту body сторінки
   (--color-black-100), який правильно перевертається на майже білий для (тепер темної)
   сторінки деінде, лишаючи майже білий текст на цій ще світлій смузі заголовка.
   Довільні кольори з бекенду не можна надійно авто-інвертувати, тож замість боротьби
   з inline-фоном фіксуємо лише власний текст заголовка на його звичайне темне
   значення - він завжди мав лежати на світлому відтінку незалежно від режиму контрасту. */
html.a11y-contrast-wb .tarif-card-title,
html.a11y-contrast-wb .tarif-card-desc {
    color: var(--color-grey-20) !important; /* #221f1f */
}

/* Той самий патерн знову, знайдено під час аудиту винятку svg invert вище:
   ілюстрація маскота .page-404 (style.css) - це фіксований блідо-м'ятний (#E0F6EF)
   декоративний графічний елемент - виключений з інверсії вище, як і будь-яка інша
   ілюстрація, тож під wb лишається світлим. Його заголовок "Oops! 404" лежить
   поверх нього, але, як tarif-card-title, не стилізується локально - він успадковує
   --color-black-100, який перевертається на майже білий для решти (тепер
   темної) сторінки і стає невидимим на цьому одному навмисно ще світлому
   фоні. Те саме виправлення: фіксуємо заголовок темним, він завжди мав
   рендеритись поверх блідо-м'ятного незалежно від контрасту. */
html.a11y-contrast-wb .page-404 .title {
    color: var(--color-grey-20) !important; /* #221f1f */
}

/* Той самий патерн знову: .btn-black.btn-border (style.css) - це варіант із glassmorphism -
   background: rgba(255,255,255,.5), сире значення rgba, а не токен -
   використовується на ілюстрації маскота 404 вище (404.php, лежить на тому самому фіксованому
   блідо-м'ятному фоні) та в doc-head rp_documentation (single-rp_documentation.php,
   лежить на власному фіксованому #fafafa у .doc-head-background - documentation.css). Його
   колір тексту/іконки - --color-black-100, який під wb перевертається на майже білий так само
   як і всюди, але фон ніколи не перевертається на темний, тож текст кнопки
   стає невидимим (біле на білому). Фіксуємо його темним - як tarif-card-title
   і заголовок 404 вище, він завжди лежатиме на фіксованому світлому
   фоні незалежно від режиму контрасту. */
html.a11y-contrast-wb .btn-black.btn-border {
    color: var(--color-grey-20); /* #221f1f */
}

/* Ціла родина сторінок ділить один рецепт "картки-CTA з градієнтом" - завжди
   той самий двоступеневий діагональний градієнт, var(--color-green-20-light) у сирий
   літерал #fcfffc/#FCFFFC (варіюються лише кут і відсотки зупинок трохи
   від сторінки до сторінки), просто під різним класом-обгорткою щоразу, бо
   власний компонент кожної сторінки отримав свою назву, коли його копіювали:
     - .get-guide-block .block-wrapper       (fop-from-zero-v4, fiscalization-v4,
                                                acquiring, guides-v4)
     - .care-banner-container                 (front-page_v4)
     - .vacancies-cta-block .cta-card         (about-us-v4)
     - .cta-banner-block .block-wrapper       (ecommerce, і власний
                                                *другий* CTA acquiring далі у його файлі)
     - .final-cta-block .block-wrapper        (business-breakfast)
     - .webinar-page .last-block .block-wrapper (webinar-single-v4)
     - .installments-v4-plate .plate-wrapper  (payment-installments-v4)
   У кожному випадку перший стоп - токен і перевертається на темний під wb так само, як
   деінде, але сирий літеральний стоп ніколи не перевертається, тож картка виходить
   наполовину темна / наполовину ще майже біла. Текст заголовка/.desc/.subtitle всередині
   ніде в них не стилізується локально - він успадковує звичайний
   колір тексту body --color-black-100, який перевертається на майже білий для
   (правильно темної) половини і стає невидимим для (ще світлої) половини -
   читабельність залежить цілком від того, на яку половину діагоналі потрапляє даний рядок
   тексту. Один фіксований фон усуває це: прибираємо
   градієнт і фіксуємо всю картку на тому самому темно-сірому, у який
   перший стоп уже перевертається, тож кожен рядок тексту читається однаково незалежно від
   позиції. Одне правило з переліком кожного класу-обгортки (без префікса конкретної сторінки,
   жодна з цих назв ні для чого іншого не використовується) покриває кожного
   викликача, за тим самим міркуванням, що й виправлення slick-dots вище - і покриває будь-яку майбутню
   сторінку, що копіює цей самий рецепт під ще однією назвою обгортки, лише
   якщо цю назву теж додати сюди. */
html.a11y-contrast-wb .get-guide-block .block-wrapper,
html.a11y-contrast-wb .care-banner-container,
html.a11y-contrast-wb .vacancies-cta-block .cta-card,
html.a11y-contrast-wb .cta-banner-block .block-wrapper,
html.a11y-contrast-wb .final-cta-block .block-wrapper,
html.a11y-contrast-wb .webinar-page .last-block .block-wrapper,
html.a11y-contrast-wb .installments-v4-plate .plate-wrapper {
    background: var(--color-green-20-light); /* #4e4c4c під wb */
}

/* Індикатор активного стану .slick-dots - та сама
   пара background: var(--color-grey-border) [неактивний] / var(--color-green-100) [активний]
   повторюється дослівно в style.css (.customers-reviews-block) і в кожному
   CSS сторінки зі slick-каруселлю (about-us-page, acquiring, buy-with-rpay-v4, ecommerce,
   front-page_v4, horoshop, invoicing-v4, payment-installments-v4, rates-page).
   Під wb --color-grey-border (#a7a5a5) і --color-green-100 (#9a9a9a) опиняються
   у межах кількох % одне від одного за світлотою - обидва були підібрані під ще білу сторінку bw,
   а не під тепер темну сторінку wb, тож активна крапка перестає читатися як
   "акцентний колір, що виділяється" і читається як "той самий сірий, що й решта, ледь-ледь".
   Фіксуємо її плоским білим замість пошуку кращого сірого; один селектор тут
   покриває кожного викликача, бо всі вони ділять цю саму
   структуру `.slick-dots li.slick-active button`, замість дублювання
   перевизначення в CSS кожної сторінки. Навмисно літерал, а не
   var(--color-black) (який під wb теж дорівнює #ffffff, вище) - суть
   у безумовно чистому білому незалежно від того, що робить
   дзеркалена палітра, а не в "тому, чим зараз резолвиться --color-black". */
html.a11y-contrast-wb .slick-dots li.slick-active button {
    background: #ffffff !important;
}

/* .popup (style.css) не має рамки в жодному режимі - він відокремлюється від сторінки
   лише м'якою тінню rgba(0,0,0,...), а це якраз єдине, що
   grayscale(1) не може виправити (він знебарвлює, а не перевстановлює світло): під wb власний
   фон попапа --color-white, який перевертається на чорний так само, як сторінка за
   ним, тож *чорна* тінь на тепер чорній сторінці зовсім невидима - попап
   виглядає як звичайний чорний прямокутник, що висить без жодного краю. Кожен
   екземпляр .popup (get-consultation, thank-you, individual-rate, мобільний попап a11y
   тощо) ділить цей один базовий клас, тож одне перевизначення виправляє їх усі.
   Відтворює початкову двошарову тінь (м'яке ambient-сяйво + тонка лінія краю) з
   білим замість чорного - той самий прийом, що й .select-gr .select-list нижче, який
   має ту саму проблему: фон перевертається під сторінку. */
html.a11y-contrast-wb .popup {
    box-shadow: 0 0 96px 0 rgba(255, 255, 255, 0.1), 0 0 2px 0 rgba(255, 255, 255, 0.2);
}
html.a11y-contrast-wb .select-gr .select-list {
    box-shadow: 0 8px 12px 0 rgba(255, 255, 255, 0.15);
}

/* Загальносайтовий прохід (grep по кожному файлу assets/css/*.css на сирий hex, що збігається зі
   значенням наявного токена - той самий сигнал "мав би бути токеном, а не є", що
   знайшов legal-pages.css) виявив ще кілька місць поза межами однієї сторінки:

   header .mobile-nav (style.css) - планшетний/мобільний перемикач-гамбургер, присутній
   у хедері на кожній сторінці нижче ~1180px. Його власний фон - сира
   трійка #F6F8FA/#EBEDF2/#D3D2D2 (спокій/hover/відкрито, жодна не токен), яка
   ніколи не перевертається, тоді як самі смужки гамбургера (.nav-icon span) уже використовують
   var(--color-black) і ПЕРЕВЕРТАЮТЬСЯ на білий - тож під wb смужки стають білими,
   лежачи на фоні, що все ще майже білий, і перемикач стає
   цілком невидимим. Перевірено вживу на 1100px: підтверджено, кнопка була
   порожнім боксом без видимої іконки. Фіксація трьох станів фону
   на їхні точні токен-еквіваленти (підтверджено збігом hex, та сама техніка,
   що й у legal-pages.css) виправляє це, не чіпаючи смужки, які вже були
   правильними. */
html.a11y-contrast-wb header .mobile-nav { background: var(--color-grey-20); }
html.a11y-contrast-wb header .mobile-nav:hover { background: var(--color-grey-40); }
html.a11y-contrast-wb body.mobile-menu header .mobile-nav { background: var(--color-black-20); }

/* Типовий --btn-pulse-color у .btn (style.css) - сирий #06BA52 - кожен інший
   варіант (.btn-black/.btn-white, style.css) уже виставляє цю custom property
   із токена, це одне місце просто пропустили. Під wb власний фон кнопки
   (var(--color-green-100)) правильно приглушується до сірого, але кільце пульсації
   навколо неї (box-shadow, що використовує цю змінну, @keyframes
   btn-pulse у style.css) усе одно спалахувало б сирим насиченим зеленим - незначна невідповідність, а не
   помилка невидимості, як ті вище, але виправлення те саме. */
html.a11y-contrast-wb .btn { --btn-pulse-color: var(--color-green-100); }

/* Hover/active-стани пагінації, скопійовані з тим самим дрейфом сирого hex
   в обидва blog-pages-v2.css і search-page.css (структура .pag/.pag-btn
   спільна, згідно з "перевикористовуваним на всьому сайті хелпером pagination()" - але CSS-файл кожної сторінки
   повторно оголошує ці інтерактивні стани вручну, і лише стани спокою/
   hover у search-page.css випадково вже використовували токени). Перехідні
   стани (видимі лише посеред кліку чи hover), тож вплив менший, ніж у
   перемикача мобільної навігації вище, але та сама категорія помилки і те саме виправлення. */
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag:not(.current):hover,
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag:not(.current):active,
html.a11y-contrast-wb .search-page .pagination-list .pag:not(.current):active {
    color: var(--color-black-100);
    border-color: var(--color-black-100);
}
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag:not(.current):hover { background: var(--color-black-10); }
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag:not(.current):active,
html.a11y-contrast-wb .search-page .pagination-list .pag:not(.current):active { background: var(--color-black-20); }
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag-btn:not([disabled]):hover,
html.a11y-contrast-wb .search-page .pagination-list .pag-btn:not([disabled]):hover { background: var(--color-black-60); }
html.a11y-contrast-wb .blog-archive .latest-posts-section .pagination-container .pagination-list .pag-btn:not([disabled]):active,
html.a11y-contrast-wb .search-page .pagination-list .pag-btn:not([disabled]):active { background: var(--color-black-80); }

/* .pag-btn (стрілка попередня/наступна, усі три виклики pagination() - блог, пошук,
   webinar-archive-v4 - один спільний PHP-хелпер, includes/helpers.php) - це
   протилежна невідповідність порівняно з усім іншим у цьому файлі досі: її іконка
   (blog/icon_pagination.svg, перевірено напряму - fill="white") навмисно створена
   світлою, бо власний фон кнопки - var(--color-black-100)
   - завжди темний у кожному попередньому режимі. Але цей токен ПЕРЕВЕРТАЄТЬСЯ під wb (за
   задумом, деінде це саме те виправлення, що нам потрібне), тож тут він перевертає єдиний
   фон, який ніколи не мав рухатись, і біла іконка на тепер
   майже білій кнопці зникає. Звичайний invert(1) (а не brightness(0) invert(1),
   що примусив би білий - протилежне тому, що тут потрібно) робить
   уже плоско-білу іконку чорною, що відповідає новому світлому
   фону кнопки. Один голий селектор `.pag-btn img` покриває всі три виклики,
   бо цей клас ні для чого іншого не використовується. */
html.a11y-contrast-wb .pag-btn img {
    filter: invert(1);
}

/* Залишкові місця в legal-pages.css поза секцією хаба, вже виправленою
   вище: нижня рамка мобільного сайдбару (сирий #ebedf2, лишається світлою
   на тепер темному сайдбарі нижче 992px), колір посилання "reset" у формі
   повідомлення про порушення (сирий #06ba52 - ледь читабельний був нормально на білому, але
   під wb скрізь деінде цей самий акцент приглушується до сірого саме тому, що
   сирий зелений на чорному не дотягує до контрасту, якого
   досягає приглушений сірий, за коментарем таблиці токенів wb вище), і - знайдено після
   звіту користувача, пропущено в попередньому проході, бо вкладено на два рівні
   глибше, ніж уже виправлені пункти верхнього рівня .icon-wrapper сайдбару, -
   власні підпункти акордеона (.children ul li a): сирий базовий колір #221f1f
   лежить прямо на власному фоні сторінки (без власного боксу, на відміну від
   пунктів верхнього рівня), тож під wb він став темним-на-тепер-чорному, а його
   стан current/hover має ту саму проблему сирого зеленого на чорному, що й
   reset-form-btn вище. */
html.a11y-contrast-wb .legal-sidebar { border-bottom-color: var(--color-grey-40); }
html.a11y-contrast-wb .legal-page article .form-unacceptable-behavior .reset-form-btn { color: var(--color-green-100); }
html.a11y-contrast-wb .legal-sidebar .nav-list .children ul li a { color: var(--color-black-100); }
html.a11y-contrast-wb .legal-sidebar .nav-list .children ul li a.current,
html.a11y-contrast-wb .legal-sidebar .nav-list .children ul li a:hover { color: var(--color-green-100); }
/* Той самий розрив data-URI шеврона has-child, що й в ідентичному патерні .kb-sidebar вище -
   fill='%23221F1F', вшитий у саме значення background: url("data:image/svg+xml,...")
   недосяжний для токена, хоч би наскільки токенізованою була
   решта файлу. */
html.a11y-contrast-wb .legal-sidebar .nav-list li.has-child > a:after {
    filter: brightness(0) invert(1);
}

/* Кнопка відправки форми need-support у /contacts/ (template_contacts-v4.php) - це
   звичайний .btn без модифікатора кольору - зелений фон / білий текст у bw, через
   базове правило .btn у style.css. Під wb флип акцентного токена (--color-green-100
   → #9a9a9a) перетворює її на кнопку середнього сірого, яка виглядає достатньо читабельно на
   власному тепер чорному фоні панелі (--color-white у .contacts-v4-form перевертається на
   чорний так само, як усюди), але вже не читається як чіткий білий CTA,
   який мала б передбачати вся тепер інвертована в чорно-біле обробка панелі.
   Фіксуємо її на вже перевернуту пару самої панелі замість акцентного сірого -
   var(--color-black)/var(--color-white) - це літеральна інверсія базових токенів
   (#ffffff/#000000 під wb), а не вручну підібрана акцентна шкала, тож це читається як
   справжня біла кнопка з чорним текстом незалежно від режиму контрасту. */
html.a11y-contrast-wb .contacts-v4-form .submit-btn {
    background: var(--color-black);
    border-color: var(--color-black);
    color: var(--color-white);
}
html.a11y-contrast-wb .contacts-v4-form .submit-btn:hover {
    background: var(--color-black-60);
    border-color: var(--color-black-60);
}
html.a11y-contrast-wb .contacts-v4-form .submit-btn:active {
    background: var(--color-black-40);
    border-color: var(--color-black-40);
}
/* </editor-fold> */