Contradictions in Accessibility – Hidden Information

Many of the techniques we employ as developers to make our web sites more accessible result in hidden information that may only make them more accessible to a small portion of users rather than more accessible to everyone.

(X)HTML provides many ways of providing extra “information” about various elements on the screen: title attributes for acronyms and abbreviations; title attributes for links; longdesc for images; alt text for images; summary attribute for tables; to name a few. While the use of these attributes is encouraged by many (including ourselves), and deemed an improvement to accessibility, using them does not always improve universal accessibility.

Common to all of the above “accessible” and recommended techniques is that the information they provide is hidden from view and is only available with some effort. As authors we need to consider low-tech solutions in addition to the solutions that we implement that technically make our documents more accessible to everyone.

Long Descriptions

Long descriptions for images include a URL in the longdesc attribute to indicate an alternative representation of the information contained within the image. Often these are complemented by hidden or otherwise obscure “d” links. The contents of the longdesc attribute, however, isn’t readily available to users — they either need to secondary mouse click, and select properties, or Longdesc, or some use some other method in order to get at the data.

A screen reader user has the advantage that their software will tell them that a long description is available. But what about the rest of us?

Perhaps it would be more universal to consider a low tech alternative – simply including the text based format in the same page. That way everyone can access it without having to go through extra clicks or other manipulation.

We might consider providing a full text link (instead of a d-link) to the image and its description in the text. This is more universal and will be available in all technologies instead of only those technologies that support longdesc. In cases where the image contains data (such as pie charts or graphs), we’ve seen longdesc links that lead to a text version of the same data — in list or tabular format. We even provide an example of this on our site: Demonstration of the LONGDESC attribute and the “d” link. Why not include the table or list of data in the original page?

Yes, we do recognize that in some instances the tabular data may be more appropriately placed on a separate page. We should at least consider using the low tech option might be better.

Title attributes

Title attributes are most commonly used on links to provide “advisory” information (or in some cases, commentary) about the link. We see them all the time for people providing a “Quick Links” section on their blogs. We see this technique used in Dave Shea’s Mezzoblue dailies, Mark Pilgrim’s b-links, Anne van Kesteren’s HREF, and Simon Collison’s Logical Linkages, among others. In many of these cases it is an exercise in saving space, being subtle and maintaining a clean, crisp design. The problem is that the titles are hidden until your mouse hovers over the link.

To compensate for this, we see Mark Pilgrim providing a good example in his b-links Archives. If you view his b-links archives for June 2004, you’ll notice that in this version of his b-links, he has opted to display his commentary on each of his links in plain view, rather than hiding it in the title attribute. A nice, low-tech alternative solution that is accessible to everyone, and a reasonable compromise.

Another issue with hidden title text remains – titles are not shown as a “tooltip” when the links received focus via the keyboard. So much for device independence. Yes, this is the fault of the browsers. (Note to browser makers – can we fix this please?) Until this is addresseed, consider that the text you are stashing in the title attribute may be better placed elsewhere – perhaps as regular old text. This ultra low-tech, highly-accessible solution provides the information to everyone. Roger Johansson of 456 Berea Street uses this technique in his Quicklinks section on the main page of his site.

Summaries on tables

This suffers from many of the same problems as the previous examples. Accessibility advocates (again, including ourselves) advocate the use of the summary attribute. The problem is that while it technically enhances accessibility, it doesn’t expose the potentially useful information to others. Clearly the decision to place the contents of the summary attribute in regular body content (either as a heading, or perhaps as a simple text description) before the table is dependent upon context, and upon the text that you are actually placing in the summary. However, it is still worthwhile considering this low tech approach — it may be useful to users with cognitive disabilities or others that are viewing the content to get the quick summary of the trend that is displayed in the table.

What can we do?

There are a number of solutions for these hidden items:

1. We can encourage and wait for browser makers to provide mechanisms to expose these hidden alternatives (eg., Internet Explorer still doesn’t support longdesc, except for those that install Jon Hanna’s longdesc linker)
2. Individual site authors can provide a preferences page so users can provide their preferences (i.e., images on/off, display long descriptions, Flash on/off). This could be saved via a cookie on the users computer. Christian Heilmann has an interesting implementation demonstrated at Learning to Let Go
3. Individual site authors can make choices about how they code their documents by realizing that just because something is technically accessible doesn’t always mean it is functionally accessible. (OK, the way I worded the third option, really makes it obvious which choice I’m going to advocate…)

Asking the browser makers to make their user agents better is a good start. It is what we expect – just as we as authors have to do our part to follow the spirit of WCAG. Unfortunately waiting for user agents to improve doesn’t deal with the here and now.

Some authors will choose to employ some type of preferences page. Perhaps Christian might add an “expose all hidden information” option to his demonstration? While this may seem to work in principle, I still believe it is a bit much to expect users to set their preferences on each web site they visit. Setting browser preferences are usually buried deep within multiple menus and modal dialog boxes where individuals either can’t or won’t change them, simply because they don’t know the controls exist.

By no means are we suggesting that we shouldn’t use all of the accessbility enhancements that are provided to us in HTML/XHTML. We are suggesting that in addition to providing extra advisory information hidden away, that as authors we simply consider other low-tech ways to support universal accessibility. After all, accessibility isn’t just about screen reader users…