This content originally appeared on Adam Silver and was authored by Adam Silver
Last Friday I received a message from Crystal, an accessibility engineer:
As you probably gleaned from my post I am building my contact page right now for my development agency. […]
I have actually heard about your Form Design Patterns book from a co manager of mine at the Accessibility Book Club but I have got to be honest with you…
I was really surprised when I went to your website and found your Newsletter signup form to be failing a few WCAG requirements like Non-text contrast on your borders and 3.3.1 Error Identification using HTML5 form validation leading to inadequate error identification and messaging.
Here’s how my form used to look:
Crystal is right.
If I saw the same form on someone else’s site I’d say the same thing.
So why did I design it this way?
I wish I could give you a good reason but instead I’ll just give you the actual reasons:
Reason 1: Trauma
Okay that’s dramatic but here’s the sitch:
I wasn’t always a designer.
I started out as a frontend developer.
Sadly, most of the designers I worked with gave me complicated and inaccessible designs to implement.
Sometimes I’d suggest changes to simplify the design and improve accessibility. But often, no matter how solid my rationale or how simple my solution, I couldn’t convince the designers to make changes.
Eventually I transitioned to design.
But there was a problem:
While I’ve always had an eye for aesthetics, I wasn’t the best at actually creating a beautiful aesthetic (it’s still not my main focus as a designer).
So when I designed my personal website, I wanted potential clients to look at my site and like how it looked. I wanted it to look like a designer designed it, not a frontend developer.
As a result, I kept the low contrast borders that made the inputs look like they had depth, something I thought looked better but I always knew they were a risk to UX, at least for some users.
So yes: it’s a bad reason but I tol you it would be.
Reason 2: Technology
My website is built with 11ty which pre-builds static HTML.
This means I don’t have an application server to perform form validation checks. Perhaps someone out there knows how to do proper server side validation but whenever I’ve looked into it, it didn’t seem straightforward - perhaps a serverless function could work.
Now I could use client-side JavaScript in the browser to show error messages but it’s bad to rely on JavaScript for something that can work without it.
So I just did the lazy thing and used HTML5 validation which the browser provides for free.
HTML5 validation sucks for reasons such as Crystal mentioned.
I don’t recommend it in my course. I recommend a pattern I’ve been using since 2008, which is the simplest, most accessible way to help users recover from errors.
Reason 3: Inertia
There’s a famous proverb that says:
The shoemaker’s children go barefoot
It’s not that famous because I google’d it.
But the point is that I spend most of the day doing client work. So my website is a little more neglected than I’d like it to.
All of that said, I’ve now fixed the contrast issues.
Here’s how it looks now:
Sometimes you just need to be reminded to practice what you preach.
If you need a reminder to practice what I preach (and design forms that users fly through using research-backed design patterns):
This content originally appeared on Adam Silver and was authored by Adam Silver
Adam Silver | Sciencx (2025-03-16T00:00:00+00:00) Why my own sign-up form sucks. Retrieved from https://www.scien.cx/2025/03/16/why-my-own-sign-up-form-sucks/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.