Forms Required Fields: A Divi Guide to UX & Conversions

You’ve probably had this happen. A Divi form looks polished, the button copy is solid, the spacing is clean, and mobile layout checks out. Then the form underperforms anyway.

In most audits, the problem isn’t the design. It’s the forms required fields strategy hiding inside the form. Teams ask for too much, mark fields poorly, validate too late, and forget that a required field is a trust decision as much as a technical one.

That gets worse in WooCommerce and popup-driven flows. A field that feels harmless to the site owner can feel intrusive to a customer who just wanted a quote, a callback, or a faster checkout. The fix usually isn’t “make everything required.” It’s deciding what’s necessary right now, what can wait, and what should only appear when the user’s intent justifies it.

Why Your Required Fields Are Silently Killing Conversions

A common pattern shows up on Divi builds. The homepage offer is clear. The popup timing is reasonable. The form itself asks for name, email, phone, company, website, budget, industry, and project details. Technically, nothing is broken. Practically, the form is asking for commitment before the visitor has earned enough value to give it.

That’s where required fields start hurting conversions. Forms with 3–5 fields typically achieve the highest conversion rates, and each extra field adds friction, according to Jakob Nielsen’s usability guidance on required fields. The issue isn’t only effort. It’s privacy, uncertainty, and the fear that the form starts a bigger sales process than the user wants.

Phone number fields are where I see this most often. Site owners want them because sales wants them. Users hesitate because they assume a call is coming.

Practical rule: If a field creates anxiety, don’t make it required unless the next step genuinely depends on it.

The same trade-off shows up across ecommerce platforms. If you work across stacks and want another lens on checkout friction, this guide on how to modify your Shopify checkout page is useful because it frames form and checkout edits around reducing unnecessary blockers rather than just adding more data collection.

Poor required-field choices create quiet losses:

• More abandons: Users leave when the form feels longer or more invasive than expected.
• Lower quality intent: Some visitors enter fake values just to get through the form.
• Support friction: Teams get incomplete or unusable submissions because users guessed what you wanted.
• Bad attribution: Designers blame traffic or offer quality when the actual problem is field friction.

Required fields should protect the conversion path. Too often, they become the obstacle.

Setting Required Fields in the Divi Contact Form Module

The native Divi Contact Form module is enough for a lot of projects, but it needs deliberate setup. The “required” toggle is easy to find. The harder part is deciding which fields deserve that status.

Start with the field audit

Before touching settings, reduce the list. Don’t ask what your CRM would like to know. Ask what your next workflow step needs.

For a standard lead form, the true essentials are usually simple:

• Name: Useful if the team will reply personally.
• Email: Usually the actual required contact path.
• Message: Needed if the form is for support, quote requests, or project details.

Everything else should justify itself. Company name might matter for B2B routing. Phone might matter for callback requests. Budget often doesn’t belong in the first interaction unless you’ve already built enough trust.

How to mark a field as required in Divi

Inside the Divi builder:

1. Add a Contact Form module.
2. Open the module and edit an individual field.
3. In the field settings, turn on the Required Field option.
4. Save the field, then save the module and page.

That’s the mechanical part. Divi will handle the basic browser-side behavior and show its standard validation response when a required field is missing.

The problem is that default setup can still be unclear if labels, spacing, and field intent aren’t obvious.

Use visible cues, not guesses

Users shouldn’t have to submit the form to learn which fields matter. Marking required fields with asterisks is a proven usability best practice, and NN Group reports that forms clearly indicating required fields with an asterisk can reduce user errors and decrease abandonment by 20–30% compared to unlabeled forms in its required fields usability research.

A practical implementation in Divi looks like this:

• Add the asterisk directly in the field label, such as Email *.
• Add a short note above the form such as Fields marked * are required.
• Keep the note close to the form, not buried in body copy further up the page.

If you want more ideas on field structure, spacing, and practical Divi-specific improvements, these tips for better Divi forms are worth reviewing before you start custom code.

What Divi does well and where it falls short

Native Divi forms are fine for straightforward contact flows. They’re quick to deploy and easy for clients to edit later. That matters.

But the defaults have limits:

