Accessibility and HTML5 Block Links
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="http://feathermelbourne.eventbrite.com/"> <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="" /> </a>
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
:hover to create the invitation to click anywhere on the block.
Block links are the perfect solution for this because:
- 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:
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.
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.