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:

  <ul>
    <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>
  </ul>

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">
  <ul>
    <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>
  </ul>
</nav>

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.

Use font-size: 100% !important

First, I should disclose my bias: I just turned 51, no longer have 20/20 vision, and prefer text that is readable rather than text that makes me squint.

Don't make users squint

Font size in CSS can be specified in any of several size units, the most common of which are pixels (px), em, or %. The differences are clearly explained in Kyle Schaeffer's article CSS Font-Size: em vs. px vs. pt vs. percent.

In his 2006 article The 100% Easy-2-Read Standard, Oliver Reichenstein argued convincingly for using a font-size of 100%, which is the text size browsers use by default.

In 2011 D Bnonn Tennant's Smashing Magazine article 16 Pixels: For Body Copy. Anything Less Is A Costly Mistake expanded on Reichenstein's article and argued for using fonts that are at least 16 pixels, which is the default size in most browsers.

I don't know this for sure, but I like to believe that browser makers at some point in their histories did extensive usability testing to determine the optimum font size to use as their factory default setting. So I agree with Tennant that web pages should honor that standard. But there's a fundamental difference in Tennant's and Reichenstein's recommendations. Tennant is recommending 16 pixels, whereas Reichenstein is recommending 100%. For many users, these two units are the same since 16 pixels is the browser default. However, some people change the default font size in their browser. It's easy to do, right there in Preferences where folks can change all sorts of things like their browser's start page and whether to block pop-up windows. The screen shot below shows the Preferences dialog in Firefox, where users can select any of an impressive range of font size options, from 9 pixels to 72.

Screen shot of Firefox preferences dialog

When users change their browser's default font size, either larger or smaller, it's because 16 pixels is not the optimum size for that person. They have a personal need or preference for text in a different size.

Continue reading

Crashing at the College Inn, Lost In Time

In 1992, DO-IT was founded with funding from the National Science Foundation, and every year since then has hosted a Summer Study program in which high school students with disabilities spend two weeks on the UW campus staying in dorms, learning about college life, participating in workshops and going on field trips that expose them to exciting and challenging academic and career opportunities. Yesterday another Summer Study in this longstanding tradition came to an end.

The kids who participated in this year's Summer Study weren't even born when this program began. For them, 1992 was a very, very long time ago. For me, I was already an adult by 1992, married and on my way to being somewhat comfortably established, already in my second position after attaining a university degree. But I too am a youngster, humbled by the size and history of my university, where brilliant people have worked together to make important discoveries and solve great problems since 1861. Each day at Summer Study I stroll across Red Square in the crisp air of early morning, and behold the majesty of the UW campus. Suzzallo Library stands Cathedral-like, preserving and protecting centuries of thought, and providing a sacred space where students can not just learn, but be awed by knowledge.

From Red Square on a clear day, the view extends to Mount Rainier, far more ancient, majestic and powerful than any of man's feeble creations. The Mountain puts all of this in perspective.

During Summer Study I spend my nights at The College Inn, where rooms are available for as little as $60 per night. Built in 1909, the Inn is nearly as old as the University itself. Its dark rooms, creaking floors, and old—if not period—furnishings are constant reminders that visiting scholars have been staying here for over a century.

Continue reading

Notes from AHEAD 2014

I'm honored to be the closing plenary speaker at AHEAD 2014, the annual conference of the Association on Higher Education and Disability.

Thinking back to a previous AHEAD conference, I recall a plenary speaker who proudly announced that he didn't have any slides; he would just be talking. This proclamation was met with applause; even a few very enthusiastic whoops!. So I'm a little nervous about presenting to this same crowd with 70 slides.

Why do some people not like slides? Are they really a bad thing? For audience members who have difficulty processing auditory information, I think it can be helpful to complement talk with visual content. That's a good application of universal design. Probably the enthusiastically anti-slide crowd that year had endured a few too many talks at other venues (not AHEAD, of course) where speakers simply read from their slides, which is boring; or said things like "As you can see from this slide", which is offensive to folks in the audience who can't see the slide. I try not to do either of these things.

For me, the slides are there to complement what I'm saying, and serve to keep things visually interesting for folks who need that stimulation. My voice, without slides, would have only been half a talk. Conversely, the slides, without my voice, would be similarly incomplete. I explain all this in order to justify my not posting the full slide deck online. Without context many of my slides would simply be pictures without meaningful content. So instead, I'm repurposing my slide content in this blog post, in a format better suited to the current medium. Following is the content of my talk organized into two sections, Resources and Ideas.

Continue reading

Alt Text in Word: Title vs Description

In my recent blog post on Converting Word to PDF or HTML, I described some confusion that stems from Microsoft Word's having two fields, Title and Description, for entering alt text for images. Unbeknownst to me at the time, Greg Kraus of NC State had recently written a similar blog post in which he echoed this confusion.

Screen shot of Word 2011's Format Picture dialog with Title and Description fields

Prior to Office 2010, Word only had one alt text field, which was simple enough. That's the field you would use to add a brief description of the image, and your description would survive as alt text when the Word doc was exported to tagged PDF or HTML.

But now there are two fields, Title and Description, in all versions of Word from 2010 onward.

Word's Format Picture dialog includes help text that describes Microsoft's intention: "The screen reader first reads the title. The person can then decide whether to hear a longer description."

This isn't a bad idea. It's analogous to the alt and longdesc attributes that have historically been used for different purposes in HTML. All informative images need a short, sweet description in order to provide access to the image content (alt); and some images additionally need a long description where the content is too complex to be described succinctly, for example a chart, graph, or diagram (longdesc).

However, this model can only be effective if it's well supported and properly implemented, and currently it's not. This model has been adopted by other tools, include Google Docs, Open Office, and Libre Office, all of which now have both Title and Description fields for alt text. However, there are variations in how this data is used and whether it survives when exported or imported from one application to another.

So, which field(s) should you use? Answer: It depends...

Continue reading