Area	Native Divi behavior	What to watch
Required toggle	Easy to enable per field	Teams often overuse it
Validation	Basic and functional	Messaging can feel generic
Labels	Flexible enough for common forms	Requires manual clarity in wording
Advanced logic	Limited in native module	Needs custom work for dynamic behavior
Accessibility	Basic visual support	Needs extra attention for ARIA and error association

A setup that works in practice

For a normal Divi contact form, this baseline is dependable:

• Require only email and message for general enquiries.
• Keep name optional unless your response style depends on it.
• Leave phone optional unless the offer is explicitly a callback.
• Use one open text field instead of several narrow qualification fields.
• Avoid duplicate intent fields like asking both “service needed” and “describe your project” unless routing depends on the first one.

The default state for any field should be “does not exist” until it earns its place in the form.

That one decision improves more forms than any styling tweak. Divi gives you the switch. Good form architecture is deciding when not to use it.

Improving UX with Smart Validation and Error Messaging

“Required” isn’t just a setting. It’s a usability problem.

A form fails when users don’t know what went wrong, don’t know how to fix it, or feel the form is punishing them for trying. That’s why validation and error messaging matter more than most visual tweaks. You can have a beautiful Divi layout and still lose submissions because the form behaves like a stern database instead of a helpful interface.

Treat validation as guidance

The best forms tell users three things fast:

1. What’s wrong
2. Where it happened
3. How to fix it

That sounds obvious, but many Divi implementations still rely on generic feedback. “Please fill out the field” is better than nothing, but it’s weak when the user has multiple fields, conditional states, or formatting requirements.

Write messages the way a real person would explain the issue:

• “Enter a valid email address so we can reply.”
• “Select a topic before continuing.”
• “Add your order number if this is about an existing purchase.”

These messages reduce hesitation because they explain the reason behind the requirement.

Client-side and server-side both matter

For Divi sites, I treat validation in two layers.

Client-side validation catches obvious issues before submission. It’s good for speed and user comfort. Email formatting, empty required fields, and basic character checks belong here.

Server-side validation protects the final submission. It matters because browser-side checks can be bypassed, and integrations often need a second line of defense before data reaches email handlers, CRMs, or WooCommerce logic.

A practical rule:

• Use client-side checks for fast guidance.
• Use server-side checks for trust, security, and clean data.

If both layers produce different messages, users get confused. Keep the logic and wording aligned.

Why optional-field marking can work better

There’s an interesting tension in forms required fields practice. Visual cues for required inputs reduce confusion. But overemphasizing required markers can make a form feel demanding.

Baymard’s benchmark found that only 14% of ecommerce checkout sites explicitly marked both required and optional fields, while 42% marked only required ones, in its analysis of required and optional form fields. The same benchmark also noted that unmarked optional phone fields still saw 86% completion rates compared with 89% when marked required. That gap tells you something important. Users often assume they must complete fields unless you clearly signal otherwise.

That’s why on longer or higher-anxiety forms, I often prefer this pattern:

• Assume fields are required only where necessary.
• Mark optional fields as Optional in plain text.
• Remove anything that doesn’t belong in the current step.

This lowers form anxiety because users don’t feel trapped by a wall of red indicators.

A required field is less threatening when there are only a few of them and the reason for each one is obvious.

This matters even more in checkout UX. If you’re refining a buying flow rather than a lead form, this piece on mastering ecommerce checkout page design to boost conversions complements the same principle: reduce hesitation by removing unclear asks and making completion feel straightforward.

What works and what doesn’t

Here’s the shortest version of what I’ve seen hold up.

Works	Usually fails
Specific inline error text	Generic error banners
Validation near the field	Errors shown only at the top of the form
Few required fields	Long forms with many compulsory inputs
Plain “Optional” labels	Making users infer optional status
Fast feedback after real interaction	Firing errors before users have started typing

A cleaner validation pattern for Divi

Use this sequence on most forms:

• First interaction: Don’t shout errors before the user starts.
• Field exit: Validate format-sensitive fields like email after blur.
• Submit attempt: Highlight any missing required fields together.
• Post-error state: Keep entered values intact so the user doesn’t have to retype.

