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
aelement 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:
- a link includes a text within block level element and text in the link.
<a href="#"><p>paragraph element</p> and some text</a>
- 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).
https://remysharp.com/2009/08/10/defining-the-vomit-bug/
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.