HTML5 has many new elements and features. One of these is block links—we have the ability to wrap a link around block level elements. Here we take a look at the impact that this can have on accessibility.

In HTML5, it is valid and considered to be perfectly acceptable to create links that surround block level content. The only exception is that you can’t nest links. So how does this play out in browsers and assistive technologies that weren’t designed with this in mind?

Here’s an example from the page showing our upcoming tour of workshops to Australia:

<a href="">
<h3 class="summary">Melbourne</h3>
	<span><em>Supported by WIPA</em></span>
	<span>July 25, 2011</span>
	<span class="button">Purchase Tickets</span>

	<img src="star.png" title="Melbourne" alt="" />

The block link makes the entire block of content clickable without using multiple links. We just couldn’t do that in (X)HTML. Traditionally we would have made the heading clickable with a link inside the <h3> and then another link around the rest of the content to make it clickable, and then we might add JavaScript to deal with the clicks that happen in the spaces around and between the links and some CSS to create :hover to create the invitation to click anywhere on the block.

Block links are the perfect solution for this because:

  • they don’t rely on or require any JavaScript
  • they create fewer “tab stops” on the page, making it easier for keyboard users to navigate
  • they automatically create a large, block clickable area, making it easier for everyone to click

It is completely invalid (X)HTML though, isn’t it?

And because of the ways these types of validation/nesting errors are corrected in browsers, assistive technologies react to these in different ways.

Testing, testing, 1, 2, 3.

Lets take a look at what actually happens when we put block links to the test with a couple of pieces of assistive technology.

With a screen reader, the behaviour depends on the mode you’re using to interact with the links (via tabbing through the interface, listening to a summary of the page, reading a links list, or listening to the entire page with “say all” mode).

With the Jaws screen reader, when navigating using the tab key, the only part of the block link that gets read is the first content in the link. In this case, the heading “Melbourne” or the other city names. When navigating using the arrow keys, though, the heading is identified as a link, as is the rest of the content that is contained in the block link, effectively creating two links. When using the links list dialog in Jaws, the block link is identified as one link.

With Voiceover on the Mac, the link text is repeated when it is read out when navigating using the tab key but is only seen as one link:

Screenshot of block links with Voiceover on the Mac.

Screenshot: We use block links on the promo page for our Down Under Tour. Using Voiceover the block link contents are repeated when the link is read out. Voiceover would read “link Canberra Supported by WIPA July 22, 2011 PURCHASE TICKETS Canberra Canberra Supported by WIPA July 22, 2011 PURCHASE TICKETS.” In other screen readers, parts of the link aren’t read at all.

To summarize, sometimes the link will be recognized as one link and other times as two, sometimes the content is repeated and sometimes portions of the content are not read out at all.

The behaviour depends on the combination of screen reader, browser and navigation mode.

We don’t want it announced twice, though that is definitely better than the link contents not being announced at all.

We tested the same block links with Dragon Naturally Speaking (voice recognition software) and were pleased to find that it recognized each block link as just one link.

Screenshot of block links with Dragon Naturally Speaking's link overlay.

Screenshot: Block links on the promo page for our Down Under Tour. Using Dragon Naturally Speaking and the “link” command that shows all the links in a page for easy access, the block links are identified as just one single link. Here you can see the three green arrows numbered 5, 6, and 7 pointing to each of the block links for Melbourne, Perth and Sydney respectively.

So, what are we to do?

We decided to forge ahead with block links. Yes, the content gets read out twice in certain situations, but it is better to be read out twice than not at all.

In fact that was one of our biggest concerns: portions of the link not being read out. However, in this case, we’ve front loaded the most important part of the link (the name of the city) so it’ll be the first thing read out. And even though the date is not read out in certain scenarios, it is one of the very first pieces of content on the Event Brite registration pages. So, while it isn’t perfect, it is a compromise we’re willing to make. We may also look at changing the markup so that it is read out as part of that first block.

And remember: these issues will eventually go away as browsers and assistive technologies fully implement HTML5 compatibility. This isn’t even an issue that is “HTML5’s fault” so to speak. It’s just based on the way browsers recover from markup that they consider to be invalid.

For now, we’ll keep experimenting with block links and other HTML5 constructs in different scenarios and examine each situation on a case by case basis. This is only the tip of the iceberg when it comes to HTML5 and accessibility so we’ve got to keep moving forward with these solutions and dig deep into the accessibility implications and make smart decisions about what we implement and how we do it in the best possible way.

Like this? This is the type of content that we have in our full day workshop “Real World Accessibility for HTML5, CSS3 and ARIA.” We’re taking this show on the road to Brisbane, Canberra, Melbourne, Perth (as part of the Edge of the Web conference) and Sydney from July 21 to Aug 2, 2011. Sign up for the workshop now. Rates go up July 1st.

4 thoughts on “Accessibility and HTML5 block links”

Read comments

  1. Hi Derik,
    thanks for post, it spurred me on to doing some more in depth testing: HTML5 Accessibility Chops: Block Links. It appears the VoiceOver repetition issue is a more general bug, I have passed on my data to James Craig at Apple, so hopefully there will be a fix implemented soon.

  2. MicroAngelo says:

    Great stuff, thanks for the testing results. We’ve used block anchors a couple of times in the past even though it (and it alone) invalidated our xhtml, so it’s a feature we were really looking forward to in HTML5.

    As you said, now it’s just a case of waiting for screen readers etc. to catch up, but it’s good to know that even the ones that fail now do so fairly gracefully.

    Thanks again and keep up the good work!

  3. Andrew Downie says:

    Derrick, I checked out your code with JAWS V12, NVDA 2011.1.1 and Window-Eyes V7.5.1 with IE 8 and Firefox 3.6 (must get round to updating it). Performance between browsers was consistent. While Window-Eyes reports two links and the other two report one, reading through the page with either down-arrow or continuously was so similar across all three it didn’t matter. All content was read, with no repetition. While JAWS and NVDA (correctly) recognise only one link, they both announce “link” before both “Melbourne” and “Supported by WIPA”.
    Even at the current stage of screen reader development, I can’t imagine that users would encounter any significant issues when encountering block links setout like this. Things might get a bit messier with more content, but not likely.


  4. matt says:

    Fantastic – I was just wondering about the implications of using this.

Comments are closed.