Roman

What do you mean by “did not find the issue as mentioned”?

If one looks at the page in the browser or in the htm codel, one will find that it displays all titles, hence the exclusions are not working.

Thank you very much in advance for taking care of it!

Could you please also add an ARIA: heading role or similar to the respective <div> so that the accessibility standards are fully respected?

The issue appeared after your last update!

I shared the link of one of the affected pages, but they are many more.

Would it be helpful if we grant you a temporary access to the problematic domain?

Hello Team,

Thank you for your kind reply!

I am not trying to achieve any particular action with your plugin personally. My primary concern is the adherence to accessibility standards, which will become mandatory for all websites in 2025.

The current implementation of onclick="brave_lightbox_close()" cannot be activated by users who rely on screen readers or navigate using keyboards. This makes the functionality inaccessible to a significant portion of users, including those with disabilities.

Ensuring that all interactive elements can be operated using both mouse and keyboard is essential for compliance with accessibility standards. This is particularly important as we approach the 2025 deadline for mandatory compliance.

<div id="bravepop_element_lightbox_close" onclick="brave_lightbox_close()"></div>

Proposed Solution: To resolve this issue, please modify the div element to include the following attributes and event handlers:

• Add role="button" to indicate that it is a button.
• Add tabindex="0" to make it focusable.
• Add an onkeypress event handler to handle keyboard events such as Enter and Space.

<div id="bravepop_element_lightbox_close" role="button" tabindex="0" onclick="brave_lightbox_close()" onkeypress="if(event.key === 'Enter' || event.key === ' ') brave_lightbox_close();"> <!-- Close icon or content --> </div>

These changes will ensure that the close functionality is accessible to all users, including those who rely on keyboard navigation.

I am glad that you are considering adding the option to close the popup in the future. However, I am not sure if this alone will resolve the issue. Could you please have a closer look at the accessibility problem with your developer(s)? The information I posted above should provide the necessary context.

Thank you for your attention to this matter. Improving the accessibility of the plugin will significantly enhance its usability for a broader audience, ensuring compliance with upcoming standards and providing a better user experience for everyone.

Best regards,

Roman Trushanov

Dear FancyBox Support Team,

Thank you for opening a ticket regarding my initial request!

I could not help but notice another accessibility warning flagged by the respectable tool https://wave.webaim.org/

You can look at the original view by following this link https://wave.webaim.org/report#/https://www.arbeitslosenselbsthilfe.org/bekommen-buergergeld-empfaenger-weihnachtsgeld-vom-jobcenter/

What is the matter:
A positive tabindex value is present.

Why It Matters:
Tabindex values of 1 or greater specify an explicit tab/navigation order for page elements. Because it modifies the default tab order, it can cause confusion and result in decreased keyboard accessibility, it should be avoided.

What To Do:
If the natural tab order is already logical, remove the tabindex. Otherwise, consider restructuring the page so that tabindex is not needed. If tabindex is maintained, ensure that the resulting navigation is logical and complete.

The Algorithm in English:
A tabindex attribute is present and has a positive value.

These lines of code were flagged by wawe.webaim.org:

• <a id=”fancybox-close” href=”javascript:;” title=”Close” class=”fancy-ico” tabindex=”1″><span></span></a>
• <a id=”fancybox-next” href=”javascript:;” title=”Next” class=”fancy-ico” tabindex=”2″><span></span></a>
• <a id=”fancybox-prev” href=”javascript:;” title=”Previous” class=”fancy-ico” tabindex=”3″><span></span></a>

Could you please review if the use of tabindex in these instances is necessary? If not, it would be beneficial to remove them or ensure the navigation order remains logical and complete.

Thank you for your attention to this matter. I look forward to your response.

Best regards,

Roman Trushanov

• This reply was modified 10 months, 1 week ago by Roman.
• This reply was modified 10 months, 1 week ago by Roman.

With the new version the issue is gone, I can confirm that.

