Block level links and screen reader support

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.

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.

CSS3 Gradient Backgrounds and Controlling Their Height

Let’s assume you want to create a gradient background that starts at the top of the page and finishes at the bottom of your page header, i.e. is 100px tall. You can do this with a combination of CSS3 rules and avoid those ugly background images.

Continue Reading CSS3 Gradient Backgrounds and Controlling Their Height

Yahoo! to downgrade IE6 in 2011

Yahoo User Interface LibraryYahoo! introduced the Graded Browser Support grid years ago to give developers a guideline on what browsers deserved the greatest amount of resources for debugging, hacking, and development. This has been well received amongst the developer community as a justification for not dwelling on obscure browsers, such as IE5.5 for mac. This has made our code cleaner and easier to maintain as the browser-specific hacks are no longer needed.

Yahoo just announced the GBS change we’ve all been waiting for. IE6 will be downgraded to a C-status browser in Q1, 2011. This means I can finally upgrade my own laptop to IE8! This means we can focus on building for the future and not the past. Excuse me as I hyperventilate over the joy.

Internet Explorer 6: We are forecasting the transition of Internet Explorer 6 from A-grade to C-grade in the next GBS update. The calculus here is simple: The proliferation of devices and browsers on the leading edge (including mobile) requires an increase in testing and attention. That testing and attention should come from shifting resources away from the trailing edge. By moving IE6 to the C-grade, we ensure a consistent baseline experience for those users while freeing up cycles to invest in richer experiences for millions of users coming to the internet today on modern, capable browsers. Note: This forecast should not be taken as an indication that IE6 users will see an abrupt change in their experience of Yahoo! websites in Q1 2011; the change in philosophy toward IE6 will be reflected in new development and products and applied in ways that make sense based on product needs.
Graded Browser Support Update: Q4 2010 – Eric Miraglia and Matt Sweeney, Yahoo! Developer Network

Cross-browser HTML5 video tag with fallback for Flash users

Apple’s lack of support for Flash on the iPhone and iPad has forced people to reconsider the value of HTML5 and its video tag. It’s no longer something to put off until the future. However, adding HTML5 video support to your site AND continue to provide a Flash option for older browsers (I.E.) is not as simple as you might expect.

While the video tag has been standardized, there is a lack of consensus for supporting the codecs used to package the videos for distribution and playback. Some browsers are supporting the OGV format, some support the more popular but licensed mp4 format. Others, such as Chrome, will support both. To make it even more exciting, there is a new version under development to make a truly open-sourced format: WebM.

This means your video tag needs to define multiple movie sources to make it playable on all browsers. It sounds complicated because it is. Luckily, Kroc Camen has written a great article and code pattern for adding a cross-browser video tag with fallback to Flash for the older browsers: Video for Everybody!.

The article is full of great advice from a programmer that has learned the stuff the hard way. Here’s an explanation of how you’ll need to adjust your htaccess file.

Ensure your server is using the correct mime-types. Firefox will not
play the OGG video if the mime-type is wrong. Place these lines in your .htaccess
file to send the correct mime-types to browsers

AddType video/ogg  .ogv
AddType video/mp4  .mp4
AddType video/webm .webm

Video for Everybody! – Kroc Camen

Related Resources