aia-website/www/integrations/jotform/README.md

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.

Installation and comparison

1. Create or open the approved blank Form A in AIA's HIPAA-enabled Jotform account.
2. Keep the form disabled while field, PHI, notification, conditional-logic, and language review is pending.
3. Paste the contents of aia-form-a.css into Jotform's custom CSS area.
4. 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.
5. 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.
6. 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.

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 four campaign pages remain mapped to Form B in the production architecture. Their current Form A mock override is temporary meeting-preview behavior only. 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.