/**
 * KAB'S OWN BUTTON TREATMENT FOR FORMASSEMBLY'S SUBMIT CONTROLS.
 *
 * Hand-written and OURS — the only file in `public/vendor/` that is not generated.
 * `formassembly.css` beside it is FA's three sheets scoped by `fa:sync-css`; this
 * one overrides a handful of its declarations and nothing else.
 *
 * ── WHY IT EXISTS ───────────────────────────────────────────────────────────────
 * FA's vendor theme paints its submit button `#3aad73` with a `#ffffff` label at
 * 12.96px bold: 2.83:1, measured by axe in a real browser on 2026-09-10, against
 * the 4.5:1 that size requires. It is the control a reader presses to receive the
 * 2020 Litter Study report, so the failing element is the entire point of the band.
 * `#3aad73` is NOT a KAB brand value — it is absent from `tokens.css`,
 * `design-context.ts` and DESIGN.md, and appears only in FA's own `theme-31.css` —
 * so the standing rule about implementing the brand verbatim and never moving a
 * brand value to pass a contrast test has nothing here to protect. The client
 * instruction points the same way: the inline forms should take the place of the
 * native forms as far as styling.
 *
 * ── WHY TOKENS RATHER THAN A DARKER GREEN ───────────────────────────────────────
 * Darkening the vendor hex until it clears 4.5:1 fixes one button by tuning one
 * value, and the next synced form ships the defect again. Reading the surface CTA
 * tokens instead makes the button pass BY CONSTRUCTION: every `.kab-surface-*`
 * declares an already-accessible CTA pairing, so the control inherits whichever
 * ground its band sits on and cannot land on an unreviewed combination. On the
 * default surface that is Bright Green with a Dark Green label (4.80:1, the book's
 * own approved pairing, p.38) — the same paint as the Donate pill.
 *
 * ⚠ THE HOVER MUST RESTATE THE LABEL COLOUR. FA's theme sets `color:#fff` on
 * `:hover`, and `--surface-cta-primary-hover` LIGHTENS the fill by design (see the
 * token's own note: darkening drives the Dark Green label to 3.22:1). White on the
 * lightened fill would be a new AA failure introduced by the fix, so the hover rule
 * below re-asserts `--surface-cta-primary-text` rather than inheriting FA's white.
 *
 * ── WHY THE SCOPE CLASS IS DOUBLED ──────────────────────────────────────────────
 * `.fa-embed.fa-embed` is one element matched twice: identical to `.fa-embed` in
 * what it selects, one class higher in specificity. The vendor rule is
 * `.fa-embed .wFormContainer .actions .primaryAction` (0,4,0) and its `:hover` is
 * (0,5,0); doubling puts these at (0,5,0) and (0,6,0) so they win WITHOUT depending
 * on which `<link>` the browser resolves last. `fa-embed.tsx` declares this sheet
 * after the vendor one and with its own `precedence` ("fa-kab-controls", so React
 * orders the group after "fa-vendor") — but a containment argument resting on order
 * alone is one React change away from silently inverting, and this defect is too
 * expensive to re-earn.
 *
 * ⚠ `precedence` ON THIS SHEET IS LOAD-BEARING, NOT TIDINESS. A plain `<link>` is
 * applied ASYNCHRONOUSLY: measured on the branch on 2026-09-11, the vendor sheet was
 * in the DOM with `.sheet` still null on the second and third FaEmbed mount, and the
 * submit control computed `rgba(0,0,0,0)` at 16px/400 — so axe read a button wearing
 * none of the CSS a reader is served and PASSED it, which is why this defect reported
 * on two stories when six carried it. An override sheet shipped as a plain link would
 * reopen that identical gap on the fix itself: not loaded when the control is read is
 * indistinguishable from not written.
 *
 * ── WHAT IS DELIBERATELY NOT RESTYLED ───────────────────────────────────────────
 * `.wfTab` (the multipage progress chip) and `input[type="file"]`'s upload button
 * carry the same `#3aad73`/`#ffffff` pair and the same failure. Neither is touched
 * here, and neither is reachable today: all three synced forms (80, 83, 196) render
 * a single `primaryAction` and no tabs, paging or file input. Restyling a progress
 * indicator is a different design decision from giving a button the button
 * treatment, and it should be made when a form that has one is actually synced. The
 * paging buttons ARE covered below — same affordance, same hex, so a multipage sync
 * cannot reintroduce the defect through a door left open.
 */

.fa-embed.fa-embed .wFormContainer .actions .primaryAction,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPageNextButton,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPagePreviousButton {
  background-color: var(--surface-cta-primary);
  color: var(--surface-cta-primary-text);
  border: none;
  border-radius: var(--radius-pill);
  /* 12.96px bold was below our own body rung and below the 44px thumb target the
     ActionLink pill is cut to. 1rem with this inset draws a 44px control. */
  font-size: 1rem;
  min-height: 44px;
  padding: 0.625rem 1.75rem;
  transition:
    background-color 150ms ease-out,
    color 150ms ease-out;
}

.fa-embed.fa-embed .wFormContainer .actions .primaryAction:hover,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPageNextButton:hover,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPagePreviousButton:hover {
  background-color: var(--surface-cta-primary-hover);
  color: var(--surface-cta-primary-text);
}

/* FA's theme draws no focus indicator on these at all. 2px at a 2px offset in the
   surface's own ring token — the same ring Button and ActionLink use. */
.fa-embed.fa-embed .wFormContainer .actions .primaryAction:focus-visible,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPageNextButton:focus-visible,
.fa-embed.fa-embed .wFormContainer .wfPagingButtons .wfPagePreviousButton:focus-visible {
  outline: 2px solid var(--surface-focus-ring);
  outline-offset: 2px;
}

/* Disabled is exempt from 1.4.3, so the vendor's own grey is left alone — only the
   shape is carried across so a disabled control is still recognisably this button. */
.fa-embed.fa-embed .wFormContainer .actions .primaryAction:disabled {
  border-radius: var(--radius-pill);
}