Versions Tested

  • 2.1.22
  • 2.2.20

Problem / Motivation

EditorIA11y is not detecting heading hierarchy violations (H1–H6 structure issues)
when the headings are placed inside jQuery UI accordions.

This issue was first observed in 2.1.22 and persists after upgrading to
2.2.20.

Even when:

  • The accordion panels are programmatically opened
  • ed11yPanelOpened is triggered
  • All accordion panels are manually opened before scanning

EditorIA11y does not detect heading violations inside the accordion content.

However, if I remove the jQuery UI accordion JavaScript library attachment
(so the content renders as normal static page content), EditorIA11y correctly
detects the heading violations.

This suggests the issue may be related to how EditorIA11y scans dynamically
controlled or initially hidden DOM elements.

Steps to Reproduce

  1. Create content with heading hierarchy violations inside a jQuery UI accordion.
  2. Initialize accordions using jQuery UI.
  3. Trigger ed11yPanelOpened.
  4. Programmatically open all accordion panels.
  5. Run the EditorIA11y scan.

Result

EditorIA11y does not detect heading level violations inside accordion panels.

Control Test

  • Remove the jQuery UI accordion JS library.
  • Allow content to render fully expanded (no collapsing behavior).
  • Run EditorIA11y scan.

Result

EditorIA11y correctly detects heading violations.

Example Markup Used for Testing

<h2>
    Header H2
</h2>

<h1>
    Main Page Title
</h1>

<!-- ❌ Skipping H2 -->
<h3>
    Section Title
</h3>

<p>
    This section content skips the H2 heading level.
</p>

<!-- ❌ Multiple H1s used incorrectly -->
<h1>
    Another Main Title
</h1>

Expected violations:

  • Skipped heading level (H1 → H3)
  • Multiple H1 elements used incorrectly

Environment

  • Drupal site
  • jQuery UI accordion for collapsible content
  • EditorIA11y versions tested: 2.1.22 and 2.2.20

Expected Behavior

EditorIA11y should detect heading hierarchy violations inside accordion content
when the panels are open and visible in the DOM.

Comments

chamilsanjeewa created an issue. See original summary.

chamilsanjeewa’s picture

Issue summary: View changes
itmaybejj’s picture

Can you tell me what is set on your configuration page for "Dynamically refresh if new content appears" under "Displaying Results"? Is it set to "Watch for changes anywhere on the page"?

There are two conflating issues to diagnose here -- one whether the change is not being detected, and one as to whether I might need to add a parameter for detecting certain hidden content and pretending it is not hidden.

That said.......the 3.x branch is a significant rewrite, so if we determine this can't be fixed by changing the "Dynamically refresh," config and also still persists into 3.x, I'll want to work on the fix there.

chamilsanjeewa’s picture

Hi itmaybejj,
It was set to "Watch for changes anywhere on the page"

itmaybejj’s picture

Assigned: Unassigned » itmaybejj

Thanks so it's the other one then.

I managed to get a test instance working and can confirm the issue, and that it is present in the 3.x branch as well. It looks like the library's hiddenElementCheck currently assumes that anything with an aria-hidden attribute should not be included in the heading outline, and that jQuery UI is toggling between aria-hidden="true" and aria-hidden="false" rather than just removing the aria-hidden attribute. This is an easy fix I can address in the next release.

chamilsanjeewa’s picture

Thank you so much

  • itmaybejj committed cc29a245 on 3.0.x
    feat: #3574069 EditorIA11y does not detect heading level violations...
itmaybejj’s picture

Status: Active » Reviewed & tested by the community

  • itmaybejj committed cc29a245 on 3.0.x-dev
    feat: #3574069 EditorIA11y does not detect heading level violations...
itmaybejj’s picture

Status: Reviewed & tested by the community » Fixed

This should work as expected in 2.2.22.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.