WebAIM - Web Accessibility In Mind

E-mail List Archives

Lists of links to alternative formats

for

From: Paul R. Bohman
Date: Aug 18, 2006 8:10PM


Here's a dilemma that's far from new, but I'm curious to hear if there
are any new perspectives. Here's the dilemma:

I've got to update several web pages for a university web site that are
essentially lists of forms to be printed. In some cases there is a
reason to have an HTML version, and in other cases it makes more sense
to have a PDF and/or Word version. The HTML vs PDF/Word debate is not
what I'm most interested in here, though it's related and there are
certainly aspects of that debate worth discussing with respect to my
question.

... But the part I'm most interested in is how to represent links to
alternative formats. Here's a simplified example of how the documents
are represented now:

Document 1 (HTML) (Word) (PDF)
Document 2 (HTML) (Word) (PDF)
Document 3 (HTML) (Word) (PDF)
etc, with *many* documents

The main concern is that there are *many* links with the exact same link
text. Most people would say this is a bad thing because it forces screen
reader users to listen to the full context of the sentence, rather than
just jump from link to link as they often do. I have heard some
accessibility aficionados argue that this is not such a big deal and
that links are meant to be heard in their full context. I agree, but not
necessarily completely. If I can, I'd like to find a solution that
1) makes the links more unique when heard out of context and
2) doesn't require too many strange and uncomfortable contortions of
markup, time, or effort, though I'll gladly put the effort if there is
indeed a "best" way.

Possible solution 1:

Leave things as they are, or in a format that's at least very close to
this one conceptually. That's easy enough to do, and may end up being
the best solution in the end.

Possible solution 2:

Write all of the links so that they all contain the full title of the
document. The main drawbacks with this approach are
1) it's redundant in the extreme, especially with large numbers of documents
2) it slows down screen reader users because they have to listen to
everything, and have to pay special attention to hear the format.
Perhaps it would make the most sense to put the format at the beginning
of such a link. For example, the link text might be: "PDF - Document 1",
though this makes 1/3 of the links start with the same text ("PDF"),
which is far from ideal either.

Possible solution 3:

This is a variation on #2: do everything as described above, but hide
the document title from visual users using CSS tricks, such as moving
the text either above or to the left of the viewable area of the
browser. All of the drawbacks are the same as in #2. The only added
advantage is that visual users do not notice the redundancy.

Possible solution 4:

Put the information in a table, with the document title on the left, as
a row header, and the three types of formats on the top as column
headers. The data cells would contain some clickable text, which might
be "HTML", "Word", and "PDF". This seems like a pretty good approach,
because it keeps the text to a minimum but still allows screen reader
users to hear the full context if they listen in table navigation mode
with their screen reader. The links themselves would still be redundant,
but all users should still be able to understand the full context, using
the table matrix as an organizer.

Possible solution 5:

This one is a bit more creative. I could create a DHTML onclick and/or
onmouseover JavaScript event that causes a list of three links (link
text = "HTML", "Word", "PDF") to appear when you click on the title of
the document. Users would then choose which link to follow. I could
provide a fallback mechanism for users with JavaScript disabled.
Advantages:
1) It keeps the page design clean
2) It avoids redundant link text
Disadvantages:
1) screen reader accessibility would be tricky, though I wager
that it would be achievable
2) It would surprise pretty much all users, at least on their
first encounter with the list of links
3) It requires an extra click, or at least an extra decision
to make, after users have already decided which link to click on


That's all I can come up with at the moment. Which of these solutions do
you like best? Do you have any better ideas? If so, I'd love to hear them.

--

Paul R. Bohman
Technology Coordinator
Kellar Institute for Human disAbilities (www.kihd.gmu.edu)
George Mason University (www.gmu.edu)