tdAccessibility.js Search dialog may block pages when Accessibility is enabled.

Hello tagDiv Support,

We are experiencing an issue with the header search (magnifier icon) that may block page interaction, mainly on mobile, only when the Theme Panel module:

Template Settings → Accessibility (Keyboard + Skip link + Search dialog) is enabled.

When the magnifier is tapped, the search panel appears, but the page can become partially or fully unresponsive (e.g., cannot type into the search field, closing becomes unreliable, and the page may require a reload to recover). In DevTools we consistently see the following warning during the sequence:

“Blocked aria-hidden on an element because its descendant retained focus…”

This points to tdAccessibility.js applying aria-hidden=”true” (and/or inert) to an ancestor while a descendant still has focus (e.g., the search trigger button or the search input). This creates an invalid accessibility state and can leave the UI in an inconsistent “stuck” state.

We implemented a temporary mitigation snippet to prevent the stuck state site-wide, but we intentionally excluded one single post so you can reproduce the issue without the mitigation on a controlled page:

https://recordeuropa.com/noticias/portugal/portugal-e-espanha-juntos-sao-a-maior-plataforma-turistica-do-mundo-16-03-2025-263052

On that page, the behaviour is “as-is” with the Accessibility module enabled, to help you test and diagnose the tdAccessibility.js Search dialog flow.

Please review the tdAccessibility.js Search dialog logic to ensure that:
aria-hidden=”true” / inert is never applied to any element that contains the currently focused node;
the search dialog container cannot end up aria-hidden=”true” while it contains the focused input;
opening/closing restores a consistent state every time on mobile (focus + attributes).

Thank you.
Regards.

Hi Calin,

Thanks for the suggestions — we tested exactly as requested (logged in, no cache, and only tagDiv/theme plugins active) and the issue still reproduces reliably on our side on both desktop and mobile.

From comparing the DOM between an installation where the search works and our installations where it fails, the key difference is where the theme’s Accessibility module ends up placing/targeting #maincontent. The module (via tdAccessibility.js) assigns/normalises the #maincontent container based on what it detects in the page structure (e.g., presence/absence of a proper <main> element and the surrounding wrappers). On our affected sites, #maincontent resolves to a wrapper that also contains the header/search trigger, so when the search is opened the script attempts to apply aria-hidden/inert to #maincontent while focus is still on the search trigger. Chromium then blocks aria-hidden in that state (“descendant retained focus”), and the page ends up in an inconsistent/blocked interaction state.

This would also explain why the same setting appears to work on a generic installation: if #maincontent resolves to the actual content area (excluding the header), the search trigger is not a descendant of #maincontent, so the focus/aria-hidden conflict never happens.

Thank you.

Hi,

Quick update after upgrading Newspaper to v12.7.5.

The issue still reproduces with the Accessibility module enabled (Template Settings → Accessibility (Keyboard + Skip link + Search dialog)), but the behaviour has slightly changed due to the update.

Before 12.7.5, the focus/ARIA conflict typically involved #maincontent. After 12.7.5 (changelog mentions “Accessibility, improved main content wrapper selector”), the browser warning now consistently shows the ancestor being hidden/inert is #td-outer-wrap:

“Blocked aria-hidden on an element because its descendant retained focus…”
Focused element: #td-header-search-button / #td-header-search-button-mob
Ancestor with aria-hidden/inert: div#td-outer-wrap

So the underlying problem remains the same (ARIA hidden/inert applied to a container that still contains the focused search trigger/input), but the update appears to have changed which wrapper is targeted by the Accessibility logic.

We currently mitigate this with a temporary hotfix on our side that prevents aria-hidden/inert from being applied to the wrapper being targeted. After the update, that mitigation had to be adjusted from #maincontent to also cover #td-outer-wrap, which matches the new runtime behaviour.

In short: 12.7.5 changed the target wrapper, but the focus/aria-hidden timing conflict is still present.
Thank you.
Regards.