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).
Related
I am currently studying the web accessibility guidelines that concern HTML5.
Concerning images, I am currently adding images in HTML as follows:
<!-- Normal Images -->
<img src="https://placeholder.pics/svg/300x300" title="Image Placeholder" alt="Image Placeholder" aria-labelledby="Image Placeholder" width="300" height="300">
<!-- Decorative images -->
<img src="https://placeholder.pics/svg/100x100" role="presentation" aria-hidden="true" alt="" width="100" height="100">
Is it recommended by WAI-ARIA to add both aria-labelledby and alt tags together for normal images? or is there something else that I should adopt?
Do I need to add role="presentation", aria-hidden="true", and alt="" to every decorative image? All three of them should go together? or only one of them? (if only one or two of them then which ones?)
Is it a good practice to add both aria-labelledby and alt tags together for normal images? or is there a better practice that I should adopt.
aria-labelledby
No, in fact adding aria-labelledby and alt together will result in some screen readers reading the name twice. Just use an alt attribute, that is what it is there for, it has the widest support (100%) and will do the job just fine.
Also aria-labelledby requires at least one element in the DOM that contains text, you reference it by ID. You can have more than one label too just for reference. It is designed to be used on other elements that can't be labelled using semantic HTML, not really for images (there are always exceptions but they are rare and this is general guidance).
e.g.
<span id="ID1">Read First</span>
<span id="ID2">You can add a second label that will be read second</span>
<div aria-labelledby="ID1 ID2"></div>
title attribute
Also don't use a title attribute unless you are planning on making it the same as the alt attribute. Otherwise mouse users get a different experience to screen reader users as the title attribute is not accessible to most screen readers. See this in-depth answer I gave about the title attribute and how to roll an accessible version if you want to use it.
accessible image example
So your final, accessible image would look like this:-
<img src="https://placeholder.pics/svg/300x300" alt="Image Placeholder" width="300" height="300">
Perfectly accessible and easy to maintain.
Do I need to add role="presentation", aria-hidden="true", and alt="" to every decorative image? All three of them should go together? or only one of them? (if only one or two of them then which ones?)
alt attribute
All you need to do is add an empty alt attribute. Notice how I said empty and not null.
e.g. alt="" NOT just alt. Using alt as a null attribute will result in it being ignored by some screen readers so the file name will get read out.
role="presentation"
For completeness you can add role="presentation" but it will not add any extra support as far as I am aware.
With that being said I personally add role="presentation" to decorative images as our unit testing will flag any empty alt attributes unless this is added. This was a deliberate decision so when we run tests we don't keep checking the same empty alt attributes are correct.
As support for empty alt attributes is also at 99/100% it is also perfectly valid and accessible to just use alt="".
aria-hidden
The only place (well the main time, there are always exceptions) where you would want to use aria-hidden on an external image is if you are going to dynamically hide and show it. Some screen readers monitor WAI-ARIA changes better than DOM changes.
aria-hidden and inline SVGs
I would recommend adding aria-hidden="true", role="presentation" and focusable="false" on inline SVGs that are purely decorative though as Internet Explorer can sometimes allow them to be focused.
Note that you don't use alt attributes on inline SVGs anyway.
decorative images examples
So your final decorative image would be:-
<!--all image types loaded externally using `img` including SVGs-->
<img src="https://placeholder.pics/svg/100x100" alt="" width="100" height="100">
<!--exception for inline SVGs due to focus bug in IE-->
<svg aria-hidden="true" role="presentation" focusable="false">...</svg>
final note on WAI-ARIA
WAI-ARIA is there to provide information when there is no semantic way to do so.
Adding extra WAI-ARIA all over actually makes accessibility worse. You should always start with 'is there a native way to give the information to a screen reader', if there is, WAI-ARIA is not needed or in fact recommended.
After Thought
I mentioned inline SVGs not using the alt attribute, instead you want to use <title> as part of the SVG. Read this quick article on accessible SVGs for a quick overview.
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
I'm trying to use the <a> tag in HTML5 more as a container as this tag can now have block elements as children, example:
before (valid XHTML 1.1)
<div>
<h3>
article title
</h3>
<p>
text
</p>
<a href="page.html" title="article title" >
<img alt="image">
</a>
<a href="page.html" title="article title" >
read more
</a>
</div>
after (valid HTML5)
<a href="page.html" title="article title" >
<h3>
article title
</h3>
<p>
text
</p>
<img alt="image">
<div>
read more
</div>
</a>
Does this new way of markup have any effects for SEO?
OK, removing pure semantics from your question (which, in my mind, does have a material impact on deciding on implementing your chosen method) and concentrating on pure "SEO" value and impact:
The first example needs to be qualified more, as if we take your example as literal, then you are linking to the same page.html 3 times. Google (specifically) only takes the link anchor value from the 1st link to any page that it comes across, so - the value for the first example is only extracted from that first link. The 2nd link (using an IMG tag with an ALT attribute as the anchor value), and the 3rd link using read more as the anchor value are effectively "ignored". It's important that other signals are used to supplement the first link's true intended value, such as surrounding text, images etc.
The 2nd example (HTML5), wraps all of that semantic/surrounding content up to make the effective 'anchor' value from which search engines will derive the link's intended meaning, and then as a consequence, the meaning of the destination page of the link.
Using an anchor tag as a containing wrapper for content that contains additional emphasis (the H tag), an image and an additional div only increases the difficulty that a search engine has to decipher the intended meaning of the link so it can associate it with the destination page.
Search engines (and Google predominantly) are constantly improving their crawling ability to enable better algorithmic parsing and processing of the HTML. Apart from emphasis signals (which are very low), Google mostly ignores the mark-up. The exception is of course links - so making an effort to simplify the parsing/processing by providing clear signals as to a link's anchor text is the safest way forward. Expecting them to understand all of the differences of HTML3, vs HTML4, vs HTML5 and all of the transitional, strict and other variations of each, is probably expecting too much.
TL;DR
Possibly, but only in terms of true link value.
As far as i know in the second way is not bad in anyway in term of seo But first may be slightly better as the titles,images are more closely linked to link.
Q. But better by how much?
A. May be not too much
Given the following link to an image:
Title
What is the most semantically sound method for indicating the location of a thumbnail?
The best I could come up with so far is using data- attributes like so:
Title
However, it doesn't seem very semantically sound. Is there a better or more correct way to do this?
Why not use an <img> element? You can give it a class to indicate that it's a thumbnail and hide it with progressive enhancement if you need to. That way, the thumbnail of the image will be shown in the absence of JavaScript/CSS:
<a href="path/to/img.jpg">
<img src="path/to/thumbnail.jpg" class="thumb" alt="Thumbnail" />
Title
</a>
Or am I being too naïve?
Title
Simple and keeps the original path intact while just adding a suffix to indicate that the image is a thumbnail. We use this all the time on our sites and it makes things easy.
This might be a stupid question but if there's a better or proper way to do this, I'd love to learn it.
I have run across this a few times, including recently, where small spaces show up in the rendered version of my HTML page. Intuitively I think these should not be there because outside of text or entities the formatting of a page's HTML shouldn't matter but apparently it does.
What I'm referring to is this - I have some Photoshop file from the client on how they want their site to look. They want it to look basically pixel perfect to the image in this file.
One of the places in the page calls for a menu bar, where each one does the changing bit on hovering, acts like a hyperlink, etc. In the Photoshop file this is one long bar, so a cheap and easy way to do this is to just split that segment into multiple images and then place them next to each other in the file.
So instinctively I lay it out like so (there's more to it but this is the gist)
<a href="page1.html">
<img src="image1.png" />
</a>
<a href="page2.html">
<img src="image2.png" />
</a>
<a href="page3.html">
<img src="image3.png" />
</a>
and so forth.
The problem is the images have this tiny space between them which is unacceptable since the client wants this thing pixel-perfect (and it just plain looks bad).
One way to get it to render properly is to remove the carriage returns between the images
<a href="page1.html">
<img src="image1.png" />
</a>
<a href="page2.html">
<img src="image2.png" />
</a>
<a href="page3.html">
<img src="image3.png" />
</a>
Which makes the images go right up against each other (the desired effect) but it makes the line incredibly long and the code more difficult to maintain (it wraps here in SO and this is a simplified version - the real one has longer filenames and JavaScript sprinkled in to do the hovering).
It seems to me that this shouldn't happen but it looks like the carriage return in the HTML is being rendered as a small empty space. And this happens in all browsers, looks like.
Am I right or wrong for thinking the two snippets above should render the same? And is there something I'm doing wrong? Maybe saving the file with the wrong encoding? Should I make every one of these links a perfectly positioned CSS element instead?
The whitespace (carriage return included) is usually rendered as space in all browsers.
You need to put the elements one after another, but you can use a trick:
<a href="page1.html"><img src="image1.png"
/></a><a href="page2.html"><img src="image2.png"
/></a><a href="page3.html"><img src="image3.png"
/></a>
This also looks a little ugly, but it's still better than one single line. You might change the formatting, but the idea is to add carriage returns inside the elements and not between them.
I don't know if this is general enough for your page, but you could class these particular a tags and float them all left, then they'll bunch together no matter how your HTML is formatted.
<style>
a.together {
float:left;
}
</style>
<a class='together' href="page1.html"><img src="image1.png" /></a>
<a class='together' href="page2.html"><img src="image2.png" /></a>
<a class='together' href="page3.html"><img src="image3.png" /></a>
That's part of the HTML specification - the spaces are in the markup so they're considered part of the document.
The only other options you've got, since you dislike the formatting, is to break the html tags:
<a href="..."><img src=".." /></a
><a href="..."><img src=".." /></a
><a href="..."><img src=".." /></a
which is undesirable in my opinion, or create the html dynamically - either via JavaScript or using a templating system and dynamic html.
The reason is simple: In HTML white space matters, but only once. Repeated white space is ignored, only the first is shown.
The only reliable way to avoid this is, as you did, by putting no white space between elements.
When table based layout would be less out than it is currently, you could use a zero-border, zero padding table to align your elements while having them on separate lines in the source code.
The way I handle this is to use an unordered list, and make each image/link an item.
Then use CSS to display each item inline and and float them to the left.
This will give you a lot more flexibility and make the markup very readable.
The behavior you demonstrated above is true as the browser treats carriage returns as a space. To fix it, you can style it like so with:
a { display: block; float: left; }
Please note that the above rule applies it to all links, so you might want to narrow the selector to certain elements only, ie:
#nav a { display: block; float: left; }
If you're going to do a tabbed interface on a website, take great pains to do it properly, and it will be worthwhile. There are many websites with great examples of CSS tab implementations. Consider using one of them.
This one has a lot of CSS+Javascript/AJAX tabs. Or see this set of simple CSS examples (some styled). Finally, check out this actually-pretty-cool tabs generator.