WCAG Accessibility 3: Fixing Form Accessibility Issues in WordPress

Why Form Accessibility Matters

When a form is not accessible, the impact is immediate. A user may be unable to understand what a field is for, navigate between fields correctly, or submit the form at all. For screen reader users in particular, missing or incorrect labels make forms confusing and unreliable.

WCAG-compliant forms should provide:

• clear labels for every input field
• logical structure and field order
• meaningful button text
• appropriate error handling
• sufficient colour contrast and visible focus states

On WordPress sites, forms are often created using page builders or third-party plugins, which means accessibility problems can be introduced even when the form looks visually acceptable.

How the Form Issues Appeared on Rainbows Ireland

During the WAVE review of the Rainbows Ireland homepage, several missing form label errors appeared. At first glance this was confusing, because the visible homepage did not appear to contain that many problematic forms.

On closer inspection, the issue became clearer: hidden login and job application forms were being injected into the page through the popup system. These forms were not meant to be part of the visible homepage experience, but they were still present in the rendered DOM and still being assessed by accessibility tools.

That meant the homepage audit was picking up:

• login fields without proper associated labels
• application form fields relying too heavily on placeholders
• popup-generated controls that had not been fully configured for accessibility
    

The Problem with Placeholder-Only Fields

One of the most common WordPress accessibility mistakes is relying on placeholder text instead of a proper label. A placeholder may look neat from a design point of view, but it is not a substitute for a correctly associated form label.

This causes several accessibility problems:

• screen readers may not announce the field clearly
• the prompt disappears once the user starts typing
• users with cognitive or memory difficulties lose the field context
• automated accessibility tools correctly flag the input as missing a label

On Rainbows Ireland, this issue appeared in hidden popup forms such as login and job application fields. The forms looked simple enough visually, but the underlying markup did not provide a reliable label structure.

Why Hidden Forms Still Matter

A common assumption is that if a form is hidden in a popup or not currently visible, it can be ignored during accessibility work. In practice, that is not the case.

If the form markup is present in the DOM, accessibility tools such as WAVE can still detect it. More importantly, screen readers and keyboard users may still be affected by poorly structured hidden content if it is not handled properly.

This is exactly what happened on the Rainbows Ireland site. Hidden login and jobs popups were contributing accessibility errors to the homepage. That made it clear that the real fix was not just to edit the visible page, but to review the popup system and its form output directly.

Tracing the Source of the Errors

To resolve the form issues properly, it was necessary to move beyond the visual layout and inspect the underlying markup. WAVE identified the missing label errors, but developer tools were needed to confirm where the form fields were actually coming from.

This investigation showed that the forms were being loaded through popup templates, which meant the accessibility errors were not tied to the visible page builder content alone. The real source was hidden popup markup generated by the JetPopup setup.

This is an important lesson in WordPress accessibility work: the source of a form problem is not always the page you are looking at. It may sit in a popup template, a reusable component, or a plugin-generated output layer.

Reviewing Labels in Form Builders

Where form builders are used, one of the first steps is to check whether labels are actually being rendered in the output. It is not enough to see a “Label” field in the editor panel if the frontend markup still hides or omits it.

For each form field, the review should include:

• whether a visible or screen-reader accessible label exists
• whether the label is correctly associated with the field
• whether the field type is appropriate, such as email for email inputs or tel for phone numbers
• whether required fields are clearly indicated

On Rainbows Ireland, this formed part of the wider accessibility review because the popup forms and other form-related elements could not simply be assumed to be correct by default.

Visible Forms Still Need Proper Structure

Although hidden forms were a major source of errors in this project, visible forms also need the same level of care. Contact forms, booking forms, and enquiry forms all need clear field labels, readable text, accessible buttons, and sensible validation messages.

It is easy for WordPress forms to fail accessibility in subtle ways, including:

• labels that are visually hidden without accessible fallbacks
• button text that is too vague
• reCAPTCHA widgets that are misconfigured
• fields with weak contrast or poor focus visibility

The Rainbows Ireland work highlighted how quickly these issues can accumulate across visible and hidden form elements if they are not reviewed as part of a broader accessibility process.

Third-Party Form Markup and Accessibility Noise

Another challenge with WordPress form accessibility is that plugins often generate additional markup automatically. This can include wrappers, ARIA attributes, hidden inputs, validation elements, and popup layers. Some of this is helpful, but some of it introduces noise or accessibility issues of its own.

In this case, the combination of popup templates, plugin-generated form output, and hidden elements made the audit appear more complex than a simple visual review would suggest. The key was to separate:

• real user-facing accessibility failures
• hidden but still relevant DOM issues
• plugin-generated output that needed configuration rather than cosmetic changes

That distinction made it possible to apply the right fix in the right place rather than simply reacting to each warning one by one.

What This Process Revealed

The most valuable insight from this stage of the project was that form accessibility is rarely isolated to one contact form on one page. On a modern WordPress site, forms may exist in visible content areas, popup templates, booking interfaces, login screens, and plugin-generated modal layers.

That means accessibility work on forms needs to cover:

• visible form content
• hidden popup templates
• field labels and input types
• buttons, validation, and assistive markup
• third-party integrations such as reCAPTCHA or consent tools

On Rainbows Ireland, the hidden popup forms were especially important because they were responsible for multiple homepage accessibility errors even though they were not part of the visible page design.

Key Takeaways

• Placeholder text is not a substitute for a properly associated label.
• Hidden forms still matter if they are present in the DOM.
• Popup systems can create accessibility failures on pages where the form is not visibly displayed.
• Form builders must be checked at output level, not just in the editor interface.
• WordPress accessibility work requires careful review of both visible and plugin-generated form markup.
    

Summary

Fixing form accessibility issues on the Rainbows Ireland website involved much more than reviewing one visible form. It required tracing missing labels back to hidden popup templates, checking the behaviour of placeholder-only fields, and understanding how plugin-generated form markup affected the homepage audit.

That process reinforced a wider point: form accessibility is one of the most important parts of WCAG compliance, because forms are where users are asked to take action. If the form fails, the service fails with it.

In the next article, we will look specifically at third-party plugin accessibility issues in more detail, including cookie banners, popups, and other components that can affect accessibility even when the main page content appears correct.