E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Paul R. Bohman
Date: Fri, Aug 18 2006 8:10PM
Subject: Lists of links to alternative formats
No previous message | Next message →

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)

From: Jukka K. Korpela
Date: Sat, Aug 19 2006 5:20AM
Subject: Re: Lists of links to alternative formats
← Previous message | Next message →

On Fri, 18 Aug 2006, Paul R. Bohman wrote:

> ... But the part I'm most interested in is how to represent links to
> alternative formats.

That's a tricky problem, but let's consider the users' needs first. If
there is a collection of documents in different formats, the user may wish
to act in two ways:
1) select the document first, then the format
2) select the format(s) first, if some formats are either strongly
preferred or strongly avoided.

The former is more common. The latter could be handled by providing some
tools, like alternative lists or some dynamic (scripted) tool for
removing some formats or selecting a particular format.

Selecting the document first is easier if there is no other selection that
_could_ be made on the page. People with cognitive disabilities will
probably find it easier to make one choice from a list than a
"two-dimensional" choice.

Thus, logically, you need a simple list of documents, or perhaps nested
lists or a table, but anyway organized by document content only, and
naturally using descriptive document names. In a simple approach,
selecting a document would then open a new small page containing links to
the different versions of that document. Naming the links would not be an
issue any more; you could use even format names, or perhaps a little more
logically "HTML version of Introduction to Foo Bar", "PDF version of
Introduction to Foo Bar", etc.

If opening a new page seems too clumsy, you could set up a piece of
JavaScript that opens a menu within the current page, with a link to the
small page as backup for non-JavaScript browsing situations.

This approach would simulate the ideal (?) solution where document format
selection takes place automatically by user preferences. The ideal
solution is technically quite possible as far as the protocols are
considered: you could set up content negotation in HTTP, so that a browser
would request for a document using a URL like
http://www.example.com/foobar and send a suitable Accept header,
specifying the acceptability of different media types, and the server
would then pick up the media type (among the versions it's got) that best
fits the request. However, this fails for two main reasons: browsers send
a more or less fixed and often nonsensical Accept header (e.g., IE says
that it will accept any media type, with no expressed preference between
them), and even if the allowed users to customize such behavior, most
users would not do so (as we can see from the fact that Accept-Language
headers, which _are_ customizable by users, have very rarely been actually
selected or even checker by users).

But this can easily be simulated using a link to a list of alternate
formats (which is more or less what content negotiation is expected to
do as a fallback, i.e. when none of the available formats is acceptable
according to what the browser says).

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: John E. Brandt
Date: Sat, Aug 19 2006 8:20AM
Subject: RE: Lists of links to alternative formats
← Previous message | Next message →

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

From: Emma Duke-Williams
Date: Mon, Aug 21 2006 4:00AM
Subject: Re: Lists of links to alternative formats
← Previous message | Next message →

I'd go with John's solution - as long as you make it clear that all
documents are available in all 3 formats.
If it's likely that people would want all the documents (or set
subgroups), could you also offer a zip version of the set?

Emma

On 8/19/06, John E. Brandt < = EMAIL ADDRESS REMOVED = > wrote:
> 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
>
>
>
>

From: ********
Date: Mon, Aug 21 2006 11:00AM
Subject: Re: Lists of links to alternative formats
← Previous message | No next message

This is a great question. I have to tackle the issue on the Division of Blind Services web site. Here's how we solved the problem http://dbs.myflorida.com/newsletter/index.shtml (touch and listen has three formats). Let me know what you think.