Yahoo! User Interface Blog

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

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.

Charts are a great idea to make rows and rows of boring numbers easier to understand and to take in — for people that can see them. However, not all of your site’s visitors can see and you’ll also want to keep information you offer available for search engines. There are a lot of libraries on the web that allow you to create charts, but not many take this use case into consideration.

In praise of data tables

This is where data tables come into play. (Note: For the purposes of this article, I’m referring to pure HTML tables — not to rich UI controls like Jenny Han Donnelly’s YUI DataTable Control.) They are the perfect data construct in HTML as they are available both for people that can see and those who can’t. Assistive technologies like screen readers offer a way to navigate tables and to read their information row-by-row and cell-by-cell. All you need to do to please everyone is to use the correct markup (including a few attributes you might not have used yet):

<table summary="Results of a survey of which animals people would like to see more on YDN">
  <caption>What animals would you like to see more?</caption>
  <thead>
    <tr>
      <th scope="col">Animal</th>
      <th scope="col">Requests</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Kittens</td>
      <td>45331</td>
    </tr>
    <tr>
      <td>Puppies</td>
      <td>32323</td>
    </tr>
    <tr>
      <td>Elephants</td>
      <td>12345</td>
    </tr>
    <tr>
      <td>Badgers</td>
      <td>6546</td>
    </tr>
    <tr>
      <td>Sharks (without lasers)</td>
      <td>223</td>
    </tr>
    <tr>
      <td>Sharks (with lasers)</td>
      <td>2323</td>
    </tr>
  </tbody>
</table>

The summary attribute tells assistive technology what this table is about and the caption shows up for all users. The th elements define what cells are headers and the scope attribute applies them to all the data cells they are connected to. In this case it means that “animal” gets read out before each animal and “requests” before each number. This means that even a visitor who cannot see will still know in row five what the information is about. All in all the table renders as:

Easy to understand, but not too pretty. And it can get boring. How about we use this information and create a tasty pie chart like the following (click on the image below to see the working example in action)?

Using table data to automatically generate charts

In order to have the table be preceeded by a pie chart like this all you need is to add two scripts at the end of the document body and a class called yui-table to the table itself. For example:

<table class="yui-table" summary="Results of a survey of what browser people love">
  <caption>What browser do you love?</caption>
  <thead>
    <tr>
      <th scope="col">Browser</th>
      <th scope="col">Lovers</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>MSIE</td>
      <td>221</td>
    </tr>
    <tr>
      <td>Firefox</td>
      <td>516</td>
    </tr>
    <tr>
      <td>Opera</td>
      <td>312</td>
    </tr>
    <tr>
      <td>Safari</td>
      <td>100</td>
    </tr>
    <tr>
      <td>Omniweb</td>
      <td>30</td>
    </tr>
    <tr>
      <td>Lynx</td>
      <td>4</td>
    </tr>
  </tbody>
</table>
<script src="http://yui.yahooapis.com/2.4.1/build/yuiloader/yuiloader-beta-min.js"></script>
<script src="tablestoyuicharts.js"></script>

This will show in a browser with the latest Flash plugin like this:

You can define the size of the chart in CSS by defining a width and height for each div element with a class of yuichartfromtable:

div.yuichartfromtable{
  width:300px;
  height:300px;
  margin:0 auto;
}

As for the scripts: the first script is the YUI Loader Utility which allows you to pull in YUI components on-demand. This is great, as you don’t need to add lots and lots of script elements but let the YUI Loader figure out what it needs. You can download the second script here; if you care to know what is going on with it, check the following section. If you just want to use the script, then you’re done :-).

How does this work?

The script to turn all tables with the class yui-table into charts is quite short, as it uses the newer YUI components that take a lot of the heavy lifting off you, especially the table-to-dataset conversion which is done by the YUI DataSource Utility. The full script is this:

var tablestoYUIchartsplease = new YAHOO.util.YUILoader({
  require: ['charts'],
  onSuccess: function(){
    var tables = YAHOO.util.Dom.getElementsByClassName('yui-table','table');
    YAHOO.util.Dom.batch(tables,function(o){
      var chartcontainer = document.createElement('div');
      YAHOO.util.Dom.addClass(chartcontainer,'yuichartfromtable');
      YAHOO.util.Dom.insertBefore(chartcontainer,o);
      var data = new YAHOO.util.DataSource(o);
      data.responseType = YAHOO.util.DataSource.TYPE_HTMLTABLE;
      data.responseSchema = {fields:['response','count']};
      YAHOO.widget.Chart.SWFURL = 'http://developer.yahoo.com/yui/build/charts/assets/charts.swf?_yuiversion=2.4.1';
      var chart = new YAHOO.widget.PieChart(chartcontainer,data,{
        categoryField:'response',
        dataField:'count',
        expressInstall:'http://developer.yahoo.com/yui/build/charts/assets/expressinstall.swf'
      });
    });
  }
});
if(document.location.toString().indexOf('http')!==-1){
  tablestoYUIchartsplease.insert();
}

Let’s chunk it up and see what each section does:

var tablestoYUIchartsplease = new YAHOO.util.YUILoader({
  require: ['charts'],
  onSuccess: function(){

First up, we let the YUI Loader do its magic: We instantiate a new loader, tell it we need the YUI Charts Control and wait for the different script nodes to be generated and the components to be loaded before we continue. The loader tells us all is OK by firing the onSuccess event, which we use to execute an anonymous function that does all the other work.

    var tables = YAHOO.util.Dom.getElementsByClassName('yui-table','table');
    YAHOO.util.Dom.batch(tables,function(o){

We use the YUI Dom Collection to get all tables with the correct class and apply a function to each of these tables using the batch method. The method sends the current table as the parameter o to this function.

      var chartcontainer = document.createElement('div');
      YAHOO.util.Dom.addClass(chartcontainer,'yuichartfromtable');
      YAHOO.util.Dom.insertBefore(chartcontainer,o);

We create a new div element, give it a class of yuichartfromtable (to allow for styling) and insert the new element into the document before the table.

      var data = new YAHOO.util.DataSource(o);
      data.responseType = YAHOO.util.DataSource.TYPE_HTMLTABLE;
      data.responseSchema = {fields:['response','count']};

Then we allow the rather new YUI DataSource Utility to flex its binary muscles. While this is meant to wade through external data sources and JavaScript arrays for you, it also allows for a responseType of HTML table, which means it converts a table to a JavaScript object you can work with. As we’re dealing here with a really simple table, all we need to do in terms of responseSchema is to define two fields: a response (what) and a count (how many). These three lines are all you need to convert the table to a dataset that both the YUI Charts Control and the YUI DataTable Control can use.

      YAHOO.widget.Chart.SWFURL = 'http://developer.yahoo.com/yui/build/charts/assets/charts.swf?_yuiversion=2.4.1';
      var chart = new YAHOO.widget.PieChart(chartcontainer,data,{
        categoryField:'response',
        dataField:'count',
        expressInstall:'http://developer.yahoo.com/yui/build/charts/assets/expressinstall.swf'
      });

Time for pie: we define the URL of the Flash movie that draws the pie and instantiate a new pie chart. We send the div we created earlier as the container, the data we retrieved from the table as the data to display and define a configuration object. This object has the response field as the categories and the count field as the data. The expressinstall defines what Flash movie to show if the visitor doesn’t have the right Flash version.

    });
  }
});
if(document.location.toString().indexOf('http')!==-1){
  tablestoYUIchartsplease.insert();
}

Almost done. All the script now needs to do is to call the insert() method of the YUI Loader — that gets the ball rolling. I’ve enclosed the method in an if statement that checks if the HTML is called up via HTTP or not as the Charts Control needs HTTP to work.

Summary

That’s all you need to do to progressively enhance an accessible data table to turn them into a pie chart using the YUI Charts Control. We can extend this example to allow for several types of charts and to turn the tables into sortable data tables quite easily. If there is interest, drop us a comment.