Best contact blocks 2026: 33 verified sections

A contact block is a form with an address beside it, and it is rarely complete. The catalogue counts 33 from 10 registries, measured on 1 November 2026 on /api/blocks/category/contact: ten different publishers are the most important number in the table.

What fails in a contact form

The first defect shows up at once in production: the form submits, the page shows a success message and the email reaches nowhere, because the block is interface only. The second concerns errors: a required field marked only by a red border tells a screen reader nothing about what is missing, and without aria-describedby the error text is not tied to its field.

The third is privacy. A form asking for name, email and message without an explicit consent box, and without the notice linked, is a problem before it is a design flaw. The fourth is spam: none of these blocks includes a honeypot or a rate check, and a public form with no defences collects bots within days.

Five things to verify in the record

• The file count: the five-file block splits the form, the information panel and the map, the others are one section.
• Whether the form is an isolated component, so you can reuse it on another page without copying the layout.
• Whether fields carry an associated label, autocomplete and an error message with an identifier.
• Whether a submit action is declared, or the button is a type=submit with no handler.
• The publisher licence, which in this category is the widest variable in the catalogue.

The map deserves its own paragraph. An embedded iframe brings third-party cookies, weighs on page speed and often has no accessible title. If the address is already written as text, a static map image linking to the real map does the same job for far less, in bytes and in compliance.

The limitation left outside the catalogue

None of the 33 blocks delivers the message. There is no endpoint, no queue, no confirmation to the user that the request was recorded. The second limitation is the licence declared by the publisher, which covers the markup and not the integration with your mail service or CRM: you pick that, and you pick it once for every form on the site.

The rule that decides in two minutes

If the form is the page's only conversion, take the five-file block with the form split from the information panel: you get a component to test and reuse on the support page. If the form lives in the footer, the single-file section is enough and you should cut it to two fields. Either way consent and spam defence are yours, and they belong before the button, not after.

The alternative is a hosted form service. It gives up typographic control and gains spam handling, notifications and a request history with no code. A block pays off when the form must match the rest of the site and the data must stay in your database; it does not pay off when the only thing that matters is that the message arrives.

Confirmation remains. After submit the form must say three things: that the message left, when a reply will arrive and which address to answer. A block showing only the word thanks leaves the user unsure whether it worked. When the form includes an email field, that same address belongs in the reply-to of your notification: two lines of code that change the tone of the whole conversation.

curl "https://ui.eneawork.it/api/blocks/category/contact?limit=10"

The sections are in /blocks/category/contact, the fields in /components/cat/form and contact icons in /icons. For the technical side read a react-hook-form form and the accessibility checklist; the comparison between copying the block and using a headless primitive is in copy-paste or headless.