Empty Links and Screen Readers

By Mike DaviesJanuary 23rd, 2008

About the Author: Mike Davies is a web developer for Yahoo! Europe focusing on web accessibility. He was the Technical Lead Developer of a website redesign which became a PAS 78 case study into the business benefits of accessible websites. Mike writes about web accessibility, Atom and web standards on his personal blog at isolani.co.uk. (Photograph courtesy of Neil Crosby)

With the help of other members of the Yahoo! Accessibility Stakeholders group, I ran a screen reader test to establish whether links that contain no link text were an accessibility barrier. We tested a number of approaches to hiding links across a typical range of screen reader and browsers.

The conclusion is that the most accessible link is one that contains link text. Different techniques of hiding links, from no link text, through to hiding by CSS can cause an accessibility barrier to screen reader users. Each screen reader presented its user with a different set of problems and barriers.

What follows is a detail description of the test, tabulated results, summary of techniques that passed, failed or came close, and a list of web development recommendations.

The Microformats include pattern

The Microformats group have created an include pattern which is a mechanism for including a portion of data from one area of a page into another area on the same page. Essentially, it’s a means of preventing the duplication of data.

A good example of this is a page that lists all the reviews done by one person. Instead of every review having to duplicate the reviewer details, we can use the include pattern to define the reviewer once, and include it into each review. No needless duplication.

The main technique being advocated as an include is the humble link, but in an effort to minimise duplication of content, the example is an empty link; a link with no link text:


<a class="include" href="#author" title="James Levine"></a>

The current accessibility understanding is that empty links can present a barrier to screen reader users. The Microformats group have attempted to solve this problem by using the title attribute to offer something a screen reader can use to announce a link.

The issue here is to find a way of marking up a microformat include pattern that’s accessible to screen reader users.

Test cases

I produced 18 test cases covering a wide range of techniques to hide a link from being displayed. These tests covered:

  • Normal links with proper link text
  • Links with no link text or title attribute
  • Links with a title, but no link text
  • Links containing just whitespace for text

Each type of link was styled in the following ways:

  • Displayed in a default manner
  • Positioned off-screen
  • Visibility of hidden
  • Display set to none

The tests were carried out by three screen reader users. Two of them are super-users of screen readers, so consequently have a great deal of experience and knowledge that can allow them to work around many difficult accessibility issues. Interestingly, neither of them had their main screen reader set up to read out both the link text and the title. Both of them have multiple screen readers installed. The third tester was a web developer with a deep understanding of using screen readers.

Ideally, we’d need more screen reader users to create a decent sample, including non-power users, but the results we saw are fairly consistent.

Success criteria

There are two screen reader behaviours that form a successful test case. The first was that a link was read out normally, as if it were an inline link within a paragraph of text. The second successful behaviour was that the screen reader does not announce the presence of a link and just skips over it.

The test results

We covered four major screen reader versions over three different browsers. The results for each combination can be seen in the following table. The result cells are colour coded to quickly highlight techniques that are safe to use:

  • Red-coloured cells indicates buggy behaviour or the output was likely to frustrate the screen reader user.
  • Amber-coloured cells indicate that the technique did work, but relies on stylesheets to hide the link from screen readers.
  • Light green-coloured cells indicate the technique did work, but relies on particular configurations of a screen reader.
  • Green-coloured cells indicate that the technique did work, and did not rely on stylesheets or a particular screen reader configuration.

All the information conveyed in colour is also available in the table footnotes and the notes below.

Tables for each browser combination

Link results for JAWS 8.0 and JAWS 7.10 with Internet Explorer 64
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href href nothing
empty with title title title href nothing
whitespace href href href nothing
whitespace with title title title href nothing
Link results for JAWS 8.0 and Firefox 2
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty absolute href absolute href absolute href nothing
empty with title title title absolute href, title nothing
whitespace href buggy1 absolute href nothing
whitespace with title title buggy1 absolute href, title nothing
Link results for JAWS 9.0 with Internet Explorer 6
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href nothing nothing
empty with title title title nothing nothing
whitespace nothing2 nothing2 nothing nothing
whitespace with title title title nothing nothing
Link results for Window-Eyes 6.1 with Internet Explorer 6
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty href href nothing href
empty with title title title nothing nothing
whitespace nothing2 href nothing nothing
whitespace with title nothing2 nothing2 nothing nothing
Link results for Window-Eyes 6.1 with Internet Explorer 7
type of link default offscreen visibility: hidden display: none
Normal text text nothing nothing
empty "empty", href3 "empty", href3 nothing "empty", href3
empty with title title title nothing nothing
whitespace nothing2 nothing2 nothing nothing
whitespace with title nothing2 nothing2 nothing nothing

