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

Create or open the approved blank Form A in AIA's HIPAA-enabled Jotform account.
Keep the form disabled while field, PHI, notification, conditional-logic, and language review is 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_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. A missing gate, any other environment role, an indexing-enabled build, a route outside that seven-route allowlist, or live mode renders the normal fail-closed Astro fallback instead.

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. It loads no Jotform helper script, reads no iframe DOM, and treats no frame load as a submission or conversion. The disabled Form A must undergo owner-authorized synthetic EN/ES testing before the isolated adapter or its fixed height can be accepted for a live workflow.

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. Form B remains for the other service-consultation journeys.

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. Form B remains the planned form for the 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

Form A is disabled while configuration is reviewed.
Exact question types, required flags, choices, conditional logic, and formContext values are approved.
English and Spanish 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.
The iframe title, loading/error state, keyboard behavior, and mobile height are accepted.
Synthetic testing uses only approved synthetic values and a separately authorized test form.
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.

8.2 KiB Raw Blame History