EDS for Forms

EDS extends the same edge-delivery model to Adaptive Forms. Authors compose forms in AEM Forms or in a document, and EDS renders them as fast, accessible, semantic HTML served from the CDN. The form runtime is just another block.

Two authoring paths

Document-based forms

Author a form as a table - one row per field. The form block converts it into a semantic <form>:

| Form                    |          |          |
|-------------------------|----------|----------|
| Field type | Label      | Name     | Required |
| text       | First name | first    | true     |
| text       | Last name  | last     | true     |
| email      | Email      | email    | true     |
| select     | Country    | country |          |
| submit     | Subscribe  |          |          |

The first row is the block name (and optional variations). Subsequent rows describe the fields. The form block in aem-boilerplate-blocks ships a working reference implementation.

Adaptive Forms (AEM Forms)

For complex forms - multi-step flows, conditional fields, server-side validation -- authors use the AEM Forms authoring UI. The form definition is rendered into the EDS pipeline via the Adaptive Forms block. EDS handles delivery and accessibility; AEM Forms handles validation rules, drafts, and submission storage.

This requires an AEM Forms entitlement.

The form block

Whichever authoring path you pick, the runtime side is the form block. Like any EDS block, it's a folder of JS + CSS:

/blocks/form/
    form.js
    form.css
    form-fields.js
    form-validation.js
    form-submit.js

Responsibilities split across the helper modules:

• form.js - decoration entry point: read fields, build <form>, wire submit
• form-fields.js - render input types (text, email, select, radio, checkbox, textarea, file, date)
• form-validation.js - client-side validation, ARIA error wiring
• form-submit.js - collect values, post to the configured endpoint, handle success / error UI

Submission targets

The form block reads a target URL from a submit row or a meta tag. Common targets:

Target	Use case
AEM Forms endpoint	Stores the submission in AEM, runs server-side validation, optionally fires a workflow
External REST API	Anything else - CRM, marketing automation, custom backend
SharePoint list	For internal forms, store directly in a SharePoint list
Email	Via a serverless function or mailto: action
Webhook	For lightweight integrations (Slack, Teams, custom)

A typical submit row in a document-based form:

| submit | Subscribe | endpoint=/api/subscribe |

Read the endpoint with readBlockConfig and POST JSON:

blocks/form/form-submit.js

export async function submit(form, endpoint) {
    const data = Object.fromEntries(new FormData(form).entries());
    const res = await fetch(endpoint, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(data),
    });
    if (!res.ok) throw new Error(`Submit failed: ${res.status}`);
    return res.json();
}

Validation

Client-side validation uses the HTML constraint API plus ARIA wiring:

<input type="email" name="email" required aria-describedby="email-error">
<p id="email-error" class="form-error" hidden>Please enter a valid email address.</p>

For server-side validation (especially with AEM Forms), the submit endpoint returns a structured error response that the block displays inline.

Spam and abuse

Edge delivery means the form is very fast to load - attackers will find it. Pick at least one of:

• CAPTCHA - reCAPTCHA, Cloudflare Turnstile, hCaptcha. Render in delayed.js to keep LCP clean.
• Honeypot field - an <input> hidden with CSS that humans never fill but bots often do.
• Time check - record the load timestamp; reject submissions submitted faster than a human plausibly could.
• Rate limit at the CDN - limit requests per IP at the edge.

Accessibility

The form block is tested with screen readers. Keep these invariants when customising:

• Every input has a programmatically associated <label> (use for/id or wrap)
• Required fields use both required and aria-required="true"
• Errors use aria-describedby and role="alert"
• Submit buttons have a clear, unique label
• Focus is visible (don't strip :focus-visible outlines)

Common patterns

Multi-step form

The block reads step rows that group fields:

| step | personal-details |
| text | First name | first |
| text | Last name  | last  |
| step | preferences      |
| select | Topic | topic |

JS hides steps after the current one and wires Next / Previous buttons.

File upload to AEM Assets

For document upload forms, post the file to a backend that then forwards to AEM Assets via direct binary upload (AEM's own direct-binary upload flow is meant for authenticated author-side clients, not anonymous public forms). Never expose your Assets API credentials in the browser - have the backend either proxy the upload itself, or issue an application-owned upload URL that is authenticated, authorized, single-use, restricted to an allow-listed asset root, bound to the authenticated principal and the specific target asset/upload constraints (size, MIME type) it was issued for, and short-lived (a TTL of minutes, not hours). Either way, the backend must independently validate file size, MIME type, actual content, and filename/path before forwarding to AEM, apply rate limiting and malware scanning, and use an AEM service credential scoped to the minimum permissions needed (write access to the target DAM folder only).

Save draft

For long forms, persist values to localStorage after each change so a refresh doesn't lose work:

form.addEventListener('input', () => {
    const data = Object.fromEntries(new FormData(form).entries());
    localStorage.setItem(`form-draft:${form.dataset.id}`, JSON.stringify(data));
});

Clear the draft on successful submit.

See also

• Blocks - the form block follows normal block conventions
• Customizing - response headers (CSP) for form submissions
• aem.live: forms documentation
• Adobe docs: EDS for Forms