Footnotes to the tables

  • 1. buggy means the screen reader reacted as if there were two separate links instead of just an empty link.
  • 2. nothing means that the screen reader announces there's a link, but there's no link text read out.
  • 3. "empty", href means the screen reader reads out the word "empty" followed by the contents of the href attribute
  • 4. In JAWS 8.0 with Internet Explorer when a list of links was displayed, the links could not be reordered alphabetically. We tried both a different page, and with JAWS 7.10, and that worked fine. Empty links breaks JAWS 8.10 ability to sort links when listed.

Test case failures (code red)

The following is a list of failures and buggy behaviour:

  • An empty linked styled with display none caused the href attribute of the link to be read out in Window Eyes 6.1
  • An empty link styled to visibility: hidden caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 in Internet Explorer and Firefox 2. With Firefox, JAWS 8.0 read out the absolute URL of the link.
  • An empty link regardless of styling (apart from display: none) caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 on both Internet Explorer and Firefox. Again, JAWS 8.0 with Firefox read out the absolute URL of the link.
  • A link containing whitespace as link text caused the href attribute to be read out in JAWS 7.10 and JAWS 8.0 in Internet Explorer and Firefox.
  • With JAWS 8.0 and Firefox we saw a buggy behaviour where a link containing just whitespace as link text was actually read out as two separate links.
  • With Window Eyes 6.1 and Internet Explorer 6 we saw buggy behaviour where a link containing just whitespace and a title attribute, but styled to appear offscreen, the href attribute was read out even though there was a title attribute present.

Test cases relying on stylesheets (code amber)

All of the test cases that relied either on the display or visibility styles to hide the link from the screen reader did succeed (except for the failures noted above, for example the handling of visibility is exceptionally buggy in JAWS).

When CSS is not enabled, or the styles are ignored by the screen reader, the behaviour falls back to the default case.

Test cases relying on screen reader configuration (code light green)

Test cases using the title attribute worked when the screen reader was configured to read out title attributes. Both our experienced screen reader users had changed their screen reader configuration to read out titles on links when there was no actual link text. Unfortunately, this is not sufficient to conclude that this is a majority preference.

Thus, techniques using the title attribute are reliant on a specific screen reader configuration to work as expected. This configuration cannot be assured, and cannot be relied on.

Test cases designed to hide the link from a screen reader by not supplying any link text fail when the screen reader configuration is set to announce links. Announcing links gets the screen reader to preface all link text with the word 'Link'. Empty links that successfully dodge screen reader heuristics and produce no link text still run into the frustrating problem of a link being announced, but no text associated with that link.

Passed test cases (code green)

Only two of the eighteen test cases resulted in an unqualified pass:

  • A normal text link with default styling
  • A normal text link displayed offscreen. (Links displayed offscreen are still announced by the screen reader)

Conclusion

Not using proper link text forces the browser and screen reader to fallback to heuristics in an attempt to determine what the link text should be. Internet Explorer decides to offer the title attribute, and failing that, it tries to extract something readable from the href attribute. JAWS 8 with Firefox 2 on the other hand reads out the absolute URL of the page, followed by, if available, the title attribute; or if the title attribute is not available, it extracts something readable from the href attribute.

There are breakages in JAWS 8.0/IE6 and Windows Eyes with IE6, when the link text is empty. We observed that a screen reader user could not alphabetically sort a list of links in JAWS 8.0, and so this creates a barrier to quickly finding a link, a barrier that wasn't there before, and it's the markup that provokes/uncovers this bug.

Windows Eyes also has problems with empty text links, falling back to reading out the href attribute, and uniquely reads out the link href when the link is styled with display: none.