That last point gets ignored too often. If the form clears or collapses after a validation fail, users leave.

Unlocking Conditional Logic with Divi Areas Pro

A visitor clicks “Wholesale enquiry” and your form still asks for an order number. A customer trying to get post-purchase help sees company VAT fields that do not apply to them. That kind of mismatch creates hesitation fast, especially in Divi and WooCommerce builds where every extra field adds friction.

Conditional logic fixes that by changing the form around the user’s actual intent. In practice, the best use is not just showing and hiding fields. It is deciding which fields become required at the right moment.

Use intent to control required states

On real projects, I treat conditional required fields as a restraint tool. They let you collect extra detail only when the user has already told you why it matters.

Common examples:

• A phone field becomes required only if the visitor asks for a callback.
• A company name field appears only for wholesale or partnership enquiries.
• An order number field becomes required only for existing-order support.
• A VAT or tax field appears for B2B checkout or trade applications, not standard retail purchases.

That trade-off matters. Sales teams usually want more data. Users want less work. Conditional logic is the middle ground that keeps forms shorter without starving the business of useful information.

A practical popup workflow

One pattern that works well with Divi Areas Pro is a behavior-triggered popup instead of a full form block shown to everyone.

A typical setup looks like this:

1. A user scrolls through a service page or triggers exit intent.
2. A popup opens with a short first question.
3. That answer determines which fields appear next.
4. Only the fields tied to that path become required.

This approach works especially well for WooCommerce support and pre-sales flows. Someone asking about bulk pricing should not have to scan past retail checkout questions. Someone requesting help with an order should not have to fill in business qualification fields first.

If you want the broader implementation options, this guide to Divi conditional logic for popups, forms, and targeted content covers the rule-building side well.

Building a multi-step required field flow

Multi-step forms can outperform single-page forms in some contexts, according to Reform’s research on form layout and completion. The practical lesson is narrower than many blog posts make it sound. Splitting a form only helps when each step feels relevant and easy to finish.

A structure I trust for service enquiries and WooCommerce support requests looks like this.

Step one asks for low-friction intent

Start with just enough to classify the request:

• Name
• Email
• A dropdown such as “What do you need help with?”

That first step should feel easy to finish in seconds.

Step two branches by answer

If the user selects Wholesale, show business fields.

If the user selects Order Support, show order-specific fields.

If the user selects General Question, keep the path light and skip the extra qualification fields.

Step three collects useful detail

Add a message field and, if needed, one or two context fields tied to the selected path. Do not split one useful explanation into five weak micro-fields unless your team has a clear reason for doing it.

Users accept required fields more readily when those fields clearly belong to the path they chose.

Later in the flow, a video walkthrough can help if you’re building more interactive popup experiences:

Code pattern for conditional required states

Divi setups vary, but the rule is simple. A hidden field should not stay required. Once a condition reveals that field, the required state and accessibility attributes should update with it.

<script>
document.addEventListener('DOMContentLoaded', function () {
  const inquiryType = document.querySelector('select[name="inquiry_type"]');
  const companyWrap = document.querySelector('.field-company');
  const companyInput = companyWrap ? companyWrap.querySelector('input, select, textarea') : null;

  function updateConditionalRequirement() {
    if (!inquiryType || !companyWrap || !companyInput) return;

    const businessSelected = inquiryType.value === 'Business Inquiry';

    companyWrap.style.display = businessSelected ? '' : 'none';

    if (businessSelected) {
      companyInput.setAttribute('required', 'required');
      companyInput.setAttribute('aria-required', 'true');
    } else {
      companyInput.removeAttribute('required');
      companyInput.removeAttribute('aria-required');
      companyInput.value = '';
    }
  }

  if (inquiryType) {
    inquiryType.addEventListener('change', updateConditionalRequirement);
    updateConditionalRequirement();
  }
});
</script>

This pattern does three jobs at once:

• shows and hides the field
• adds and removes the actual required attribute
• keeps aria-required in sync for assistive technology

That last part gets missed often in Divi customizations. A field that is visually optional but still marked as required in the DOM creates avoidable accessibility problems. The reverse is also true.

WooCommerce cases where the extra setup pays off

