Make embedded forms more accessible & WCAG compliant

HubSpot Ideas

Status: Not Currently Planned

Status history

1

At present, HubSpot embedded forms do not meet common standards for accessibility compliance. To meet common standards such as WCAG 2.0 several changes would be required, for example:

  • Focus States: Clearly indicate which element has focus when navigating with a keyboard. For example, on form submit if a user has not completed a required field the focus should go to the required field and the error message should be labeled relevant to that field, not the whole form.
  • Required field labels: Similarly, required form fields should be labeled, (for example include aria-required=“true”) to inform screen-reader users of the field’s validation.
  • Name, Role, Value: Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities. While HubSpot forms can be labeled in the form editor, form elements should have unique IDs to ensure that their corresponding labels provide accurate information and this isn’t always true, nor can labels be edited easily in the embedded form.
2

Indeed. We are creating a form for vision-impaired users and it totally fails WCAG AAA in a number of ways.

Here’s what the HubSpot support bot came back with:

First, I want to acknowledge how important this is, especially given that a significant part of your audience is vision impaired and that you’re targeting full WCAG AAA compliance. I understand your disappointment when the default HubSpot forms don’t meet that bar out of the box, and I appreciate how clearly you’ve articulated the issues.

HubSpot’s standard form renderer is designed with general accessibility in mind, but it is not certified as WCAG AAA-compliant, and there is currently no “WCAG level” toggle or setting in the form editor. For AAA-level requirements, some additional development work (or fully custom forms) is typically needed.

1. How your specific findings map to current HubSpot behavior

1.1 Programmatic label associations

From your description, the key concern is that while labels look visually correct, the HTML structure does not give you a reliable guarantee that each <label for=“…” /> is bound to the correct input for screen readers and voice input users.

Today there is no setting in the Forms UI that allows you to control the exact label/input markup or ARIA attributes. The structure is generated by HubSpot’s form renderer and can be influenced primarily through:

  • The surrounding page/module or theme when you place the form on HubSpot CMS pages (via form modules and custom modules).
  • Your own HTML/CSS/JS when you embed the form on an external site and customize it via the embed/developer code.

For strict WCAG AA/AAA requirements, HubSpot recommends using accessible templates/modules and following a11y best practices when developing on the CMS. You can see our general CMS accessibility guidance here: HubSpot CMS accessibility best practices

.

1.2 Required fields and aria-required / required attributes

You’re correct that:

  • Required fields are primarily indicated visually in the form editor (e.g., asterisks), and
  • There is no option in the current editor to explicitly configure aria-required=“true” or other ARIA attributes per field.

The form editor lets you mark fields as required, but the accessibility semantics of that requirement (for example, whether and how required, aria-required, or aria-invalid are output) are not configurable via the UI. That’s a limitation if you need guaranteed AAA-level behavior across all assistive technologies.

1.3 Error handling, error summary, and focus management

The behaviors you’re looking for are the standard accessible error patterns:

  • An error summary region that lists all errors.
  • Automatic focus movement to the first error when submission fails.
  • Errors announced via a live region so screen reader users immediately hear what went wrong.

Out of the box, HubSpot forms display inline error messages visually, but:

  • There is no built-in global error summary at the top of the form.
  • Focus is not automatically moved to the first invalid field or a summary container.
  • There is no user-facing configuration in the form editor to control ARIA live regions or focus management for errors.

So you are right that, as of now, the stock behavior falls short of typical WCAG AA/AAA error-handling patterns for screen reader users.

4

Hi Everyone,

Thank you all for taking the time to submit, vote and comment on this Idea.

I’m Sabari, the PM for HubSpot’s Forms tool.

At this time there are no plans to develop this idea. This is not to say that this idea will never be developed, just that there are no plans to do so at this time.

Regards,

Sabari