Accessibility: Is the aria-label text too redundant?

[yellowled]

Someone just notified me that the aria-label for the anchor links is kind of redundant in screenreaders.

For example, if I use a heading <h3>My heading</h3>, the anchor link for that will get aria-label="Anchor link for: my heading", which seems to (I'm not a screenreader user myself) be read as something like “Heading level 3 My heading Anchor link for: my heading" in at least some screenreader/browser combinations.

My suggestion would be to reduce the default aria-label to something like “Permalink”, “Link to this” or something like that? Also, you might want to make this label text configurable for i18n.

[bryanbraun]

Thanks for the heads up.

The reason I set it up like this in the first place is that a permalink isn't useful unless you know what you are linking to. The scenario I wanted to avoid was screenreader-users hopping around a page, finding permalinks but not knowing what they link to (since they can't use visual closeness of the link to provide that context). In short, erring on the side of providing more information.

It's hard to say whether that redundancy has costs outweighing the benefits, especially since neither of us are regular screenreader users.

If I got enough feedback from screenreader users that the redundancy is distracting/unnecessary, then I'd pull it out. Any chance you know anybody like that who can provide feedback?

I'll like to leave this issue open for a while to collect that kind of feedback, if anybody has it.

[MarcoZehe]

Hi! @yellowled and I just discussed this issue over e-mail, and of course the most obvious idea came to me after we had basically finished our back and forth.

I am a screen reader user and also find this redundant information distracting when the heading is read. 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. OK, it would follow right after the link, but at least it would reduce the chattiness when just reading the heading. Or you could put it directly before the heading, so screen reader users would come across it while reading the page top to bottom, but not if jumping directly to a heading. Some experimentation might be in order here. This is the first time someone has asked me about this particular technique, so I am not aware of any long-term proven solution yet.

I heard from Matthias that Github does this, too, but I am not sure where exactly this is. The comments (like in this thread) all have a permalink to themselves within the text that is the timestamp when the comment was posted, so the problem getss avoided that way, and no redundant text is given.

Hope one of these ideas helps!

[MarcoZehe]

Ouch, sorry for the bad formatting! I didn't think Github would interpret that HTML snippet directly from within the text. :-(

[yellowled]

Adding a summary of what we discussed before for @bryanbraun for consistency. @MarcoZehe, please correct me if I got something wrong.

• 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 …? I assume this is why GitHub uses aria-hidden="true" to hide anchor links.
• But apparently it is not a good idea to use aria-hidden on a focusable element because that messes with the ability to tab through the page or something. (Not sure if I got that right, kind of hard to understand not being a screenreader user.)
• A better solution would be to not add the anchor link to the heading but instead wrap the heading in the anchor link. Of course, that is visually not very desirable.

[yellowled]

@MarcoZehe GitHub does this in Markdown documents like the README.md that many GitHub projects use. See for example https://github.com/bryanbraun/anchorjs#anchorjs-

[bryanbraun]

Thanks for the feedback @MarcoZehe and @yellowled.

There are some complications with wrapping the heading in the anchor link, especially since these links are designed to be used in more places than just headings (like paragraphs). Wrapping the link in cases like that could result in links within links... not a good situation.

I see your point about the links being fairly useless for most screenreader users, and I'm interested in Github's approach of simply hiding them (especially because it looks like older versions of their site didn't hide them with aria-hidden). It might be a good idea to look at some other major sites to see if they treat them similarly.

For reference, I looked up some of the downsides of having focusable elements with aria-hidden="true" and I'd like to not introduce those issues if possible. We may be able to avoid them with tabindex="-1", but I could see that bringing unintended consequences as well.

One option we haven't mentioned yet is to just make the permalink text as succinct as possible, making it say something like "Permalink". That would reduce the redundancy of repeating the title twice, while not introducing the complexities of hiding it. Thoughts on that?

[MarcoZehe]

One option we haven't mentioned yet is to just make the permalink text as succinct as possible, making it say something like "Permalink". That would reduce the redundancy of repeating the title twice, while not introducing the complexities of hiding it. Thoughts on that?

That would work for me.

[yellowled]

It might be a good idea to look at some other major sites to see if they treat them similarly.

I never noticed since I still use a feed reader, but Smashing Magazine also has these links. Seems like they use just “Link” as the link text (which is replaced with a PNG image) and an aria-label which says “Link to section <title of section>”.

[bryanbraun]

That's interesting about Smashing's. Their aria-labels look a lot like ours:

I'm still leaning towards @MarcoZehe's recommendation to make it less redundant by shortening it, but I'd like to keep my eyes open for other examples for a bit just to see what else is out there.

(for the record, I found a couple examples that don't use any aria attributes, like Read the Docs and Anchorific, though I'm more inclined to believe that it's due to oversight rather than deliberate choice). Thanks for your assistance and patience, both of you!

[RichCaloggero]

Shorten the aria-label

Perhaps just the word "anchor" would work; even shorter than permlink, and makes more sense.

I first noticed this on bootstrap's site; it is extremely distracting, especially when you simply want to read a long document straight through (screen reader's have a say-all feature that lets you start at a certain point and then simply read until you say stop). Each time it comes across a section heading, it is read as something like:

• Hover examplesAnchor link for: hover examples
• Advanced usageAnchor link for: advanced usage
• OptionsAnchor link for: options

The above were taken from the anchorjs docs: https://www.bryanbraun.com/anchorjs/#examples

Thanx.
-- Rich

[bryanbraun]

@RichCaloggero, thanks for your input and the example you shared. That description makes it easier to understand what people are experiencing.

I've let this issue sit for a bit, but now's a good time to pick it back up and make a decision. It sounds like everyone in the discussion is on board with shortening it and your input confirms that approach. I'm ok with your suggestion of simply calling it "anchor".

I'll put together a PR.

[bryanbraun]

☝️ PR is up. If anybody has feedback, let me know in the next couple of days, after which I'll merge.