Web Accessibility: Discrepancies Between Jotform's Check and External Tools Like WAVE

Good afternoon,

I am using the check accessibility feature on my forms. To use one as an example, I have received the "No accessibility problems" message for my "Contact Us" form. However, when I check the accessibility of the web page using an outside tool like WAVE, I see several errors having mainly to do with form labels and ARIA references. Are you please able to assist?

Hi Clayton,

Thanks for reaching out to Jotform Support. I'm an AI assistant here to assist you.

When you enable the Form Accessibility option in Jotform's Form Builder, it scans your form for potential accessibility issues and warns you if any are detected. This check is based on Jotform's internal accessibility standards and runs each time you update your form. If your form shows "No accessibility problems" in Jotform but external tools like WAVE report errors related to form labels and ARIA references, this can happen because external tools may have different or more stringent criteria for accessibility.

Here’s how to address this:

1. Review Jotform Accessibility Warnings: In the Form Builder, enable the Form Accessibility option under Settings > Show More Options > Form Accessibility. Fix any warnings shown, such as missing labels, empty sublabels, or unsupported widgets.
2. Check Form Labels and ARIA Attributes: Ensure every form question has a clear label and that sublabels are not empty. Jotform automatically handles ARIA attributes for most fields, but some widgets like the Unique ID widget may trigger warnings because they are not fully accessibility-compliant. You can replace such widgets or use Jotform's Accessibility Enhancer widget to improve ARIA attributes.
3. Compare with External Tool Findings: External tools like WAVE may flag issues that Jotform's checker does not. Review those specific errors and see if they relate to custom HTML, embedded elements, or external scripts on your webpage that are outside Jotform's control.
4. Use Accessible Themes and Color Schemes: Jotform offers accessible color schemes and themes designed for better contrast and readability, which can help with some accessibility concerns.
5. Alternative Text for Images: Add alternative text to all images in your form to improve accessibility for screen readers.

For more detailed guidance, you can visit Jotform's accessibility help page on How to Make Forms Accessible.

If you continue to see discrepancies between Jotform's accessibility check and external tools, it may be due to differences in evaluation criteria or additional elements on your webpage outside the form itself.

Give it a try and let us know how it goes.

The Jotform accessibility page says "Jotform builder lets you create accessible forms that are Section 508 and WCAG 2.1 Level A and Level AA compliant," so it should be the same standards as the WAVE tool. Can I speak to a real human?

Hi Clayton,

One of our Support Team members will take it from here to follow up shortly.

Hi headquartersbranchcanva,

You’re right that Jotform advertises compliance with Section 508 and WCAG 2.1 Level A/AA. The difference you’re seeing comes down to the scope and depth of each checker. Jotform’s built‑in accessibility tool is designed to catch the most common issues inside the form builder, like missing labels, contrast issues, or required fields.

WAVE, on the other hand, evaluates the rendered HTML of the published page and applies stricter WCAG rules. That’s why it surfaces issues with labels and ARIA references that Jotform’s checker doesn’t flag. Here’s why WAVE flags errors while Jotform reports no accessibility issues:

• Jotform checks the form only within its builder. Once the form is embedded or published, extra markup can appear, and WAVE inspects that.
• Jotform’s checker doesn’t fully validate ARIA references or structural grouping, but WAVE does, so broken aria-labelledby attributes or orphaned labels get flagged.
• Jotform may allow multiple labels for flexibility, but WCAG requires each input to have a single, programmatically associated label.

Reach out again and let us know if you have any other questions.

Hi Joeni,

Are there any way to correct the issues on the published HTML pages/forms, either on my end or by someone at Jotform? Or can you not really guarantee AA compliance, then?

Thanks!

Hi Clayton,

I understand the issue. Let me look into it and get back to you with verification on what Jotform can do.

Thanks so much, Brandon!

Hi Clayton,

Thank you so much for your patience! As it currently stands, Jotform cannot correct issues once the form has been published. While that feature isn’t available in Jotform right now, I’ve sent this ticket and desired functionality to our Developers for review as a feedback request. When or if it gets developed will depend on their current workload, how possible it is, and how much demand there is from other users. If/when we have any updates, we’ll follow up here and keep you posted.

Thanks, Brandon! I appreciate you looking into it. It's also just a suggestion, but Jotform should stop advertising WCAG compliance/accessibility until it's actually possible. My forms are pretty basic, so they shouldn't be pushing the limits of what is possible in Jotform/creating new issues.

Thanks!

Adding to this thread, as we are encountering the same issue described by Clayton. Jotform's built-in accessibility checker reports our published forms as having no issues, but running the same forms through WAVE returns multiple violations, including missing form labels and broken ARIA references.

I would like to highlight why we consider this a significant concern rather than a minor discrepancy:

1. Jotform publicly advertises compliance with WCAG 2.1 Level A and AA and Section 508. Our procurement process relied on those claims. If the in-builder checker does not validate the rendered output, the compliance statement cannot be verified against the artifact that end users actually interact with.
2. Accessibility obligations are assessed against the published page, not the editor. A passing result in the Jotform checker that does not reflect the production form creates a meaningful risk for customers who rely on it as evidence of conformance.
3. Until parity between the checker and the published output is achievable, we would respectfully ask that the in-builder checker include a clear notice stating that it does not evaluate the published form.

We would appreciate this being formally re-escalated rather than left as open feedback, and we are happy to provide our form ID and the corresponding WAVE report to assist the development team in reproducing the issue.