An empty link with a title attribute, styled with display: none looks to be a feasible option, but flounders because of two ungrounded assumptions:

  • CSS will always be enabled on browsers communicating with screen readers
  • The title attribute is configured to be read out by screen readers.

Neither of these assumptions realistically hold, nor can be relied on.

Web Developer Recommendations

  • Always have proper link text for a link, and assure that the link text makes sense in context. At that point the link can then be hidden by positioning it offscreen. If the link is styled with display set to none, ensure that the content makes sense with and without the link text in place.
  • Never have an anchor with jusst an href attribute. The screen reader fallback is to read out the entire URL or try to extrapolate something readable from it, or a combination of both. This can lead to unpredictable results. How a browser or screen reader translates a URL into text that is read out requires more extensive testing.
  • Never use visibility: hidden to hide an empty link from view. This leads to the title attribute being ignored in both JAWS/IE6 set-ups, and the absolute URL of the link being read out with Firefox. It also introduces a dependency on CSS to prevent an accessibility barrier.
  • Never use just white space as the link text, the choice of link text between the setups tested differ significantly, with all combinations creating an accessibility barrier - either of reading an entire absolute URL, or guessing the link text based on URL extrapolation, or as in Window Eyes announcing a link, but with no link text read out.
  • Never use display: none as a means of hiding this link. This creates a dependency on CSS, since the rendering of the page in screen readers is degraded.
  • Never rely on the title attribute as the sole means of providing a form of link text since it's inconclusive whether title attributes are enabled for all screen reader users.

Resources

  • Test cases: The 18 test cases that we used for this experiment. This will allow interested parties to re-run these tests and confirm the findings.

Thank you to Artur Ortega and Victor Tsaran (both of the Yahoo! Accessibility Stakeholders Group) for volunteering time to run these test cases and talk through the issues they encountered - that process was enlightening and informative. Thanks to Ben Hawkes Lewis for his insight and guidance on screen reader usage, also for volunteering to run these tests through his screen readers, and his support of running this experiment. Finally, thanks to Ben Ward for taking the initiative to understand and resolve the accessibility implications of certain markup techniques, and for providing me with an interesting problem to tackle.

Tagged as:

