WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Lists of links to alternative formats

for

From: John E. Brandt
Date: Aug 19, 2006 8:20AM

I vote for #4, but Jukka makes some good points.

How about doing it this way ...

---------

Intro: This is a page of forms use for bla-bla-bla. They are sorted in
different formats based upon your need. Choose the format first, then the
form:

[each of these clicks to a sections below]
These versions of the forms are in HTML.
These versions of the forms are in Microsoft Word
These versions of the forms are in Adobe Acrobat (PDF).

[anchor]HTML versions
Form 1(HTML)
Form 2(HTML)
Form 3(HTML)

[anchor]Microsoft Word versions

Form 1(HTML)
Form 2(HTML)
Form 3(HTML)

[anchor]Adobe Acrobat (PDF) versions

Form 1(HTML)
Form 2(HTML)
Form 3(HTML)

----


The above lists could be in tables or organized in columns using CSS to make
it easier for the sighted user. The same thing could be done on separate
pages.

John E. Brandt
Augusta, Maine USA
www.jebswebs.com



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Paul R. Bohman
Sent: Friday, August 18, 2006 8:59 PM
To: <EMAIL REMOVED>
Subject: [WebAIM] Lists of links to alternative formats

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)