Thank you for opening a ticket for the IT! We appreciate that.

With respect to “These shortcodes are still a crucial part of our Easy TOC plugin and haven’t been deprecated.”, it is of vital importance that the manually seeded [toc] and [ez-toc] remain enhanced in the future, without being overwritten by automatic settings. The newly arised conflict with “Internal Link Juicer (Pro) prevents that.

Here you go.

https://www.ads-software.com/plugins/internal-links/

I linked the free version, although we have the PRO-version installed.

1. Fatal Error with [ez-toc-widget-sticky] Shortcode: Upon implementing the new [ez-toc-widget-sticky] shortcode to replace the original [ez-toc], my site experiences a fatal error that prevents the page from loading. Additionally, while editing the page in “edit mode” and attempting to save the change from [ez-toc] to [ez-toc-widget-sticky], I receive an “Updating failed.” error message. This issue is critical as it directly impacts the usability and accessibility of the content on the page.
2. Plugin Conflict with “Internal Link Juicer (Pro)”: After updating to the latest version of “Internal Link Juicer (Pro)” (version 2.23.6), I’ve noticed a conflict that affects the display and functionality of table of contents on my site. Specifically, the [toc] and [ez-toc] shortcodes that we’ve implemented across all pages are not functioning as expected, with table of contents appearing in arbitrary positions on the page. Temporarily reverting to an older version of the plugin (“Internal Link Juicer (Pro)” version 2.23.4) seems to mitigate the issue, suggesting a compatibility problem with the latest version.

Given these challenges, I am seeking your assistance to:

• Understand the cause of the fatal error with the [ez-toc-widget-sticky] shortcode and find a resolution.
• Address the compatibility issue between the “Internal Link Juicer (Pro)” plugin version 2.23.6 and the shortcode functionality on my site.

https://www.arbeitslosenselbsthilfe.org/test/

To acceed the content of the URL to investigate, type “test” into the password-field.

* Fix: Usage of core filter?pre_comment_user_ip?breaks ASB if the IP address is removed for GDPR compliance -> works for the whole network of our wp-domains. Thank you very much for the timely release!

“I think this could be caused by using the core filter here. I will check with the team and maybe we need to use an own filter to fix this.”

Looking forward for updates! Since we are subjected to the German GDPR-regulations, we can′t store any IP-adresses at all, even for a short period of time.

Hello there,

We are experiencing the very same issue on about 30 WP-domains.

Therefore, I would like to ask you:

“Can I disable the IP-check in the plugin?” -> is this possible?

Best,

Roman

• This reply was modified 1 year, 6 months ago by Roman.

Hello Serge,

I still could not save any changes. But a complete re-installation of the plugin helped.

It is perhaps worth to add that:

1. the domain in object is a multi-site
2. we already had a CleanTalk account, without me knowing that. It took some time to find the password out and sync the keys.

Best,

Roman

• This reply was modified 1 year, 7 months ago by Roman.

So, I tried again with Twenty Twenty-Three. Deactivated all the plugins. The problem still persists.

When I activate only Yoast in the troubleshooting mode, there is a tiny difference in the HTML output:

without yoast

<title>Wer darf auf einem Frauenparkplatz parken? & #8211; (without the extra space at the beginning) Bussgeldkatalog.de</title>

with yoast

<title>Wer darf auf einem Frauenparkplatz parken? – Bussgeldkatalog.de</title>

But, in principle, the two tags are the same. & #8211; (without the extra space at the beginning) is indeed the same as –

Do you have any other ideas regarding the debugging of this issue?

Best,

Roman

• This reply was modified 1 year, 9 months ago by Roman.

Hello Maybelline,

I did switch to the old good Twenty-Twenty as suggested by the guide you recommended to me: https://yoast.com/help/how-to-check-for-plugin-conflicts/

The issue persists. Switching to Twenty-Twenty does not solve the issue, regardless of Yoast being active/not active.