Hiding duplicate links with aria-hidden

Question

I know that in theory you shouldn't hide active elements... But... What if the link is repeated twice?

To clarify the link is on the picture which has no additional information value. A separate link is on a text and the url is the same as on the picture. The problem is that the picture is a separate component for the text link. So I can only surround the picture with an element (div). I have limited options to change the structure of the picture component.

It seems to me that the UX of a person with a screen reader will be better if redundant links are hidden. Formally, however, it is not recommended. Not sure what to do?

Rough structure is something like this:

<div role="listitem">
 <div aria-hidden="true">
  <fileComponent name="Wikipedia-logo.png" link="w:Some article"/>
 </div>
 <p>
  <linkComponent url="w:Some article" label="Wikipedia"/>
 </p>
</div>

I have the option to add alt to fileComponent, but not more advanced attributes.

PS: To give more context... Actual code is from Wikipedia. And to clarify I do want links on both the image and text.

<div role="listitem">
<div aria-hidden="true">[[Plik:Wikipedia-logo.png|50px|link=w:]]</div>
<p>[[w:|'''Wikipedia''']]</p>
</div>
<div role="listitem">
<div aria-hidden="true">[[Plik:Wikiquote-logo.svg|50px|link=q:]]</div>
<p>[[q:|'''Wikiquote''']]</p>
</div>

Answer 1

aria-hidden will indeed hide the element from screen readers and will prevent the user from navigating to it with the screen reader (such as using the down arrow) but does not prevent the user from navigating to it with the TAB key (since links are inherently keyboard focusable). This means a screen reader user could TAB to the hidden link but nothing will be announced because the element was removed from the accessibility tree.

That's bad.

To prevent TAB, you'd need tabindex="-1". However, that will prevent sighted keyboard users from navigating to it. That might be a good thing as you'll have fewer tab stops, but if something looks like a link, then I'd expect to be able to TAB to it.

It's always best to reduce/eliminate duplicate links, especially when they're next to each other in the DOM, but that's mainly a best practice and doesn't necessarily make for a horrible user experience (unless, I suppose, you have 50 links on the page and they're all duplicated).

Duplicate links are not a WCAG failure.

I commend you for trying to make the UX better for some users but this is a case where you don't really have to "fix" it. Screen reader users have lots of shortcut keys for navigating the page. Interestingly enough, navigating with the TAB key is not the most common way to navigate, so many screen reader users will not run into the duplicate link problem. They will often navigate with G to jump to each image ('graphic') or U to go to the next unvisited link (NVDA allows K to go to the next link).

Most screen readers allow the user to display a dialog with a list of links on the page. You'd have duplicate links in that dialog if you don't hide the duplicate link. If you can't change your page structure to combine the picture and the text into one link, then it's a UX you'll have to live with. It's more of an annoyance rather than a blocking behavior, so that's a minor silver lining.

In general, you can't really hide an interactive element from just screen reader users. In order to do so, you have to "hide" the TAB too, which makes it "hidden" for sighted keyboard users.

Answer 2

To support screen readers, use aria-label to provide an article description similar to the visual description the image provided.

Put aria-label attribute in the role="listitem" DIV:

<div aria-label="Describe the article in some detail." role="listitem">
 <div aria-hidden="true">
  <fileComponent name="Wikipedia-logo.png" alt="brief description of image" link="w:Some article"/>
 </div>
 <p>
  <linkComponent url="w:Some article" label="Wikipedia"/>
 </p>
</div>

(Unrelated to question but added alt attribute to fileComponent, which presents an image, for good measure.)

The aria-hidden="true" DIV—along with it the fileComponent tag—is hidden but the role="listitem" DIV presents the description provided in the aria-label attribute to the screen reader.

From W3C Using ARIA, Practical Support: aria-label...:

Don't use aria-label or aria-labelledby on a span or div unless its given a role.

Since the role="listitem" DIV has a role aria-label is appropriate.

---

There are two approaches to consider here:

1. User-focused
2. Media-focused

User-focuced

The above example is user-focused—rather than merely describing the image, a textual description is designed and written to do the job of the image.

With a user-focus, media is selected, designed and developed according to the tools or inputs the user uses to access the information. Consider the various users you are presenting to and design and develop media "packages" tailored to each of their receptive capabilities.

If a conventional browser is the presentation device then text, images, animation, videos, audio can be use to present the information. When a screen reader is used you are relying on text being converted to speech to present the same information to the user.

By taking the user's perspective when developing the presentation you're not describing the image, but instead doing the job of the image with text.

Media-focused

Alternatively, wrap the aria-hidden="true" DIV with a role="img" DIV including a aria-label attribute:

<div role="listitem">
 <div role="img" aria-label="Detailed description of image—for screen readers.">
   <div aria-hidden="true">
    <fileComponent name="Wikipedia-logo.png" alt="Brief description of image—for browser preload, missing image, and other support tools." link="w:Some article"/>
   </div>
 </div>
 <p>
  <linkComponent url="w:Some article" label="Wikipedia"/>
 </p>
</div>

In this case, and admittedly being simpler and having lower development costs, is to develop the media for users with full, or slightly limited receptive capability such as color sensitivity, then provide alternative text descriptions for each media component to be read by the screen reader.