I was working on a small WordPress site and needed a simple way for visitors to get in touch.
Nothing fancy. No page builders. No complex forms.
Just a clean contact button that stays visible and opens a form when clicked.
I started looking at existing contact form plugins and quickly realized most of them were solving a much bigger problem than I had. Drag-and-drop builders, dozens of options, external scripts, and settings pages that felt heavier than the site itself.
All I wanted was a lightweight, accessible way for someone to send a message.
So I built Zontact for myself.
After using it on the site, I realized others might be running into the same problem. That’s when I decided to clean it up, document it properly, and submit it to the WordPress plugin directory so anyone could try it.
This post is about why I did that and what I learned along the way.
The Real Problem Isn’t Contact Forms
Every website needs communication.
But not every website needs a form builder.
Somewhere along the way, “contact form” became synonymous with:
Drag-and-drop editors
Multi-step workflows
External services
Heavy JavaScript bundles
But for a small business website, portfolio, or brochure site?
It’s usually unnecessary.
Most of the time, the goal is simple:
Let someone send me a message without friction
That’s it.
And yet, many contact solutions introduce more friction than they remove, both for site owners and visitors.
Overengineering Hurts More Than It Helps
While researching plugins, I noticed a common pattern:
- The form loads on every page
- Scripts are included even when unused
- Accessibility is bolted on later (if at all)
- Settings overwhelm users who just want a working solution
This leads to:
- Slower page loads
- More things to break
- Poor keyboard and screen reader experiences
- Increased maintenance over time
Ironically, all of this is often done in the name of “flexibility.”
But flexibility comes at a cost.
Why a Floating Contact Button Makes Sense
Instead of a full-page form or embedded block, I started thinking about visibility and intent.
When do users actually want to contact you?
Usually when:
- They have a question
- They’re ready to take action
- They don’t want to hunt for a “Contact” page
A floating contact button solves this well:
- It’s always visible
- It doesn’t interrupt the experience
- It’s easy to ignore if not needed
When clicked, it opens a modal, keeping users on the same page and reducing friction.
The key, though, is execution.
Accessibility Isn’t Optional
Modals are notoriously bad for accessibility when implemented poorly.
Common issues include:
- Focus on not being trapped
- Keyboard users are unable to close the modal
- Screen readers not announcing context changes
- Poor ARIA roles or none at all
I didn’t want to ship something that looked simple but excluded users.
So accessibility became a core requirement from day one:
- Proper ARIA attributes
- Keyboard navigation
- Focus management when opening and closing
- Semantic HTML structure
This wasn’t about compliance checklists; it was about building something that works for everyone.
Performance Matters More Than Features
Another thing I noticed while testing plugins was how much code was loaded for simple use cases.
Even when:
- Only one form existed
- No advanced features were enabled
- The plugin wasn’t actively used on a page
The site still paid the cost.
I wanted the opposite:
- Minimal assets
- No external dependencies
- Load only what’s needed
A contact solution shouldn’t noticeably impact performance, and it definitely shouldn’t be the slowest part of the page.
Building the Solution I Actually Needed
So I built a small plugin with a very narrow scope:
- One floating contact button
- One accessible modal
- One contact form
- Email notifications
- Optional message storage
That’s it.
No page builders.
No third-party APIs.
No feature sprawl.
The goal wasn’t to compete with form builders.
It was to avoid becoming one.
Keeping Configuration Simple
Another thing I paid attention to was the admin experience.
I’ve seen plugins where:
- The settings page is more complex than the frontend
- Options exist “just in case” someone needs them
- Users are afraid to touch anything
For Zontact, the defaults had to work out of the box.
Configuration focuses on:
- Button position
- Basic styling
- Enabling or disabling the button entirely
If someone installs and activates Zontact and never opens the settings page, it should still work and look good.
From Personal Tool to WordPress Plugin
After using Zontact on my own site for a while, a realization hit me:
I couldn’t find anything that did just this cleanly, accessibly, and without extra baggage.
So instead of keeping Zontact private, I decided to:
- Clean up the code
- Follow WordPress best practices
- Add translations support
- Document it properly
- Submit it to WordPress.org
Not as a “next big plugin,” but as a small, focused tool for people with the same problem.
Intentional Simplicity Going Forward
One thing I’m very conscious of is feature creep.
More features aren’t inherently bad but they need to earn their place.
Any future improvements should:
- Solve a real problem
- Preserve performance
- Maintain accessibility
- Keep the plugin easy to understand
If adding something makes the plugin harder to explain, it’s probably the wrong addition.
Final Thoughts
Not every problem needs a platform.
Sometimes, the best solution is a small tool that does one thing well.
If you’re building or maintaining WordPress sites and need a simple, accessible way for visitors to get in touch, that’s the gap I was trying to fill.
The plugin is called Zontact.
It’s free, open source, and available on WordPress.org if you want to try it or explore how it’s built.

Top comments (0)