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 totally 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 (they aren’t any good):
Reason 1: Trauma
Okay that’s a bit 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 (if you can’t beat em, join em).
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 (I’m still not particularly good).
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 deep down they didn’t work well (at least for some users).
So yes: it’s a sh*t reason but I did tell 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 easy.
Now I could still use JavaScript in the browser to show error messages but it’s bad to rely on JavaScript for something that can work without it (like validation).
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.
(Feel free to message me with a tutorial about how to use a serverless function to render server side errors using Nunjucks)
Reason 3: Inertia
There’s a famous proverb that says:
The shoemaker’s children go barefoot
Okay, it’s not that famous, I had to google it.
But the point is that I spend most of the day doing client work (the stuff that pays my bills). Which means, my website is a little more neglected than I’d like it to.
All of that said, I’ve fixed the contrast issues, thanks to Crystal’s reminder.
Here’s how it looks now:
Sometimes you just need to be reminded to practice what you preach.
If you need a reminder about how to practice what I preach (and design forms that users fly through using research-backed design patterns):