The topic’s title is false and should instead be something like ‘Hidden Element Fails Accessibility Scanner I’m Currently Using’.
AddToAny is perfectly accessible to those using screen readers and other assistive devices. “More…” is clearly understood within the context of the mini menu, which isn’t actually used unless explicitly enabled on a site.
Since you’re not using the mini menu, the hidden element has no impact to users or your site, and there’s no need to change it. That said, you’re free to customize text using AddToAny’s language customization feature.
Thanks for the quick response. Apologies for not describing it exactly as you wish, but kudos for attacking a user trying to help make your plugin more accessible. I understand context is key and “More…” as a last item in the popup of other social links could be considered subjectively contextual, but it’s a simple suggestion to be more clear and objective in the intention of the link. Even if just a best practice.
Unrelated to accessibility, I would also argue that outputting code (even hidden) in the footer when those settings are specifically not in use is poor practice and added bloat and DOM size as well. This hidden block is also loaded on all pages with or without the widget placed on the page. Why even have a whole #addtoany div block of hidden items when it knows those settings are disabled?
Thanks for taking the time to review and improve.
The topic is being corrected because it’s incorrect. AddToAny is fully compliant with the latest WCAG.
Your unrelated argument is another non-issue. AddToAny measurably aces all categories of concern for site owners and end-users, including performance, accessibility, best practices, and SEO.
