Duplicate 'Anchor' links aren't accessible

[dotherightthing]

No description provided.

[dotherightthing]

When viewing the page in Safari, the screen reader 'VoiceOver' can access a list of all the hyperlinks on the page:

As you can see, there are multiple entries for 'Anchor'.

The text 'Anchor' is derived from the aria-label attribute on the injected anchor links:

<h2 id="advanced-usage">
    Advanced usage
    <a class="anchorjs-link " aria-label="Anchor" data-anchorjs-icon="" href="#advanced-usage" style="font: 1em / 1 anchorjs-icons; padding-left: 0.375em;"></a>
</h2>

This text is repeated for each heading. This makes it difficult for a screen reader user to differentiate between the different 'Anchor' links on the page.

[dotherightthing]

You can verify this in Chrome by checking the 'Accessibility' tab:

[stphnwlkr]

@dotherightthing I noticed the same thing. The single static value should not be an option (IMO). I downloaded the code and replaced the 'Anchor' value with

anchor.setAttribute('aria-label', "reference link to "+elementID.replace(/-/g, ' '));

Not sure if this is sufficient or if the "reference link to" will be understood

[bryanbraun]

Hey @dotherightthing, 👋 .

AnchorJS originally did differentiate between anchor links as you described (by default the aria-label was "Anchor link for: My heading"). We ended up moving away from that approach after some conversations with screenreader users who felt it was too redundant. The full background conversation for the decision can be found here but here's a quick summary of the options:

Options:

Option 1: Static label ("Anchor")
Option 2: Dynamic label ("Anchor link for: My Heading")

Voiceover reading when navigating by headings:

Option 1: "My Heading, Anchor"
Option 2: "My Heading, Anchor link for My Heading

Voiceover reading when navigating by links:

Option 1: "Anchor"
Option 2: "My Heading, Anchor

Your suggestion, Option 2, reads better when screenreader users are navigating by link but it's arguably more redundant/distracting when screenreader users are navigating by heading. Ultimately it's a tradeoff between two different ways of navigating, and given that we've had screenreader users state a preference for option 1, I'm comfortable with that approach for now. Happy to reconsider though, if we've overlooked something here!

[dotherightthing]

@bryanbraun Thanks for your thorough reply.

I read through the linked issue and have a few thoughts:

The anchor links are actually pointless for most screenreader users. Screenreaders use headings to generate a table of contents for quicker page navigation anyway. I guess you could say that screenreaders already do what AnchorJS does …?

In my view, the goal of the heading anchor link is not to allow the user to quickly jump to a heading. If this were the case then a list of jump links targeting heading IDs would accomplish this, and mirror the element lists that screen readers produce to reduce the number of navigation keystrokes.

IMO The goal of the heading anchor link is to allow a user to bookmark a certain section of the page, by adding the heading/fragment ID to the URL as a hash. Now when they share the URL they can also share the section of interest (sharing mechanism notwithstanding).

Maybe auto-updating the URL with the fragment and adding some sort of floating section-share button is a better solution in that case?

An idea that just came to me was to move the link outside the tag, directly after it. That way, when screen readers jump to the heading (which we usually have a direct screen reader shortcut for), the heading would be read, but the link would not.

An interesting suggestion and one that Amber Wilson initially took on https://amberwilson.co.uk/blog/are-your-anchor-links-accessible/.

A better solution would be to not add the anchor link to the heading but instead wrap the heading in the anchor link.

Interestingly, I talked to a disabled support worker last year. She lamented the fact that many websites didn't link their headings, making it harder for her clients to navigate through long pages.

AFAIK there's nothing in HTML5 or WCAG that says that we should link our headings. But how should I tell an end user that their learned behaviour is wrong? This is where UX gets interesting because we have to weight up what's 'right' with what's 'useful'.

given that we've had screenreader users state a preference for option 1

On that note, it's great that Marco Zehe is weighing in with some accessibility guidance. But consider that Marco has been working in the Assistive Technology industry since 1996. That means he's likely far more tech savvy than a kid struggling to do their schoolwork (see Cody's https://eyetvision.com/) or a retiree who has lost some or all of their vision due to ageing.

AFAIK new screen reader users learn the ropes by reading the manual just like everyone else. That means that while some people will surf headings, others will be stuck using the tab key. Others might have the screen on massive zoom. The user may or may not be legally blind. A screen reader may or may not be involved. The user may only use the keyboard, or also use the mouse, or use a keyboard proxy like a switch, or any other combination of AT.

Addressing screen reader issues is important. Reliance on screen reader specific fixes like aria-label is risky. Making assumptions is also risky. Extra navigation isn't necessarily redundant.

Anyway, just some food for thought. I'm actually investigating a few different solutions for use in my own plugin (https://github.com/dotherightthing/wpdtrt-anchorlinks) which I use on my own blog. I'll refer back to this issue when I get back into development.

[stphnwlkr]

@bryanbraun thank you for the background information. I am not a JavaScript person by any stretch of the imagination so I will ask, how hard would it be to provide options to either choose static or dynamic label (I really like option 2) or even opt for aria-hidden? @dotherightthing In my mind, the latter would give the keyboard functionality while hiding the redundancy from those skilled in screen reader technology.