Problem/Motivation
Sites using the AddToAny JavaScript share button widget are flagged by WebAIM WAVE and other accessibility tools due to a broken same-page link:
Broken same-page link
A link to another location within the page is present but does not have a corresponding target.
The offending markup typically looks like this:
<a href="#addtoany" id="a2apage_show_more_less" class="a2a_more a2a_localize" title="Show all" data-a2a-localize="title,ShowAll">
<span class="a2a_svg">...SVG Icon...</span>
<span class="a2a_localize" data-a2a-localize="inner,More">More…</span>
</a>
There is no corresponding id="addtoany" target in the DOM, so the link destination is invalid, which violates WCAG success criterion 2.4.4 (Link Purpose) and potentially 1.3.1 or 4.1.2.
Proposed resolution
Either suppress the warning by ensuring a DOM element with ID "addtoany" is always present or (better) implement a proper fix following known ARIA Patterns.
Option 1: Quick fix (suppress the warning)
Dynamically inject a hidden target element into the DOM so the link reference resolves:
<div id="addtoany" hidden aria-hidden="true"></div>
This removes the warning from accessibility scanners without changing the behavior of the widget. However, this is not a semantic or fully accessible solution—only a way to suppress notifications from validators.
Option 2: Proper fix (ARIA-compliant behavior)
The correct semantic approach is to replace the <a> element (used as a button) with an actual <button> element (styled appropriately to avoid visual regressions), and use an ARIA Disclosure pattern:
<button
id="a2apage_show_more_less"
class="a2a_more a2a_localize"
aria-expanded="false"
aria-controls="a2a_share_panel"
title="Show all"
data-a2a-localize="title,ShowAll">
<span class="a2a_svg">...SVG Icon...</span>
<span class="a2a_localize" data-a2a-localize="inner,More">More…</span>
</button>
<div id="a2a_share_panel" hidden>
...expanded share UI...
</div>
JavaScript should toggle aria-expanded and hidden on interaction. This follows the
WAI-ARIA Disclosure pattern, providing proper semantics for assistive technology.
User impact
Screen reader and keyboard users may experience confusion due to broken link behavior. This also introduces accessibility errors that may block site compliance checks.
Remaining tasks
- Decide upon the best approach.
- (ideally) fix this in the upstream addtoany library.
- if cannot/will not be fixed upstream, write a patch for the Drupal module to suppress the warning
User interface changes
None, unless AddToAny maintainers choose to implement the full semantic fix, which would improve accessibility and interaction behavior without visible UI difference.
API changes
None.
Data model changes
None.