18 Comments

  1. Thank you for this excellent piece of work. Is there any chance you could also test to see how the “object” method of using include in microformats works in ATs?

    You might also be interested in the testing associated with the (mis-) use of ABBR in microformats, in the hope of fix the problem identified in the hAccessibility article.

  2. Hello,

    Thank you for this very interesting research. I talk about it on my blog and I tried to translate recommendations into french.

    Sébastien Delorme

  3. First off, I really want to say how glad I am that this piece of research was done. It’s an issue we’ve been investigating at RNIB for a while now, but haven’t had the time or resources to spend on it. Luckily, you appear to have had both of those things, which is fantastic.

    That said, I have one issue with the recommendations given, and that relates to hiding links offscreen.

    I know that this test was concentrated on screen readers, and that it may be perfectly fine to hide links offscreen for screen reader users, but it causes serious issues for those who *can* see the links.

    If links are moved out of the viewport, the focus indicator follows the links and disappears from view. If several links are hidden from view in this way, it could be (and actually is, which I found out from bitter experience) seriously disorientating for any screen magnifier, voice recognition or keyboard only users.

  4. Hi pixeldiva, thanks for the comments, and you make a very important point about positioning links off screen.

    The best practice recommendations we use within web development is to always, if something is focusable and appears off screen, when it receives the focus it must then appear on screen so that it can be seen by sighted users. (And of course, it must be as obvious as possible where the focus is on the page at all times).

    Thank you for highlighting the point. One of the common errors in web accessibility is to fix something for one part of our audience, only to create or leave a problem for a different segment. Accessibility needs to be considered from a holistic point of view.

  5. Thank you Mike, Artur, Victor and Ben for putting so much effort into this testing. Witnessing the effort and resources required to put this together is a very welcome revelation of how much is required to get solid, complete data on accessibility issues.

    What we’ve got here is supremely valuable to the microformats community in refining the include-pattern documentation, and I hope web development at large where quirky techniques with anchors are employed.

    Of course, for the include-pattern we’re most interested in a solution where no content is added to the page — for any user — but other page content can be referenced for parsers. This research needs some digesting, but from the conclusions we’ll be able to identify when and where the hyperlink-based include pattern is and is not appropriate.

    Thank you again, this is invaluable.

    Andy Mabbett: In an ideal world I would of course love to see more research that would aid microformats development; be that from Yahoo, or elsewhere. I’m very lucky to work in the company of good, dedicated people who can assist with effort like this. I hope that some time in the not-too-distant future we get to do some more. Personally, my priority is to make sure the include-pattern makes good use of this research before I start thinking about the next project.

    I hope others will be inspired by this quality of work in their own research, though. I really can’t say enough good things about the effort that went into it.

  6. Thanks for the post… it is indeed very useful peace of work for accessibility developers
    I’ve one question though.
    In case of links like ? screen readers tend to treat “?” as inline punctuation.. I usually use title=”help” for such links.
    But if I am correct SR would read the title only when configured to do so.
    is there any better option for this type of links, which would work without requiring any special SR configuration?
    Thanks

  7. Hi Mike, thanks for the research. One question: In the second line of the conclusion it states

    Internet Explorer decides to offer the title attribute, and failing that, it tries to extract something readable from the href attribute.

    Should this not be a screen reader used in conjunction with IE and if so which one?

  8. Thanks for the research. Any accessibility developers should ‘use’ it!

  9. [...] Empty Links and Screen Readers » Yahoo! User Interface Blog (tags: accessibility screenreader microformats yahoo css html article links *) [...]

  10. for information, i have run the test case with nvda :
    The absolute url is read every time except for the visibility hidden and display none links who are never announced, the title is read not read at all

  11. Hi Steve,

    I’m not sure whether its the screen reader that’s figuring out what to display or the browser. I guess using a MSAA debugger/watcher will reveal which one is doing what.

    My explanation of the heuristics is based on the first table of test cases – JAWS7.10 and Internet Explorer 6, basically since I have the test results for a normal link, a titled empty link, and an empty link, I deduced what was going on based on the test results.

  12. [...] technique typically relies on one or more empty anchor (”a”) element(s), and as such has been criticized as not accessible for non graphical user agents such as screen readers, which get confused by these [...]

  13. This is very interesting. Also useful to know that off-screen links (which I use on my own website) can cause problems for users of magnifying software.

    Jacks comment: “Any accessibility developers should ‘use’ it!” is good. Maybe I am naive but after becoming the law in 1999 that all websites should be accessible (in the UK) I would assume that all web developers take accessibility very seriously (removes tongue from cheek).

  14. Thanks for this, Mike, It’s good to have some initial solid data to backup what may have been previously just a theory (aka “gut instinct”).

    Just to follow on from pixeldiva’s comments about hiding links offscreen. She mentions sighted non-screenreading users but some screen readers users can see very well. Some dyslexics use screen readers to support their comprehension of web pages.

    Given that this is a group that may be easily disorientated, I’ve always been a bit concerned that offscreen positioning of page content could create problems for these users as the screen reader output would no longer match the visual display. I’m not suggesting that offscreen positioning should be abandoned – merely that it should be used judiciously. More than a couple of instances on a page may well create barriers for this group.

    I think it’s also worth remembering that only about 5% of those who are registered blind (in the UK) are thought to have no usable sight. With that in mind, it becomes harder to asses what extent (if any) individual visually-impaired screen reader users rely on the visual display. Again, any significant disparity between the visual display and the screen reader output could create confusion.

    In short, screen reader users aren’t necessarily blind. They just have problems reading. :-)

  15. [...]  Empty Links and Screen Readers – Research into the potential accessibility barriers of links that contain no link text. [...]

  16. [...] Clarified the uses of the include-pattern, via Mike Davies of Yahoo [...]

  17. What about this?

    This is the one thing

    What if you hide the span, but still display the “a” tag? In this way, the title attribute is available, the anchor tag is not hidden, and the anchor tag is not technically empty – though it might appear empty to a screen reader, no sure. Can this be tested?