What's the best practise for accessibility when you have redundant links on a page. For example, a page containing blog listings often has a clickable title and a read more link:
<article>
<h2><a>My awesome blog post title</a></h2>
<p>This is the excerpt...</p>
<a>Read More</a>
</article>
<!-- more blog listings... -->
My first approach would be to add an aria label to the read more link to give it some context.
<article>
<h2><a>My awesome blog post title</a></h2>
<p>This is the excerpt...</p>
<a aria-label="My awesome blog post title">Read More</a>
</article>
<!-- more blog listings... -->
However now there are two identical links and I can see how this would be irritating for people using screen readers - especially if the page contains a large number of articles.
Would this be a good use case for hiding the extraneous link from screen readers and/or people navigating using the keyboard. Something like this?
<article>
<h2><a>My awesome blog post title</a></h2>
<p>This is the excerpt...</p>
<a role="presentation" tabindex="-1">Read More</a>
</article>
<!-- more blog listings... -->
Not sure whether this is one of those situations where trying to help may actually make things worse. Would appreciate any advice!
Thanks, Adam
Some baseline:
Generally you want links that point to the same URL on a site to use the same text. This is part of the reason "read more" is so confusing for many screen reader users.
You also want to avoid being overly-verbose, in deference to screen reader users.
You also want to avoid linking an entire block of content, as that can also be incredibly verbose.
This mostly affects screen reader users; visual non-screen reader users can generally parse "read more" links easily.
You may have found from Google searches that are lots of different approaches and many of them depend on the context.
That is the catch — context matters. Knowing the audience, considering the material, and understanding the impact are all crucial. I might code it differently for a tech blog targeted at younger users than I would for a food blog targeted at a generation ahead of mine. In both cases I would include screen reader testing.
That being said, since "it depends" is generally a crap answer. Here are a some approaches you can test. Since screen reader users are our target, I am leaning on ARIA instead of CSS or scripting trickery.
This approach has issues in NVDA when a user tabs to a link (but is still my preferred method):
<article>
<h2>My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</article>
This approach will be more clear and gives context, but is a bit verbose and means you have to update / insert the content twice (which can be problematic if your post titles of have double quotes in the title that are not escaped):
<article>
<h2>My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</article>
This approach leans on the existing heading, as the first one does, but removes the "read more" text instruction completely:
<article>
<h2 id="Foo">My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</article>
This approach gives context first (id="Bar") and then the name of the post (id="Foo") thanks to a space separated list of IDs in the aria-labelledby. A skilled screen reader user (or someone who understands the page) can skip right past it after the first couple words:
<article>
<h2 id="Foo">My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</article>
I hope that gives you at least a starting point to test and/or decide which is the best fit for your audience and content.
<article>
<h2><a href>My awesome blog post title</a></h2>
<p>This is the excerpt...</p>
<a href>Read More</a>
</article>
First solution : let screen readers users ignore the "read more" link
Here the easiest thing is to set the aria-hidden attribute on the "Read more" link.
Problem : like it was stated for tabindex=-1, sighted screen reader users will see a link they can't go on.
Second solution : consider all as a link
In HTML5, you can perfectly enclose the whole article snippet in a link
<article>
<a href><h2>My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</a>
</article>
Problem : the alternative text will be awfully long.
3rd solution : Playing with a bit of javascript
Combining the aria-labelledby approach (see #aardrian excellent answer) and some javascript magic, you can have the best of two worlds by playing with the onclick event on the article tag (or the h2)
<article onclick>
<h2 id="Foo">My awesome blog post title</h2>
<p>This is the excerpt...</p>
<a aria-labelledby="Foo" href>Read More</a>
</article>
This way, the only visible link is the "read more" link, keyboard and screenreaders users can focus it. The alternative text is very explicit. Mouse users are still able to click on the heading or the excerpt.
I would add that having a link inside an heading (or vice versa) is often a bad design choice (too long to discuss here).
In my personal recommendation, I would combine it to one link... Anytime you can combine redundant links that's a great win.
<article>
<h2>My awesome blog post title</h2>
<p>This is the excerpt...</p>
Read More
</article>
<!-- more blog listings... -->
If you really need both links you can use an onclick function and remove the href.
<article>
<h2 id="Foo">My awesome blog post title</h2>
<p>This is the excerpt...</p>
<a onclick="examplefunction()"id="Bar" aria-labelledby="Bar Foo">Read More</a>
</article>
This removes that redundant link error and removes the second link from achieving focus. The link can still work if someone clicks on it, but it removes it from the tab order. This is perfectly valid.
Though it's always best to have HTML handle links instead of using javascript to do it.
Good Luck,
Giovani
Related
A screen reader user has multiple options to access content on the page.
A list of all headings for example, but also a list of landmarks.
With aria-label, you can label a landmark.
Consider the following markup:
<main>
<h1>My Blog items</h1>
<article aria-label="Why blueberries tast good">
<h2>Why blueberries tast good</h2>
<p>Some content about blueberries</p>
Read more
</article>
<article aria-label="I don't like apples">
<h2>I don't like apples</h2>
<p>Text about why I don't like apples</p>
Read more
</article>
<article aria-label="Oranges are orange">
<h2>Oranges are orange</h2>
<p>An article discussing the color of fruit</p>
Read more
</article>
</main>
Are the aria-labels in the above example useful to a screen reader user, or are they overkill?
The behaviour of aria-label is the key to understanding when to use it.
So in the comments I asked whether these were posts inline in the page or excerpts linking to other pages.
The reason this is important is down to the behaviour of aria-label.
If you add aria-label to a container it will over-ride all of the content in that container.
So if these were just full articles the aria-label would replace the whole blog content.
Example 1 - actual articles on the page
For example:
<article aria-label="Why blueberries taste good">
<h2>Why blueberries taste good</h2>
<p>Some content about blueberries which could be hundreds of paragraphs long</p>
</article>
Would only be read as "Why blueberries taste good" and all of the post content would be lost for screen reader users. (Kind of, obviously active elements such as links etc. still get read out and are accessible so it isn't straight forward but hopefully you get the idea).
As such in the above example the aria-label should be removed.
Example 2 - whole article is a link
Now if this was a list of posts with excerpts that are surrounded in a hyperlink we may not want the excerpt text read out as part of the hyperlink text.
For example:-
<article>
<a href="somewhere" aria-label="Why blueberries taste good">
<h2>Why blueberries taste good</h2>
<p>Some content about blueberries which could be hundreds of paragraphs long</p>
</a>
</article>
In the above example the whole article excerpt is part of the hyperlink text so we may decide it is better to override this and just have the article title as the link text.
However see the "final thoughts" section as I still think there is a preferable way to do this.
Your Example
In the example you gave I would not use aria-label at all.
Now this is partially down to the behaviour of aria-label as stated previously but more importantly down to how screen reader users navigate pages.
Screen readers have shortcuts for listing all the links on a page, cycling through headings and cycling through sections. This is the way that screen reader users "orientate" themselves and explore pages and the contents of the page.
Your example way of doing things is nice and accessible. Screen reader users can navigate by sections (<article>), headings <h2> or by hyperlinks.
Adding an aria-label is actually worse for screen reader users as they may or may not (depending on the screen reader and browser combination) be able to access the <h2>s anymore as you have overridden them.
Example 3 - same as yours but with the aria-label removed
<article>
<h2>Oranges are orange</h2>
<p>An article discussing the color of fruit</p>
Read more
</article>
Proper use of aria-label
aria-label is used to add information where there isn't any (or to add contextual information portrayed visually in certain circumstances).
For example if you have social media icons as links to your social media channel then adding an aria-label is one way to allow the accessibility tree to provide meaningful information to a screen reader.
Use it sparingly and always think of aria-label as a last resort after you have exhausted all semantically appropriate options.
Final Thoughts on the above examples
I personally would use aria-hidden instead of aria-label for example 2 (where we have a list of articles where the whole article is a link).
So instead I would structure those as follows:
<article>
<a href="somewhere">
<h2>Why blueberries taste good</h2>
<!--using `aria-hidden` on the excerpt text so that the `<h2>` is more likely to be discoverable using headings shortcuts-->
<div aria-hidden="true">
<p>Some content about blueberries which could be hundreds of paragraphs long</p>
</div>
</a>
</article>
The reason for this is (as mentioned previously) we are now not potentially over-riding the <h2> so in all screen readers the user should now be able to discover this article via heading as well as hyperlink.
Not overkill -- but you can use aria-labelledby to reference the header's ID to avoid text duplication.
Which one of the below methods is correct / better for making a link accessible?
Read More <i class="fas fa-chevron-right" aria-hidden="true"></i>
OR
<span class="sr-only">Title of post</span> Read More <i class="fas fa-chevron-right" aria-hidden="true"></i>
Which one of the methods is correct/ better for making a section accessible?
<section aria-label="Events"></section>
OR
<section aria-labelledby="hdng">
<h2 id="hdng">Events</h2>
</section>
OR
<section>
<h2 class="sr-only">Events</h2>
</section>
For the link, it should make sense out of context so I'd use a sr-only class around helpful screen-reader specific text.
<span class="sr-only">Title of post</span> Read More <i class="fas fa-chevron-right" aria-hidden="true"></i>
Regarding the section, a major heading tag at the very beginning will do the job well. If you want both screen-reader and regular users to see the heading, use a heading tag with an aria-labelledby attribute. If you only want screenreader users to see the heading, use the sr-only class again. Typically, you'd want all users to see a section heading though, so everyone can recognize the beginning of a new group of content.
<section aria-labelledby="hdng">
<h2 id="hdng">Events</h2>
</section>
Just to expand upon the great answer by #thenomadicmann here is a bit of advice on the subject and why things are suggested in WCAG / general accessibility guidance.
How should I include screen-reader friendly text in a link?
In the two examples you give (one using visually hidden text and one using an aria-label) you should use the visually hidden text.
There is one good reason for this, compatibilty.
14 browser / screen reader combinations have problems with aria-label on links (although support is very good)
However 100% of browser / screen reader combinations will read visually hidden text.
For this reason you should use
<span class="sr-only">Title of post</span> Read More <i class="fas fa-chevron-right" aria-hidden="true"></i>
Side note on icons
Consider replacing your font-awesome icons with inline SVGs. They are more accessibility friendly as they won't disappear if somebody overrides your site fonts (e.g. someone with dyslexia who prefers a certain font as it is easier for them to read). Plus font awesome is some 150kb of CSS and an inline SVG is about 1kb so it makes the site faster too if you only have a few icons!
How to make a section accessible
By standards the following is the correct method
<section>
<h2>section title example<h2>
</section>
However for maximum comparability you should use aria-label and role="region".
<section aria-label="section title example" role="region">
<h2>section title example<h2>
</section>
There are two points here.
aria-label support is nearly 100% (as discussed previously) whereas aria-labelledby support is not as good
Around 2% of all screen reader users are still stuck on IE6-8. As such adding role="region" gives (almost) the same semantic meaning to those screen reader users.
Side Note(s) on regions and headings
1 - The aria-label will result in some duplicate announcements in some screen readers. However this is still preferable as a user may prefer to navigate by regions and as such announcing the region names is useful.
2 - In your comments you wondered why to use a sr-only heading vs a label.
I partially covered this in the previous point (aria-label is slightly less reliable than visually hidden text) but there is another reason.
While some screen reader users navigate by regions, others prefer to navigate a page by headings (i.e. in NVDA you press NVDA key + 2 to loop through all level 2 headings.).
This is why headings are important, in fact they are more important than correct use of <section> elements as this is how the majority of screen reader users will explore your page.
I want to change
<section>
<header>...</header>
<p class="tweet">This is a tweet preview. You can... <em>6 Hours ago</em></p>
</section>
into
<section>
<header>...</header>
<article class="tweet">
<p>This is a tweet preview. You can... <time pubdate>6 Hours ago</time></p>
</article>
</section>
But after reading some articles on the <article> tag, I'm not sure that this is the best move. What would be better practice?
The important thing to understand about articles and sections is that they are sectioning elements. Each follows a common pattern:
<sectioning_element>
<heading_or_header>
... the body text and markup of the section
<footer>
</sectioning_element>
The footer is optional. Sectioning elements should have a "natural" heading. That is, it should be easy to write an <h?> element at the start of the section/article, that describes and summarises the entire content of the section/article, such that other things on the page not inside the section/article would not be described by the heading.
It's not necessary to explicitly include the natural heading on the page, if for example, it was self evident what the heading would be and for stylistic reasons you didn't want to display it, but you should be able to say easily what it would have been had you chosen to include it.*
For example, a section might have a natural heading "cars for sale". It's extremely likely that from the content contained within the section, it would be patently obvious that the section was about cars being for sale, and that including the heading would be redundant information.
<section> tends to be used for grouping things. Their natural headers are typically plural. e.g. "Cars for Sale"
<article> is for units of content. Their natural headers are usually a title for the whole of the text that follows. e.g. "My New Car"
So, if you're not grouping some things, then there's no need, and it's not correct, to use another sectioning element in between the header and footer of the section and your correct mark-up would be
<article class="tweet">
<header>...</header>
<p>This is a tweet preview. You can... <em>6 Hours ago</em></p>
</article>
assuming you can find a natural heading to go inside the <header> element. If you can't, then the correct mark-up is simply
<p class="tweet">This is a tweet preview. You can... <em>6 Hours ago</em></p>
or
<div class="tweet">
<p>This is a tweet preview. You can... <em>6 Hours ago</em></p>
</div>
* There's a case for including the natural heading anyway, and making it "display:none". Doing so will allow the section/article to be referenced cleanly by the document outline.
<article> content
represents a self-contained composition in a document, page,
application, or site and that is, in principle, independently
distributable or reusable, e.g. in syndication. This could be a forum
post, a magazine or newspaper article, a blog entry, a user-submitted
comment, an interactive widget or gadget, or any other independent
item of content.
(from the html5 working spec)
in fact one of the examples illustrates nested <article> elements where the inner <article> is inside a <section>
Why don't you think it's a good move? It seems to me that a Tweet would fit perfectly in the W3C spec on what should be in an article. It would most likely depend on the context your sample code is in (which we can't tell from what you've provided).
It could also be put this way.
The semantics don't matter THAT much. You could very well do that if you wanted to and it would be fine. The thing with the article vs. section usage debate is that it's all subjective, to a point. I would recommend against how you're doing it in the second version though because it seems as though that just clutters the code more. What you could do is just replace the section tag with an article tag.
I went through quite a bit of head scratching to understand it because it seems to be confusing to quite a few but it really should be looked at a bit more literally. Here is an easy way to look at it:
Sections can contain elements from different topics.
Articles should contain elements from the same topic.
For example:
<section>
<section>
<article id="article_ONE">
<header>...</header>
<p>Not directly related to article_TWO</p>
<footer>...</footer>
</article>
</section>
<section>
<article id="article_TWO">
<article>
<header>...</header>
<p>Part 1 of article TWO</p>
<footer>...</footer>
</article>
<article>
<header>...</header>
<p>Part 2 of article TWO</p>
<footer>...</footer>
</article>
</article>
</section>
</section>
I have a sidebar with latest news and random blog posts etc
<nav id="sidebar">
<section id="latest_news">
<h1>
Latest News
</h1>
<h2>
News Item 1
</h2>
<p>
Truncated text from the news item in question
</p>
View all news items
</section>
<section id="random_blog_post">
<h1>
Random Blog Post
</h1>
<h2>
Blog Post 1
</h2>
<p>
Truncated text from the random blog post in question
</p>
View all blog posts
</section>
</nav>
As you can see, I've got sections, h1's and paragraphs inside my nav.
I'm just wondering if this allowed or considered good practice. Is there a better more semantic (or less) approach to marking-up and structuring such sidebar content?
Yes, this appears to be pretty valid html5. w3org have an example of navigation with h1 tags in it.
Yes, you can do that, as also denoted in the spec
Quotes specifically relevant to your question:
The nav element represents a section
of a page that links to other pages or
to parts within the page: a section
with navigation links.
and
A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many school papers are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a thesis.</p>
<p>To the west are several exits. One fun-looking exit is labeled "games". Another more
boring-looking exit is labeled ISP™.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>
Actually, you could even write an h1 element as a direct child of the nav element so that the nav element would be named in the document's outline.
I suggest this reading about the importance of headings and document's outline:
http://dev.w3.org/html5/spec-author-view/headings-and-sections.html#outline
You can check your document's outline with this on-line tool:
http://gsnedders.html5.org/outliner/
Regards.
Let me just say first that I'm not looking to start a flame war :-)
I'm aware of the semantic meaning that tags such as <article> give a document, but what benefits does one get from using them?
Do search engines look at them differently? If not, what other benefits are there?
A Q+A on Google's Webmaster Central seems to suggest that the new HTML5 semantic elements have no impact currently, but will at some point in the future:
http://www.google.com/support/forum/p/Webmasters/thread?tid=2d4592cbb613e42c&hl=en
There are the obvious benefits that one day search engines might use them or microdata to associate more meaning to your site. I'm not totaly sure if that is the case yet, but some of the other answers so far provide some good links to answer that question.
Another benefit is cleaner markup. It helps to clean up the div soup that solved so many of our organization issues with HTML 4.01. Take this example:
<div class="post">
<h1>Example Blog Post</h1>
<div class="entry">
<p>Blog text goes here...</p>
</div>
<div class="entryFooter">
<p> Posted in example category.</p>
</div>
</div>
is not as readable or as clean as:
<article>
<header>
<h1>Example Blog Post</h1>
</header>
<p>Blog text goes here...</p>
<footer>
<p>Posted in example category.</p>
</footer>
</article>
Cleaner markup will make maintaining the markup a lot easier and that is always a benefit in my opinion.
Search engines will certainly look at Microdata differently.
Here's a tool that parses microdata:
http://www.google.com/webmasters/tools/richsnippets
To learn more about HTML5 Microdata:
http://diveintohtml5.ep.io/extensibility.html