47 lines
4.8 KiB
Markdown
47 lines
4.8 KiB
Markdown
# 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`](./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.
|