From paper to a live, encrypted web form in an afternoon
Web forms shouldn't mean a developer, a database and a fortnight. Here's how to turn a form into a published, accessible, encrypted web form — and what to look for so you're not leaking data.
Most organisations still collect information the slow way: a PDF emailed back and forth, a printout posted in, a spreadsheet someone retypes by hand. It works, sort of, until it doesn't — until a referral gets missed in an inbox or a sensitive form sits unencrypted in a shared drive.
A web form fixes most of that. The catch has always been that "build a web form" traditionally meant a developer, a database, hosting, and a conversation about GDPR nobody enjoyed. It doesn't have to.
What a web form should actually give you
It's easy to be dazzled by a form that looks nice. The things that matter are mostly underneath:
Accessibility built in
Visible labels properly associated with their fields, sensible focus order, error messages that screen readers announce, and contrast that passes. If a form excludes the people you serve, it's failed before it's collected a single response.
Encryption of submissions
When someone submits personal data, it should be encrypted at rest. If your form tool stores responses in plain text, anyone with database access can read them.
Control over the data
Where it's stored, how long it's retained, and the ability to export or delete it. Bonus points for data residency you can name.
Notifications that fit your workflow
For a time-sensitive referral form, waiting for someone to log in and check isn't good enough — you want to know when something lands.
The accessibility part isn't optional
It's tempting to treat accessibility as polish you add later. For web forms it's the opposite — it's the foundation, and it's a legal expectation for a lot of UK organisations under the Equality Act and, for the public sector, the accessibility regulations.
The most common own goal
Hiding field labels to make a form look "clean", then relying on placeholder text. Placeholders vanish when you start typing, fail contrast, and aren't reliably read by assistive technology. Keep your labels visible.
The encouraging news is that an accessible form is also just a clearer form — visible labels, good contrast and sensible error messages help everyone, not only people using assistive technology. Accessibility and usability pull in the same direction.
How it works in FormGenius
The same form you design on the canvas can be published as a live web form — no separate build, no developer. When you publish, you get a hosted form at its own URL (or embedded on your own site with a single script tag), rendered to WCAG 2.2 AA.
Behind it, submissions are encrypted at rest with AES-256-GCM, per form. The data is hosted in London (AWS eu-west-2), you can set auto-delete retention windows, export to CSV whenever you need, and get email notifications — from an instant-ish hourly digest down to weekly — so referrals don't go stale in a queue.
The old way
Design a form, send the PDF, hope it comes back, retype the answers into a spreadsheet, store it... somewhere. No encryption, no audit trail, no accessibility guarantee.
Published web form
One accessible form, a live URL, encrypted submissions in a dashboard, CSV export, retention you control, and a notification the moment something arrives.
You're not trading accessibility or data protection for convenience — you're getting all three at once, which is rather the point.
Collecting referrals, applications or feedback? See how accessible, encrypted web forms work for public sector and third sector teams.
See FormGenius for the public sector
