HTML5 Accessibility Chops: Block Links

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.

Block Links in HTML5

The HTML5 specification says:

The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).

Reading the article prompted me to dig a bit deeper into the issues: HTML5 block link tests

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 href="#"><p>link one</p> link 2 </a>
• Jaws skips link content outside of the block level element when a user navigates using the link shortcuts keys (in Internet Explorer only).
  • <a href="#"><p>link one</p> link 2 </a>
• NVDA announces ‘link’ for each line of text content in a link containing line breaks.

VoiceOver has bugs that cause it to repeat link text in a number of situations, 2 of which are unrelated to the change in conforming use of the a element in HTML5:

1. a link includes a text within block level element and text in the link.
   1. <a href="#"><p>paragraph element</p> and some text</a>
2. a link includes both text and an image with a non empty alt attribute.
   1. <a href="#">link text and <img src="tick.png" alt="image"></a>
3. a link includes a line break.
   1. <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.