HTML5 Accessibility Chops: Block Links

Posted on Friday, 17 June 2011 by Steve Faulkner

It is conforming in HTML5 for links to include block level elements such as headings and paragraphs, this was forbidden in previous versions of HTML. A recent article by @feather concludes that the inclusion of block level elements inside a link causes some Assistive Technology (AT) to misbehave.

Summary of results

I created some test cases to tease out the different behaviours I was finding from testing permuations of the example in @feather’s article.

JAWS, NVDA and Window Eyes all treat text in a link that is contained both inside and outside of a block level element as separate links when the user navigates through the content using the cursor keys.

a link includes both text and an image with a non empty alt attribute.

<a href="#">link text and <img src="tick.png" alt="image"></a>

a link includes a line break.

<a href="#">some text before a line brake <br> and some more text after.</a>

Note: Also found that in Firefox, the default underline style for links is removed for text content inside a block level element contained in a link.

Conclusion

A link should contain a brief description of the link target, the possibility of links containing paragraphs of text is a potential issue that requires users to speak up about. Main advice is to include the key information at the start of a link. The current behaviour in the Windows screen readers does not appear problematic or broken. The VoiceOver issues are not due to inclusion of block level elements per se, but a symptom of a more general bug that needs to be fixed.

Comments

Yep I saw the speaking twice bug in VoiceOver for Mac but in VoiceOver for iOS it worked correctly, no bug. Apple seems to be putting more effort into mobile accessibility. Most blind people haven’t jumped over to macs yet but they are all over the iPhones and iPads. Google chrome is almost accessible for windows but does not work for form fields at all.

It should be noted that Firefox 3.6 does not handle block links with html5 elements very well (or any default inline element containing block elements). It will butcher the initial construction of the DOM, duplicating elements and mangling the order. For this reason it’s best to avoid putting block elements inside of anchors until firefox 3.6 usage drops to an acceptable level (shouldn’t take too long).

To clarify, at least in Firefox 8pre (but I suspect Firefox 4 and later), NVDA doesn’t really treat the “block level element and inline text” or “text with line breaks” as multiple links. You can confirm this by moving through the link word by word or character by character. Observe that NVDA only says “out of link” at the end of the link element.

What it does do is speak “link” at the start of each line of a link when reading by line. The assumption (for efficiency) is that links will normally only span one line. If we didn’t make this assumption, we’d have to speak “out of link” whenever the user moves out of a link when moving by line, which would become overly verbose. As I noted above, however, you can check where the link really ends by moving by character or word.

In retrospect, I wish we’d brought The Paciello Group into this one earlier than we did. We received the following from one of our clients after they spoke to Leonie: “I thank you. If I weren’t already a client, I certainly am now, and I’m glad for having referred a number of friends and family members to Schwab over the years.