AIA Form A Jotform styling and conditional-button guide

This directory contains the nonproduction visual handoff for the new AIA Form A. aia-form-a.css is intended for Jotform Classic Forms' Form Designer → Styles → Inject Custom CSS after the form is created and its settings are approved.

The CSS translates the existing AIA form treatment: Rubik typography, blue labels and text, #fcf9f5 inputs with #edeef3 borders, the #ffbd59 filled button, the #ff914d hover/focus border, four-pixel corners, visible validation errors, and strong keyboard focus. The Astro page supplies the heading, introduction, privacy-policy link, and surrounding card. The stylesheet therefore removes the Jotform surface rather than adding another header, footer, or nested card.

The selectors target Jotform Classic Forms identifiers such as #form, .form-all, .form-line, .form-label, .form-sub-label, .form-required, .form-textbox, .form-dropdown, .form-textarea, .form-error-message, and .form-submit-button. Jotform's final generated DOM must be checked in the account before relying on pixel-level parity. The stylesheet does not hide required indicators, error messages, honeypots, or focus outlines, and it does not request fonts or other external assets.

The current Builder theme reconciliation adds narrowly scoped !important declarations to the outer surface, labels, inputs, and submit-button treatments that Jotform's generated theme otherwise overrides. Error, required-indicator, and focus rules remain visible and are deliberately not reset. The account owner must still confirm the final generated DOM and rendered form after any Jotform theme or field change.

Installation and comparison

Open the approved Form A in AIA's HIPAA-enabled Jotform account. Do not change its fields or settings from this repository workflow.
Keep production activation disabled while embedded-runtime, accessibility, telemetry/privacy, and release review remain pending.
Paste the contents of aia-form-a.css into Jotform's custom CSS area.
Compare the Jotform preview with the Astro Form A mock at 390px and 1440px. Check the form surface, label rhythm, input height, button fill, outlined hover/focus state, error state, and mobile reflow.
Check both English and Spanish configurations. Confirm translated labels, required indicators, validation messages, confirmation copy, and the accessible iframe title supplied by the parent Astro integration.
Test the form in a real embedded iframe and on the direct hosted-form fallback. Confirm the iframe has a practical mobile height, does not create horizontal overflow, and does not trap keyboard focus.

The current Astro meeting preview remains off by default and can only be shown in a non-indexing mock build. It does not load Jotform and is not a live submission test.

Isolated Form A iframe adapter

The Astro adapter exists only for a separately approved, non-indexing isolated test. It can render Form A at the two contact routes and five explicitly allowlisted landing routes when all of the following are set at build time:

PUBLIC_AIA_FORMS_MODE=isolated-test
PUBLIC_AIA_FORMS_ENVIRONMENT=isolated-test
PUBLIC_AIA_FORMS_ISOLATED_TEST_APPROVED=true
PUBLIC_AIA_FORMS_LIVE_APPROVED=false
PUBLIC_ALLOW_INDEXING=false

It uses fixed allowlisted hosted URLs only: the contact routes use formContext=contact with their fixed English or Spanish language value, and the five landing routes use formContext=landing&language=en. formContext is the exact case-sensitive Jotform Unique Name supplied by the owner; it is presentation-only and does not accept visitor query values. In isolated-test mode, a missing gate, any other environment role, an indexing-enabled build or a route outside that seven-route allowlist renders the normal fail-closed Astro fallback. The separately documented live gate uses the same route allowlist and its own independent approvals.

Production-gated Form A adapter

The adapter remains off in normal builds. A production artifact may render Form A only when all four independent settings are present at build time:

PUBLIC_AIA_FORMS_MODE=live
PUBLIC_AIA_FORMS_LIVE_APPROVED=true
PUBLIC_AIA_FORMS_ENVIRONMENT=production
PUBLIC_AIA_FORM_A_PRODUCTION_APPROVED=true

PUBLIC_ALLOW_INDEXING=true is required for an indexing-enabled release artifact, but it is not a Form A authorization setting and cannot activate a frame by itself. The production gate preserves the same fixed seven-route allowlist, URLs, formContext, locale parameters, fixed heights, sandbox, no-referrer policy and conditional fallback. It does not enable future Form C, service drawers, native POST forms, analytics, advertising, tracking, webhooks, API forwarding or the Jotform resize handler.

For a deployment rollback, set PUBLIC_AIA_FORMS_MODE=off or remove any one of the three approval/environment values, rebuild the static artifact, verify no Form A identifier is emitted, and switch to the reviewed artifact. This disables Form A in Astro without changing the static site or the Jotform account. Do not change Jotform notification recipients, fields or availability as part of that rollback.

The adapter has a localized iframe title, a fixed-height responsive frame, a no-referrer policy, a minimal sandbox, and a direct hosted-form fallback. The fallback is outside the iframe, initially hidden without layout space, revealed after a 15-second missing-load timeout, cleared on frame load or component disposal, and duplicated only as localized <noscript> content. A frame load cancels the timeout but is never treated as Jotform initialization, accepted submission, conversion, or proof that the cross-origin application is healthy. It loads no Jotform helper script, reads no iframe DOM, and installs no postMessage handler.

