I took a very bold decision and built a new version of the site using Astro https://astro.build/. It was HTML-first. Javascript existed, in web components, but only to progressively-enhance a website that worked perfectly fine without it.

My logic was thus:

1. This is a public service
2. It should work on every machine possible
3. It should work when connections are poor
4. The forms must never lose data once it is entered

…

The results? When we launched, the number of people completing the form doubled. The analytics people didn’t even know where these users were coming from. Of course, your javascript-based analytics package doesn’t see the users you are bouncing because of javascript failures. It was a flood! We also saw my “keep a backend session, never lose user data” approach pay off. In one case, someone completed a form a month after starting it.

This is something I really wish more sites would take to heart.

I am fairly certain I am not alone in saying that my city government has a website for giving out appointments that does not load without JS and when I do enable JS and complete the rubbish form it fails with an ambiguous error on my desktop computer.

How can even governments, which are supposed to be accessible to everyone within the country manage to push for use of their digital tools but then completely mess them up what feels like every single time?

Ahead of any validation for forms should be input masks at every reasonable step.

Make sure that only numbers can be entered into a phone field, and with the correct pattern. Ensure that postal codes can only have numbers and letters, and the letters come in uppercase even if the user presses a lowercase letter. Have a date picker available, sure, but give people the option of just typing it out, and also make it clear that the format will be ISO-8601.

Well thought out input masks provide proactive correction and can massively help avoid reactive validation that only comes up after the user leaves the field or submits the form.