Go to page 22: The JAWS aria-label with digits bug

Some software bugs are more amusing than others. For some reason I find this one to be amusing, perhaps because I discovered it on a Friday afternoon.

My goal was to provide some context for a list of numeric links that appear at the bottom of a pager feature on a web page, for example at the bottom of a page of search results:

A pagination feature,  featuring the number 1, followed by the numbers 2 through 5, each of which are blue underlined links

Typically this might be coded as a list of links, like so:

    <li class="thispage">1</li>
    <li><a href="page2.html">2</a></li>
    <li><a href="page3.html">3</a></li>
    <li><a href="page4.html">4</a></li>
    <li><a href="page5.html">5</a></li>

Screen readers will read this as “link 2”, “link 3”, “link 4”, and “link 5”, which in my opinion is not particularly intuitive and needs a bit more explanation.

With this in mind, I thought I would enhance the list with a few accessibility features:

  • Wrap it in a <nav> element with role=”navigation” and aria-label=”More pages on this topic”
  • Add hidden text “The current page:” as a preface to the number of the current page. This is hidden using the clip method so it’s invisible to sighted users but announced to screen reader users.
  • Add aria-label to each link so that it reads “Go to page 2” rather than simply “2”.

Here’s the revised code:

<nav role="navigation" aria-label="More pages on this topic">
    <li class="thispage"><span class="hidden">Current page:</span>1</li>
    <li><a href="page2.html" aria-label="Go to page 2">2</a></li>
    <li><a href="page3.html" aria-label="Go to page 3">3</a></li>
    <li><a href="page4.html" aria-label="Go to page 4">4</a></li>
    <li><a href="page5.html" aria-label="Go to page 5">5</a></li>

According to the Text Alternative Computation algorithm in the ARIA spec, the link text should be announced only if there is no value for aria-label or aria-labelledby, so aria-label should work as a replacement for existing link text.

This all works beautifully with NVDA 2014.3 in both IE11 and Firefox 32. It also works beautifully with JAWS in Firefox, but in IE11 JAWS announces both the aria-label and the link text (observed in both JAWS 15 and 16 beta). Not only that, but it concatenates them into a single label, which results in “Go to page 22” rather than “Go to page 2”. It continues on in this fashion, with “Go to page 33”, “Go to page 44”, and so on. The position of the aria-label attribute within the code has no effect.

Here’s my test page, which includes a couple of possible temporary solutions until the JAWS bug is fixed (I reported it to Freedom Scientific using the JAWS 16 Beta Report form. The ok-but-not-great solutions I came up with are:

  1. Spell out the page number in aria-label (e.g., “Go to page two”). This is an improvement, but JAWS still reads both aria-label and link text so the result is “Go to page two 2”. At least that’s more accurate than “Go to page 22”, but still odd and potentially confusing.
  2. Add additional text to the aria-label to serve as a separator between the two digits, for example “Go to page 2 now”. With this approach, JAWS announces “Go to page 2 now 2”. Still not perfect, but to me this seems like the best solution until the JAWS bug is fixed.

6 replies on “Go to page 22: The JAWS aria-label with digits bug”

I don’t like the idea of using the span with aria-hidden. But here’s another option that uses aria-describedby to add context.
<div style=”display:none” id=”goTo”>Go to this page</div>

<a href=”/page2.html” aria-describedby=”goTo”>2</a>

I find the bug amusing, but don’t think that simple page navigation needs aria. This particular use case is so idiomatic that it would just slow me down. The landmark is a good idea, but relabelling all the links to say “go to page” is just an irritation. Prefix it with “pages:”. This is a much better experience. Current page is interesting and more justified, but I personally pick it up because (usually) the current page is not a link.

Paul’s idea is very pragmatic and should work well, but we all must admit it’s a hack (not to sound negative, I’ve also use this technique). The aria-label solution is most correct; screen reader vendors (and browsers) need to follow the spec much better. Voiceover with Safari 7 didn’t work properly either; it announced the link text and the aria-label.

Web Axe: I agree the CSS hidden plus aria-hidden technique is a bit of a hack, but it’s pretty much fool-proof. It works in a predictable way across all modern screen readers and browsers. I’m all for doing things by the spec, but not at the expense of something not working correctly with some combinations of common technologies. After all, robustness is one of the accessibility principles!

On the plus side, the CSS hidden plus aria-hidden technique makes it very explicit as to who is supposed to see/hear which piece of text.

Comments are closed.