Conditional required fields are worth the extra configuration when they remove irrelevant checkout or support friction.

Scenario	Show this field	Make it required when
Retail checkout	Standard billing data	Needed for payment and fulfillment
Wholesale enquiry popup	Company name, tax-related business details	User selects wholesale interest
Support request after purchase	Order number	User selects order support
Callback offer	Phone number	User asks to be called

The trade-off is maintenance. Every extra branch adds testing overhead across mobile, validation, email delivery, and accessibility. Keep the logic obvious. Tie each required field to one visible user choice. If the rule needs a paragraph to explain to your client, it is probably too complicated for the form.

Making Required Fields Accessible for Every User

A visual asterisk helps sighted users. It doesn’t solve accessibility on its own.

That’s the gap in a lot of Divi form tutorials. They explain how to show required indicators, but not how assistive technology understands them. That matters because standard Divi Contact Forms can enable required fields without native aria-required="true" labeling, and this gap can lead to 20–30% higher abandonment for users relying on screen readers, according to the accessibility issue highlighted in this Divi required-field article from Pee-Aye Creative.

What accessible required fields need

For required fields to work well with screen readers, users need more than a red star beside a label. The form should communicate:

• which fields are required
• when an error has happened
• which message belongs to which field

If you’re also refining visible field labels in the module itself, this guide on how to show labels on fields in the Divi contact form helps with the visual side. The semantic layer still needs extra attention.

Add ARIA to the field state

For fields that are required, use aria-required="true" in addition to the native required attribute.

<input
  type="email"
  id="contact-email"
  name="email"
  required
  aria-required="true"
  aria-describedby="contact-email-error contact-email-help">

Why both?

• required gives native browser behavior.
• aria-required="true" makes the requirement more explicit to assistive tech.

Connect error messages properly

If a validation message appears, link it to the field with aria-describedby. Then update aria-invalid when the field fails validation.

<label for="contact-email">Email <span aria-hidden="true">*</span></label>
<input
  type="email"
  id="contact-email"
  name="email"
  required
  aria-required="true"
  aria-describedby="contact-email-error"
  aria-invalid="true">

<p id="contact-email-error">Enter a valid email address so we can reply.</p>

This is better than dropping a generic error block somewhere above the form. A screen reader user needs the field and the error to be programmatically connected.

If the error message isn’t tied to the field in the markup, many users won’t experience the form the way you think they are.

A practical enhancement script for Divi forms

On Divi projects, I often add a small script to improve required semantics after render.

<script>
document.addEventListener('DOMContentLoaded', function () {
  const requiredFields = document.querySelectorAll('.et_pb_contact_form input[required], .et_pb_contact_form textarea[required], .et_pb_contact_form select[required]');

  requiredFields.forEach(function(field) {
    field.setAttribute('aria-required', 'true');

    const fieldId = field.getAttribute('id');
    if (!fieldId) return;

    const errorId = fieldId + '-error';
    let errorEl = document.getElementById(errorId);

    if (!errorEl) {
      errorEl = document.createElement('p');
      errorEl.id = errorId;
      errorEl.className = 'form-error-message visually-hidden';
      field.parentNode.appendChild(errorEl);
    }

    field.setAttribute('aria-describedby', errorId);

    field.addEventListener('invalid', function () {
      field.setAttribute('aria-invalid', 'true');
      errorEl.textContent = 'This field is required.';
      errorEl.classList.remove('visually-hidden');
    });

    field.addEventListener('input', function () {
      if (field.validity.valid) {
        field.removeAttribute('aria-invalid');
        errorEl.textContent = '';
        errorEl.classList.add('visually-hidden');
      }
    });
  });
});
</script>

And pair it with a visually-hidden utility class:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Accessibility checks worth doing every time

• Keyboard test: Tab through the form without a mouse.
• Error test: Trigger validation and confirm the message appears near the right field.
• Label test: Every field should have a real label, not placeholder-only guidance.
• Conditional logic test: Hidden fields must not remain required.
• Screen reader pass: Check whether required status and errors are announced clearly.

Accessible forms are usually better forms, even for users who never touch a screen reader.

