Category: Browsers

Daniel Göransson introduced VoiceOver’s contradictory support for block level links on a mailing list for Apple accessibility. Specifically, Safari + VoiceOver on OSX allows the link to be announced as a single object, whereas on iOS, the link is announced as individual elements.

Prior to HTML5, the link tag was an inline element and was not meant to contain block level elements, such as headers. This led engineers to create multiple links as designs included teasers and id card modules. These may include a thumbnail photo, header, abstract, and read more link. Bruce Lawson describes this code simplicity: Block level links in HTML5.

Göransson describes the desktop vs. phone behavior:

In Mac Safari and VoiceOver using tab key all items get announced and works perfectly. But in iOS Safari and VO using swipe to next item or touch exploring, each item get announced separately.

This is actually the intended behavior, as Chris Fleizach explains:

iOS is much flatter than MacOS, so we want to give individual access to each element within a link. Whereas, on the Mac, you can navigate inside of that link group if you so desire.

So how could we trigger mobile users to hear the content as a single chunk instead of individual elements? The following code snippets are inspired by Göransson’s emails. He deserves credit for the ideas, I can accept blame for mis-representation.

Please Note: you may find it easier to view these examples outside the WordPress framework. Visit the block level example page.

Base code snippet

This example has a header, paragraph, and image. I’ve placed alt=”” on the image, as the surrounding text provides adequate description.

<a href="https://www.flickr.com/">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic (Δέησις, “Entreaty”) probably dates from 1261. It was commissioned to mark the end of 57 years of Roman Catholic use and the return to the Orthodox faith. It is the third panel situated in the imperial enclosure of the upper galleries. It is widely considered the finest in Hagia Sophia, because of the softness of the features, the humane expressions and the tones of the mosaic.

See the larger image on Flickr

Using ARIA to make the experience consistent

ARIA roles allow developers to define the purpose of content. Ideally, you should use the correct tag before even considering ARIA attributes. Use the role when HTML doesn’t provide an adequate tag (tabs), or the HTML equivalent is not as well supported by accessibility APIs (nav). Secondarily, roles are used to restore the semantics of code when the correct tag is not used (div based buttons).

This example is correctly using the link tag, as the user will be taken to a new source of content, such as a web site. I had initially suggested using role=”button”, as that would flatten the experience and should announce the entire content, regardless of platform.

<a href="https://www.flickr.com/" role="button">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Using role=”button.

This would change the user’s expectation, as it announces this as a button instead of a link. It implies clicking on the object would trigger an action. But what is the action? Buttons should have a clear and concise call to action (“print”, “share”, “close”). This also means the link would appear within the quick menu for forms, rather than links.

Combining with aria-hidden

Göransson also noticed an unusual problem when placing aria-hidden=”true” on the image. This removed the image’s area from the touchable region.

Also when using anything with aria-hidden=”true” inside that <a>, the area where hidden item is located will become untouchable even if it’s still inside a <a>. For example, if I float an icon/image with aria-hidden to the left — that part of the <a> will be subtracted from the hitbox.

<a href="https://www.flickr.com/" role="button">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." aria-hidden="true" alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Added aria-hidden=”true” to the image.

Victor Tsaran re-iterated Chris Fleizach’s suggestion of using role=”text” to allow the block to be announced as a single unit.

I am not sure you can achieve this in Mobile Safari without perhaps having to resort to the role=text. The Voice Over navigation of the DOM is much flatter on iOS than on Mac OS and you are inserting a bunch of block elements into an inline one.

<a href="https://www.flickr.com/" role="text">
  <h4>The Deësis mosaic</h4>
  <p>
    <img src="..." aria-hidden="true" alt="">
    The Deësis mosaic ... </p>
  <p class="more">See the larger image on Flickr<p>
</a>

The Deësis mosaic

The Deësis mosaic …

Using role=”text” on the link

But this changes the semantics of the link to a text node, removing it from the link menu.

Göransson’s next attempt wraps the link’s content in a div with role=”text”. This keeps the link’s semantics and the entire content is announced. However, this also removes the semantics of the h4, removing it from the header menu.

<a href="https://www.flickr.com/">
  <div role="text">
    <h4>The Deësis mosaic</h4>
    <p>
      <img src="..." aria-hidden="true" alt="">
      The Deësis mosaic ... </p>
    <p class="more">See the larger image on Flickr<p>
  </div>
</a>

The Deësis mosaic

The Deësis mosaic …

Wrapping the content within a div that has role=”text”

What is the answer?

This exploration could be summed up by Sina Barham’s tweet about trying to change the expected gestures.

Great piece of advice, yes you can override #accessibility gestures, but please be very careful with that decision! #a11y #mw2014

— Sina Bahram (@SinaBahram) April 4, 2014

While we could solve the issue of making a block level link work consistently across mobile and desktop browsers, that may not be the ideal solution. The user’s expectations are context dependent, this is especially true with navigation.