Weblogs: Web Accessibility

Configuring links in Screen readers

Tuesday, February 12, 2008

I did some accessibility tests about Empty Links and Screen Readers which was published on the YUI Blog in January. Along with two full time screen reader users, Artur Ortega and Victor Tsaran, I tested how various forms of empty links were handled in screen readers.

The first draft of the resulting article was overly long, and I had to chop it down to ensure the focus of the article remained on target - tackling an accessibility issue with the Microformats Include Pattern. This meant that one particular section, describing the variety of configuration options about screen reader handling of links got dropped off.

This information instead is now in this blog post. It's a vital piece of information because I'm seeing well-intentioned people like Tantek Celik assuming a particular screen reader handling of markup and basing their ideas on top of this expectation. And as we see with the include pattern, it's to the detriment of the screen reader user. Hopefully this post can shed some light into what screen readers are really capable of.

Real world screen readers

Screen readers are highly configurable pieces of software. There has been no wide-scale research into what configuration preferences are more popular, or even if there's a one true configuration that screen reader users gravitate towards.

The big danger with building accessible websites is to assume that there's a default configuration, and chose solutions that enforce the expectation of a particular configuration. We can make some sensible design choices without resorting to expectation.

There are various reasons for configuring a screen reader differently. Most of them come down to experience, where a user is happy with a current setting, or has found one that provides him with more information that he wants and less of what he doesn't want.

Another factor is the general web at large. Even though the vast majority of markup out there in the real world is not well formed, invalid nor semantically meaningful, there are techniques that are fairly safe for screen readers, and some techniques that go against the typical expected markup.

The Microformats include pattern threw up an unexpected use of markup - an anchor with no link text. In the vast majority of sites an empty link wouldn't be deliberately used within typical content, so the technique is quite an edge case, and so its effect in screen readers can be rather random than planned.

The less mainstream a markup technique, the less likely a screen reader will handle it well. There's a natural reason for this - for a screen reader to be a useful assistive technology on the web, it needed to handle the real markup that was out there. It didn't have the luxury of living within an academic-minded environment, it had to deal with the brutal environment that is the Web. So, where it can solve or work around a markup issue, it did, especially when it was a common markup problem.

Configuring links

Screen readers are fairly complex pieces of software, it is a complete aural interface to an operating system. As such there are a variety of customisations and configurations that can be changed or updated. There are two significant configurations that directly impacts how links are perceived:

Link title configuration

Screen readers have a specific configuration about how to handle titles on links. The options are typically:

Since sites using title attributes appropriately and containing appropriate content is very much a minority, there's a strong argument that providing necessary information in a title attribute only will present problems to screen reader users.

There is no formal study or empirical evidence that can definitively state that titles are always available or that titles are never available. Relying on one optional state is not advisable. Thus, the title attribute method is not sufficient to guarantee that the link is accessible (or invisible) to screen readers.

On a practical basis, it would be safer to assume that the configuration option selected would be one where the link text was either the primary source read out, or overridden when a title attribute was present. The option of title attribute or nothing wouldn't be a practicable option on today's web.

Link announcement

Screen readers can optionally announce the presence of links. Typically links are read out by a different voice to normal text - sometimes a female voice is used to read link text, and a male voice reading normal text. In addition to this, or perhaps as a substitute, the screen reader will preface any link text with the word 'Link'.

This means that link solutions that intend to be transparent to screen readers - such as not having link text so that the screen reader seems to ignore the link - may stumble in that because there is a link, the word "Link" is read out, followed by no link text.

So this means that we cannot guarantee that a link remains invisible. From a practical perspective, why would normal content have a link that the author didn't want people to use? It's not a typical use case, and so attempts to hide links tend not to be a safe practice.

Update: Steve Faulkner on JAWS

Steve Faulkner points out that JAWS does not allow the user to hear both the link text and title attribute. The choice is either one or the other. From the JAWS 9 documentation:

By Default, JAWS speaks the on screen text of a link, but you can set JAWS to instead speak title text, assigned by the page author within the HTML code. Title text normally provides supplemental information about the link.

Steve also provided a screenshot of JAWS' Text Link Options configuration pane.

The JAWS configuration dialogue shows options for:

Steve has also recently republished articles about the title attribute over on the Paciello Group blog, and has collated extra information in the title attribute - what is it good for? (resurrected). Thanks Steve!

Related resources

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]