A tabbed form that silently refused to submit — required fields hidden behind another tab

Background

The site edit modal kept accumulating fields — site name, category, SSH connection details, WordPress install location — until editing anything meant scrolling up and down a single long form to find the right field. To clean this up, we split it into three tabs: "Registration info," "SSH," and "WordPress info." That change broke form submission itself, in a way that was hard to spot at first.

What tabbing broke

The tab implementation itself is straightforward. Each tab's fields live in a <div class="site-tab-content" data-tab="...">, and CSS toggles which one is visible.

.site-tab-content { display: none; }
.site-tab-content.active { display: block; }

An inactive tab is hidden with display: none. Nothing unusual so far, and visually it worked fine.

The problem showed up when a required field sat in a tab that was not currently active, and the user left it empty while saving from a different tab. Clicking the save button did nothing. No error message appeared. The form just looked stuck.

Root cause: a browser cannot report an error on a field it cannot show

HTML5 form validation works by having the browser automatically block the submit event whenever a constrained field (like required) fails, then focusing that field and showing its standard validation bubble (equivalent to calling reportValidity()).

Note: reportValidity() is a method from the HTML5 Constraint Validation API. It checks whether a form element's value satisfies its constraints (required, pattern, etc.) and, if not, displays the browser's standard error bubble.

But when the failing field sits inside a tab hidden with display: none, the browser has nowhere to anchor that error bubble. It still faithfully blocks the submit — but it cannot visualize the error, so it simply stops without any visible feedback. From the user's side, this looks exactly like a button that does not respond.

Before tabbing, every field lived on the same screen, so this never surfaced. Introducing tabs — a UI pattern that deliberately limits what's visible at once — broke an implicit assumption the browser's built-in validation depends on: that an invalid field is always visible.

The fix: novalidate plus JS-driven validation

The fix was to stop relying on the browser's automatic blocking. Adding novalidate to the form disables that automatic block and guarantees the submit event always fires, letting JavaScript take full control of validation.

async function saveSite(e) {
    e.preventDefault();
    const form = e.target;

    // If checkValidity() fails, switch to the tab containing the first
    // :invalid element, then focus it and call reportValidity().
    if (!form.checkValidity()) {
        const firstInvalid = form.querySelector(':invalid');
        if (firstInvalid) {
            const tabContent = firstInvalid.closest('.site-tab-content');
            if (tabContent && tabContent.getAttribute('data-tab')) {
                switchSiteTab(tabContent.getAttribute('data-tab'));
            }
            // Focus/scroll may not work right after a tab switch,
            // so call reportValidity() on the next frame.
            requestAnimationFrame(() => {
                try { firstInvalid.focus({ preventScroll: false }); } catch (_) {}
                firstInvalid.reportValidity();
            });
        }
        return;  // abort submission on validation failure
    }
    // ...normal save flow continues here
}

Two things matter here.

1. novalidate does not disable the constraints themselves. Attributes like required and pattern remain in effect, and both checkValidity() and the :invalid pseudo-class still work as expected. What novalidate disables is only the browser's automatic "block submit and show the error" behavior.
2. The code finds the first :invalid element and forces a switch to its tab before calling reportValidity(). By making the field visible first, the browser can render its error bubble without issue. Since a tab switch may not have finished painting yet, the code waits one frame via requestAnimationFrame before calling focus() and reportValidity().

A concrete case: making the SSH profile conditionally required

This mechanism paid off directly with the SSH profile requirement. The site edit modal has an "Update via browser only (no SSH)" checkbox; leaving it unchecked makes selecting an SSH profile mandatory. We wanted to prevent saving a site that satisfies neither option — no profile selected, and the checkbox left unchecked.

function toggleSSHFields() {
    const isBrowserOnly = document.getElementById('browser_only_check').checked;
    const profileSelect = document.getElementById('server_profile_select');

    if (isBrowserOnly) {
        // Browser-only mode doesn't need a profile
        profileSelect.value = "";
        profileSelect.removeAttribute('required');
    } else {
        // SSH mode requires a profile
        profileSelect.setAttribute('required', '');
    }
}

The required attribute is toggled dynamically based on the checkbox state, and the rest is handled by the cross-tab validation logic in saveSite described above. Trying to save without a profile selected automatically opens the "SSH" tab and shows the error bubble right on the profile dropdown. The user never has to hunt for why saving isn't working.

A side benefit: accessibility via ARIA

Alongside the tab split, we added role="tablist" / role="tab" / role="tabpanel" and aria-selected / aria-controls / aria-labelledby.

<div class="site-tabs" role="tablist" aria-label="Site edit tabs">
    <button type="button" class="site-tab-btn active" role="tab"
            id="site-tab-btn-info" aria-selected="true"
            aria-controls="site-tab-panel-info">Registration info</button>
    <!-- SSH and WordPress info tabs follow the same pattern -->
</div>

The tab-switching JavaScript keeps aria-selected in sync as well.

function switchSiteTab(tabName) {
    form.querySelectorAll('.site-tab-btn').forEach(btn => {
        const isActive = btn.getAttribute('data-tab-target') === tabName;
        btn.classList.toggle('active', isActive);
        btn.setAttribute('aria-selected', isActive ? 'true' : 'false');
    });
}

It is not just a visual toggle — screen reader users also get told which tab is currently selected.

Wrap-up

Splitting a form into tabs feels like an intuitive cleanup, but it can quietly break an assumption the browser's built-in validation depends on: that an invalid field is always visible on screen. Disabling the automatic block with novalidate, keeping the constraint checks alive through checkValidity() / :invalid, and making the failing field visible before calling reportValidity() — that small extra step is what lets a tabbed UI coexist with standard form validation. It's a modest but broadly reusable pattern for any design that splits a form across multiple views.

Comments

[Bert Shim]

The silent part is what makes this expensive. I drive a lot of forms from scripts, and this failure looks identical to the click not landing, so you retry.

Ran into the mirror image today. A submit that looked like it failed, box still full, had actually gone through. A retry there would have posted twice. Now I check the target state before assuming anything about what the click did.

[Kane Lim]

One detail I’d add is that the browser can still determine that a display:none field violates a constraint—the bigger issue is that native error reporting/focusing becomes unreliable or effectively invisible when the invalid control is not rendered. That distinction is useful when debugging similar forms.

I especially like the requestAnimationFrame() step after switching tabs. For a production implementation, I’d consider extracting the validation flow into a reusable function:

checkValidity() → identify invalid field → locate owning tab → activate tab → focus/reportValidity()

That makes the pattern easier to reuse with dynamically added fields and future tabs instead of coupling it directly to saveSite().

The accessibility work is also a good direction. Beyond aria-selected, aria-controls, and the tab/tabpanel roles, I’d make sure the component supports keyboard navigation (ArrowLeft/Right, Home, End) and follows a consistent focus-management strategy.

The broader lesson here is valuable: when native browser behavior interacts with custom UI state, the transition between the two needs to be explicit. The pattern you've described is applicable well beyond tabs—multi-step forms, accordions, dialogs, conditional sections, and other interfaces where invalid controls may be temporarily hidden.