This question is about Accessibility.
Here is my code:
<a href="https://example.com/url-to-details">
<img src="https://example.com/item.png" alt="some description">
</a>
some description
It's not perfect, as we know we should avoid Adjacent links go to the same URL (this is what the WAVE accessibility tool says for me on my webpage about this piece of code).
With another words, the problem here is you use th Tab key consequently and still appear on the same link. This is not perfect.
My solution is to set tabindex="-1" for one of the links.
So, my questions are:
1. is it a good idea, or you have a better approach?
2. Which code is better from the Accessibility point of view:
<a href="https://example.com/url-to-details" tabindex="-1">
<img src="https://example.com/item.png" alt="some description">
</a>
some description
or
<a href="https://example.com/url-to-details">
<img src="https://example.com/item.png" alt="some description">
</a>
some description
P.S. There is a 3rd approach: to unite two <a></a><a></a> into one such as <a> picture + some description</a>, but I would avoid it for some reasons.
P.P.S. The description text "some description" is equal for both the image description and the text in the anchor tag.
I don't see a use case for having both an image link and an adjacent textual link that use the same URL. It should be a single link, so you have three options:
get rid of the image link,
get rid of the textual link,
combine the image and the text into a single link, where the image has an empty alt attribute:
<img src="https://example.com/item.png" alt=""> some description
In the third case, the alt attribute should be empty in order to avoid duplication of text (screen reader users don't want to hear the link text twice). This also results in simpler code that does not rely on tabindex="-1". See also WCAG Technique H2: Combining adjacent image and text links for the same resource.
Note that using two adjacent links, both with the href attribute and one of them having tabindex=-1, as proposed in the question, will result in both links being listed in a screen reader's list of links. This duplication should be avoided.
Assuming that your alt description should be equal to your link text is a misguided approach, in my opinion.
Let's say you are designing a products list page for an online store.
If the link goes to a product detail page, then the link text should describe that detail page. However, the image alt should describe the image itself, not the detail page.
.link {
display: flex;
flex-direction: column;
align-items: center;
}
<a class="link" href="https://www.mywebsite.org/detail-page-100">
<img class="link-img" src="https://picsum.photos/200" alt="2 puppies running through a meadow in the summer sun">
<span class="link-desc">Buy organic pet food - 5kg</span>
</a>
The tabindex only changes the keyboard order, but screen reader will still announce the same link twice.
Making the img clickable using javascript will avoid annoying keyboard users or screenreader users, letting mouse users click on the image itself.
From a purely WCAG accessibility point of view, nothing has to change in the original code. That fact that WAVE points it out is just an artifact of that tool. It's not an error, but an "alert" (in WAVE terms). The doc for WAVE says this about "alerts":
The goal should not be to get rid of all icons, except for the errors. Alerts will require close scrutiny - the[y] likely represent an end user issue.
The key being that alerts are "end user" issues, meaning usability or user experience issues. Not accessibility failures.
So, if you're trying to comply to WCAG AA, having a redundant link is not a failure and does not have to be fixed. But if you're looking at the user experience, reducing the number of tab stops and links that point to the same destination is always a good thing.
How you fix that issue seems to be the crux of the OP. When two links that are adjacent point to the same location, the best way is to combine the links into one. Adding tabindex="-1" to one is generally a bad idea because that only affects keyboard users and not screen reader users.
I would keep them both, because if a person using a screen reader is tabbing through your website you would like them to hear the image description as well as the text in the anchor tag.
The correct answer is - it depends.
If your image better describes your link, then use the image.
If your anchor tag better describes it - then use the <a>.
Some info for tabindex
Please see all the accessibility you can add to a link here
Related
I have be rewriting my website to be accessibility friendly and have a really good handle on good behavior, but I'm having a problem with the following pattern:
I have a list page of blog entries that I am trying to remove a duplicate link alert for (I know it's just an alert, but it's right to alert me).
<article>
<a href="destination">
<img src="decorative picture.jpg" alt="">
<h2>Blog entry title</h2>
</a>
<p>Summary of blog post and other meta info about the post</p>
<p>
<a href="destination" class="btn btn-details" tabindex="-1"
aria-label="Continue reading about Blog Entry Title">
Continue reading
</a>
</p>
</article>
The usual pattern discussed is when you have an image and title together (solved), but what should I do with the "continue reading" part? It is not, nor should it be, near the image/title, but it really is redundant. I thought about either making the link or the surrounding paragraph aria-hidden="true" because "Continue reading" is really stylistic, someone in a screen reader would know to click the link above, but I know we're not supposed to put links in a hidden context. I thought tabindex="-1" would solve that problem, but there is still a link there, it's just not focusable and is weird for visual navigators because they can't tab to it.
I found the following article, which makes me wonder if I should remove tabindex and use aria-labeledby to bring some semantic connection to the previous link?
<article>
<a id="md5-hash-of-destination" href="destination">
<img src="decorative picture.jpg" alt="">
<h2>Blog entry title</h2>
</a>
<p>Summary of blog post and other meta info about the post</p>
<p>
<a aria-labeledby="md5-hash-of-destination" href="destination"
class="btn btn-details">
Continue reading
</a>
</p>
</article>
What is the optimal way to "eliminate" the entire Continue reading link to give the best UX to people who use screen readers et al?
I think the key to your question is at the very end where you're asking about the UX since the code you have is technically accessible according to WCAG.
Having two adjacent links go to the same destination isn't ideal but it's not a horrible UX either. Users with mobility issues will have two tab stops to navigate through for each article, which can be draining for some assistive technology such as a sip-and-puff device.
I'm not sure I see the need for the "continue reading" link at all. Hearing the blog title and that it's a link, then a summary afterwards seems sufficient. What benefit is the "continue reading" link? I suppose my question might be better asked on https://ux.stackexchange.com/.
If you have to keep the second link for whatever reason, you definitely don't want tabindex="-1" on the link. That would give you a link that mouse users can click on but keyboard users couldn't. Technically, that's not a failure of WCAG 2.1.1 since that guideline says that all functionality of the page must be available to keyboard users, and since your first link is available, having the second link unavailable doesn't fail.
But if you shouldn't have tabindex="-1" on the link, then you shouldn't have aria-hidden="true" either. As you said, interactive elements should not be aria-hidden.
If you really want to keep the second link, my first choice is just leave it as is. If you only want one link clickable, then perhaps make the entire <article> a link. That would cause the blog title and the blog summary/metadata and the "continue reading" to all be read as the link name. That makes for a pretty wordy link, which isn't a great UX either.
So I'm not sure you have a win-win situation. My first choice is to remove the second link completely. The "continue reading" doesn't seem to have any benefit.
Your second code example is not much different from your first. You changed the label of the second link so it ends up being less accessible than your original code. You'll hear "blog entry title" as the name of both links. The "continue reading" will not be announced because you're overriding the link text with the aria-labelledby.
The image inside this anchor tag throws a "Linked image missing alternative text" error in the WAVE accessibility checker:
<img src="google.jpg" alt="" />
You can't have a decorative image being the sole element of a link. This image is a link, it's not decorative.
<img src="google.jpg" alt="" />
When an image is the only content inside the link, its alternative should contain the link destination description.
In other cases, adding the role="presentation" would have been sufficient to explicitely state that you willingly wanted a decorative image which is not the case here.
Support for the title attribute in screen readers and other assistive technologies is extremely limited; it is also useless for sighted keyboard users.
See for example,
Don't Rely on the Title Attribute for Accessibility (2016)
Using the HTML title attribute – updated (2013)
If a link contains only an image and no text, the content of the alt attribute constitutes link's "link text", i.e. this is what a screen reader will announce when the link receives focus. For this reason, the alt attribute cannot be empty in this case. You need something like the following:
<img src="google.jpg" alt="Google" />
If you include actual text next to the image, as in the following example, you can leave the alt attribute empty:
<img src="google.jpg" alt="" />Google
In the last example, the image can be treated as a decorative one, due to the presence of proper link text. If the string Google were included in the alt attribute, it would be announced twice by a screen reader.
Adding a title attribute to the link is not a great idea for the following reasons:
It is useless to sighted keyboard users who cannot hover the mouse pointer over the link.
Screen reader support for the title attribute is not entirely consistent, as can be seen from the test results A "click here" link with TITLE attribute: Screen reader compatibility (last updated in April 2019). Adding the attribute title="google link" to the above examples would just lead to needless repetition in those screen reader and browser combinations that actually support that attribute on links.
Trying to figure out why a Lighthouse audit flagged a bunch of my links as failing the elements have discernible names
<h3>
My New Post Title
</h3>
My question is do all links need aria-labels because I thought if it's just a normal link the text inside the link is what is required?
Or is there something else going on with the structure of my markup? Another flagged element is this one:
<a class="custom classes" href="https://...">
<div class="custom classes" style="background-image: url('https://...');"></div>
<div class="article-thumbnails-small__title">Post Title</div>
</a>
For that one I understand that the a has no text so the aria-label should go on the div with the actual post title, correct?
SOLVED
I was looking at the wrong element... Have a nice day.
Both of your examples are fine and should not be flagged. Something else must be going on. Is the code you posted exactly what was being tested?
ARIA attributes should be used sparingly and are only meant to be used when native markup isn't sufficient. For links, as you said, if there's any text between the <a>...</a>, then that's "discernible text".
If the link doesn't have any direct text but if a child element does, then you're also ok, such as your second example. The <a> doesn't have text but the second <div> has "Post Title". All the child elements of the <a> are considered when looking for the "discernible text". When I tab to that link, I'll hear "Post Title, link" from a screen reader.
However, CSS can affect this. If your class="article-thumbnails-small__title" on the second <div> has a display:none or visibility:hidden, then that text will not be discernible because it's hidden.
If the class has width/height:0px, then it might not be discernible either. Sometimes 0 sized elements are considered hidden.
If your link does not have text but has a nested <img>, as long as the image has alt text, then you're ok.
Good:
<a href="foo.html">
<img src="foo.jpg" alt="foo">
</a>
No Discernible Text:
<a href="foo.html">
<img src="foo.jpg">
</a>
The aria-label attribute on links (a elements with a href attribute) should only be used when, for whatever reason, it is not possible or not desirable to use perceivable link text. (This includes the alt attribute in image links.) If you have normal link text, you should not use the aria-label attribute because that attribute would override the link text. See step F of the text alternative computation in the document Accessible Name and Description Computation 1.1: the a element has an inherent role that allows the computation of its name from its content (i.e. the link text and/or the alt attribute on an img in the link). However, this step is only followed if there is no aria-label attribute on the link element (see step C.
See also Principle 2: ARIA Can Both Cloak and Enhance, Creating Both Power and Danger in the WAI-ARIA Authoring Practices 1.1, which points out that ARIA sometimes overrides the original semantics or content, citing aria-label as an example.
So if Lighthouse flags links with perceivable link text and no aria-label attribute, there must be something else going on, such as CSS that hides elements.
Lets say the alt text of an image is too long and the image is linked as in below
<a href="http://somelink.com" title="">
<img src="someimage.png" alt=""/>
<p class="hide_text">The complete alt text here as in too long to have any meaning to put in the title/alt above. Then is it accessible enough to put in the p tag?</p>
</a>
And I just hide the p text. Is that WCAG 2.0 AA accessible compliant then? If both title and alt is empty in such case and I include the image alt text in the p...is that WCAG 2.0 AA accessible?
If an image is the only element inside an anchor tag, its alt text would need to describe the link's destination rather than the image itself. If this description is too long, then it may be worth asking yourself whether this is appropriate.
This is a border-line WCAG pass/fail. The image could be said to fail 1.1.1 (non-text content) because it's not decorative but has no alt text. But the link itself would likely pass because the hidden text makes its destination programmatically determinable.
There's two reasons why I wouldn't use this approach:
Hidden text might not be available to access technology on all devices. I've seen this happen using VoiceOver on the iPhone.
Speech recognition users may have trouble clicking the link if seeing the image with no accompanying text doesn't give them enough info about how to instruct the recognition software to click the link.
So in conclusion I'd use alt text, try to pare it down to a short description of the link's destination, and ensure that it's obvious from the image content how to click it using speech recognition.
The best option in my case I have found is to use something like below
<a href="http://somelink.com" title="">
<img src="someimage.png" alt=" "/>
<p class="hide_text">The complete alt text here as in too long to have any meaning to put in the title/alt above. Then is it accessible enough to put in the p tag?</p>
</a>
Put a space in the alt . So that when NVDA reads it, it is read as Link graphic link "The complete alt text here as in too long to have any meaning to put in the title/alt above. Then is it accessible enough to put in the p tag?"
Seems to be ok. I am just not 100% certain if I am violating any WCAG rules.
It is not WCAG AA compliant because if you put a title attribute on a A tag, it can't be empty.
And I just hide the p text.
You can hide it as long as the screen-readers can read it (so no display: none)...
It might be WCAG AA compliant from many people's view, but you have to remember that not all people use a speech synthetizer and that such invisible information should be made available for everybody.
Also, link text should be as short as possible.
I'm wondering how to format my code. which one is better?
<a href="http://stackoverflow.com">
<img src="http://localhost/g3.jpg" alt="" height="90" width="150">
Q&A for professional and enthusiast programmers
</a>
OR
<a href="http://stackoverflow.com">
<img src="http://localhost/g3.jpg" alt="" height="90" width="150">
</a>
Q&A for professional and enthusiast programmers
I would definitely go with the first one unless you have a specific reason for having two links. Don't think about it in terms of proper coding style, but rather what makes sense usability-wise.
Note that you also have the option to only use the text in the link, and set the image as the link's background-image property in CSS. In many cases, that's exactly what I would do unless the image itself is essential to understanding the link.
In cases like this, the best thing is to think, "Which HTML structure most accurately represents how I want a user to perceive this element?"
It all depends on what you want to get :
If you only want one link (which, I suppose, is the case, here ?), then go with the first solution
If you want two distinct links (not sure why you'd want that here, as both point to the same location), then go with the second solution.
Here, you want the <img> and the text to link to the same page -- so, I'd say it's more logical to only use one <a>
The first one makes more sense to me (since you want both image and text to be part of the link, i see no reason to make two links).