Direct-Jotform Form A synthetic EN/ES submission, native thank-you, conditional-email/language, generic staff notification, autoresponder delivery, fixed Reply-To, no-answer/no-PDF and no-webhook/integration evidence is owner-confirmed. The owner also reports successful synthetic submission and confirmation through the isolated Astro iframe on English contact, Spanish contact and one ABA landing placement. This establishes owner-reported Form A functional submission acceptance for the sampled routes; it does not replace final seven-route responsive/keyboard/accessibility acceptance, Jotform runtime/network and telemetry privacy review, deployment review or site-release authorization.

Landing-route extension — 2026-10-25 / 2026-10-26

The owner has extended this same isolated-test-only adapter to /lp/aba-therapy, /lp/aba-insurance, /lp/aba-ahcccs, /lp/aba-private-pay, and /lp/early-intervention. Those five English landing routes use the fixed URL parameter pair formContext=landing&language=en; the contact routes continue to use formContext=contact with their fixed page locale. This supersedes their earlier Form B mapping. Physical Form B is retired; other service-consultation journeys are planned Form A consultation targets and remain inactive.

The campaign adapter uses the existing campaign form surface rather than creating a second card. Its native Jotform Submit label is not overridden by Astro. The current sandbox is deliberately limited to allow-forms allow-scripts allow-same-origin, which is the minimum anticipated set for Jotform validation and in-frame confirmation. It intentionally does not grant popups, modals, top navigation, downloads, or a feature-policy allow list. Owner-authorized synthetic acceptance must confirm the real form's validation, confirmation, and any required in-frame navigation before this sandbox can be accepted for production.

The versioned P9-03 contract and implementation plan must record this owner decision and reconcile the superseded campaign mapping without erasing the prior decision history. Keep any documentation PR review aligned with those versioned records.

Form context and button labels

The current Form A design uses a hidden formContext value with fixed, approved values such as contact and landing. Jotform does not provide a native conditional rule that changes one Submit button's accessible label safely in every context. If owner-approved context-specific labels are required, use multiple native Jotform Submit buttons and Jotform's conditional visibility rules:

Add one native Submit button for each approved context/language label.
Show exactly one intended Submit button for the current, validated formContext.
Keep every button a real Jotform Submit control; do not use CSS ::before/::after text as a label.
Verify that every visible variant submits through the same approved form and preserves the honeypot and validation behavior.
Make the no-context and invalid-context states fail closed: no ambiguous extra button and no unintended submission path.
Verify keyboard order, focus visibility, screen-reader names, English/Spanish labels, and mobile layout for every variant.

The owner-approved Form A landing extension applies only to /lp/aba-therapy, /lp/aba-insurance, /lp/aba-ahcccs, /lp/aba-private-pay, and /lp/early-intervention, using its fixed landing context under the isolated-test gate. Physical Form B is retired; a planned Form A consultation context requires separate Builder approval, synthetic acceptance and an allowlist change before it can appear on other service-consultation journeys. No Form A landing placement is approved for live production activation. Do not add an external Astro button that attempts to submit a cross-origin iframe.

Verification checklist

Direct English/Spanish Form A language handling, conditional email requirement, synthetic submission and native thank-you were owner-verified; this is not embedded-iframe acceptance.
Direct staff-notification/autoresponder delivery, generic no-answer/no-PDF content, fixed Reply-To, recipient access/retention, and absent webhooks/integrations were owner-verified for Form A.
Exact remaining Form A consultation question properties, choices, conditional routing and availability, plus future Form C configuration, are approved.
English and Spanish embedded-iframe labels, validation, confirmation, and button variants are reviewed by fluent-language owners.
The hidden honeypot remains present, effective, and excluded from user-facing visual changes.
Exactly one native Submit button is visible for every valid context.
Invalid or missing context does not expose an unintended submission path.
No PHI-bearing answer, PDF, recipient, redirect, webhook, or HTTP POST forwarding is inherited without privacy/security approval.
Owner-reported embedded synthetic submission and confirmation passed on English contact, Spanish contact and one ABA landing placement; record the exact ABA path in the owner test log before release.
All seven placements have final responsive, keyboard, screen-reader and fluent-language acceptance, including timeout/fallback and error expansion.
Jotform runtime requests, telemetry and cross-origin failure behavior are reviewed with privacy/security owners.
No Jotform, Contabo, analytics, advertising, or production API request is made by off/mock builds.

JF-01 through JF-09, privacy/security review, operations approval, fluent-language review, and production activation remain pending. This guide does not authorize Jotform account changes or live integration.

2026-10-28 reconciliation

The current records supersede the earlier Form B mapping: all five named landing journeys use Form A under the seven-route isolated-test or separately approved production gate, and physical Form B is retired. Other service-consultation journeys are planned Form A consultation targets; this context is not configured or emitted. The two-form integration specification defines its fixed planning contract and the separate Form C referral work. The official Jotform JavaScript embed handler is conditionally acceptable pending targeted verification; it is not included in this adapter. Any future adoption must first verify its current source, origin and source-window validation, parent-page privileges, URL mutation, network requests, Firefox behavior and all supported error states. Fixed heights remain the current approved architecture until that review is separately accepted.