Your High-Conversion Form Checklist

A form can look polished in Divi and still underperform because of three small choices: one extra required field, one vague label, and one rule that breaks when conditional logic hides a field. That is usually where conversions leak.

Use this checklist before redesigning the layout or adding another plugin.

Field strategy

• Remove fields before you optimize them: If the next step does not depend on the answer, cut the field or collect it later.
• Require only what your workflow uses: Sales teams often ask for phone number, company size, and timeline by default. If nobody acts on that data in the first reply, it should not be required.
• Treat sensitive inputs as high-friction: Phone, date of birth, VAT details, and account numbers need context. In WooCommerce flows, buyers will abandon fast if the field feels unrelated to checkout.

Labeling and clarity

• Write labels that answer "why am I filling this out?": "Business email" is clearer than "Email." "Order number" is clearer than "Reference."
• Show required status consistently: If you use asterisks in one part of the form and "Optional" in another, users hesitate. Pick one system and apply it across the whole form.
• Use helper text where the label cannot carry the full job: This matters for fields like wholesale license number, delivery instructions, or custom product requirements.

Validation behavior

• Match the message to the mistake: "Enter a valid email address" is better than a generic required-field warning when the user typed the wrong format.
• Keep entered values after validation fails: Losing a half-completed WooCommerce inquiry form is a good way to lose the lead.
• Test the form in the browser, not just in the builder: Divi settings can look correct while custom scripts, CSS, or plugin conflicts change how validation behaves on the front end.

Conditional logic in Divi and WooCommerce

• Tie field visibility to user intent: If a shopper selects "Wholesale inquiry," then show resale certificate fields. If they choose standard retail checkout, keep those fields out of the path.
• Change required rules with the condition: A hidden field cannot remain required. This is one of the most common mistakes I see in Divi Areas Pro setups and custom WooCommerce form flows.
• Audit edge cases: Test what happens when users change their selection mid-flow, reopen a popup, or return to a previous step. Required-state bugs often show up there, not in the happy path.

Accessibility and compliance

• Use real required attributes, not visual hints alone: The asterisk helps sighted users. The field still needs semantic markup so assistive technology can interpret it correctly.
• Connect each error to the field it belongs to: If the message is visible but not programmatically associated, screen reader users get a broken experience.
• Check conditional states for accessibility too: If Divi Areas Pro reveals a required field after a user action, make sure focus order, announcements, and instructions still make sense.

A high-converting form asks for the minimum information needed to move the user to the next step, then handles the details cleanly. That is the balance. Better lead quality without making the form feel like work.

Frequently Asked Questions About Divi Forms

Should every important field be required

No. A field can be important to your business without being necessary for the first conversion. Require only what the current step depends on. Everything else should either be optional, deferred, or revealed later through conditional logic.

Can I build better required fields without a premium plugin

Yes, up to a point. Native Divi handles basic required fields well enough for simple contact forms. Once you need behavior-based field visibility, popup-driven interactions, or conditionally required WooCommerce flows, custom code or a specialized tool becomes much more practical.

Is asterisk labeling enough for accessibility

No. It helps visually, but it doesn’t fully communicate required state or errors to assistive technology. You still need semantic markup such as required, aria-required="true", and proper links between fields and error messages.

Should I mark required fields or optional fields

It depends on the form. For short forms, marking required fields can work well. For longer forms or higher-friction flows, clearly marking optional fields can reduce anxiety because users don’t feel surrounded by warnings. The important part is consistency and clarity.

How do I handle required fields in WooCommerce-related forms

Tie them to intent. Don’t ask retail buyers for wholesale data. Don’t require a phone number unless the purchase, delivery, or support flow depends on it. For support and post-purchase forms, make context-specific fields required only after the user selects the relevant issue type.

What breaks forms most often in Divi

Three things show up repeatedly: too many required fields, hidden fields that are still technically required, and weak error handling. Fix those first before redesigning the form.

---

Divi sites perform best when forms feel simple on the surface and smart underneath. If you want tools and tutorials built specifically for interactive Divi experiences, explore Divimode for advanced popup logic, targeted content behavior, and hands-on guidance that helps turn forms into better conversion paths.