About

Hi, I'm Pete.
Here's the longer version.

UI developer. Design systems engineer. I notice when a tab order is wrong, a button label is dishonest, a form doesn't work for screen readers. Building for the web since 1994. Still here because it still matters.

Get in touch Testimonials
Role UI developer & design systems engineer
Based in Ocala, Florida
In the craft 30+ years
Peter Benoit

01 · How I'm wired

Two things I can't seem to switch off.

The thing I can't turn off

There's a pattern I notice everywhere. A typo on a restaurant menu. A page that's two pixels off from its mockup in a way nobody else mentioned. A speech rhythm that doesn't match someone's affect. It isn't a skill I developed. It's just how things land.

It makes me very useful in some jobs, and mildly annoying to watch movies with.

I've spent most of my career in the interface layer partly because there's something honest about that boundary. A bad tab order, a loading state that lies, a button that says "submit" when it means "save." I notice them. And if I can, I fix them.

I fix things by building

When something bothers me enough, I build the fix rather than live with the problem. Not as a startup idea, not as a portfolio piece. Just because staying annoyed felt worse than spending a weekend on a solution.

That's where most of my open-source tools came from. A workflow that wasted a few clicks. An accessibility check I kept doing by hand. A small thing I do every day that nobody had bothered to automate yet.

The artifacts are usually small. The habit is just how I'm wired.

Small things accumulate into trust; or the quiet erosion of it.
The whole job, more or less

02 · The long version

Twenty-some years, abbreviated.

Table layouts to federal health infrastructure. Open source in the margins.

  1. Late '90s

    The table-layout years

    Put my first HTML page up in 1994. Freelanced through the browser wars, built sites for local businesses, then agencies. Learned that browser disagreement is a useful kind of pessimism that never really left.

  2. 2000s

    Agency work and learning to ship

    Years in the trenches turning other people's designs into working interfaces. Where the pixel-level eye got trained, and where I learned that the gap between a comp and a shipped page is where most of the real work lives.

    Drupal CSS
  3. 2010s

    Design systems and accessibility

    Moved into design systems work when "component library" became a real job. Picked up Vue. Got interested in accessibility after watching a screen reader session on a form I built. It wasn't pretty.

    Vue Accessibility Component systems
  4. Federal

    CDC.gov, from scratch

    Stood up the CDC.gov design system from nothing, scaled it across 200+ page templates, and drove Section 508 compliance to 100% across federal health infrastructure.

    USWDS Section 508 Design systems
  5. Federal · ongoing

    The VA and resilient interfaces

    Accessible, resilient interfaces for the people who depend on federal health systems. The stakes are higher and the constraints are real, which is exactly why the details matter more.

    Accessibility React VADS
  6. Nights & weekends

    30+ open-source tools

    The steady undercurrent through all of it. Small, sharp, mostly zero-dependency tools for the open web. Built because I needed them, then left out for anyone who needs the same.

    Vanilla JS npm

03 · Craft

What I've stopped arguing about.

Experience settles some things. Here are the ones experience settled for me.

Accessibility isn't a checklist item or a layer you add at the end. It's a starting condition. If a form doesn't work with a keyboard, the form is broken. That's not a metaphor. That's a user who couldn't complete their task.

Federal work sharpened this. When your interface is used by people who can't always choose their own tools, you stop treating accommodations as optional. A bad tab order on a disease-surveillance dashboard used during an outbreak isn't a UX footnote. It's a failure.

Dependencies are a decision, not a default. Every npm package you pull in is a decision you're making on behalf of every person who maintains the codebase after you. That's worth treating seriously.

Things I've stopped questioning

  • Vanilla before a framework. Always check what the browser already does.
  • Accessibility first, not accessibility last.
  • A dependency is a liability with a package.json entry.
  • If the tab order is wrong, the interface is wrong.
  • The best loading state is not needing one.
  • Performance is accessibility for people on bad connections.

04 · Off the clock

When I'm not at a keyboard, I'm probably on a back road.

I moved to Ocala a few years ago and decided to actually pay attention to where I landed. Florida's interior is nothing like the beach version people imagine. There are spring-fed rivers in colors that look wrong in photographs. Flatwoods that go on until they don't. Old-growth scrub that most of the state has already lost.

I spend a lot of time on back roads and trails with my dog Bowie, who is large, decisive, and only mildly impressed by the places I pick. He has opinions about water crossings. I carry a Lumix G9 II. I've been writing about some of the trails, partly to practice noticing things more carefully.

I also read more history and biology than you'd expect from someone who spends his days in DevTools. Systems that fail, and why. The overlap with broken interfaces is bigger than it looks.

Hiking Photography Birds, apparently Ocala, FL Reading
Pete on a Florida trail somewhere off US-441

Thanks for reading this far.

Type Bitter & Hanken Grotesk
Built with Hand-written HTML & CSS
Where Ocala, Florida