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



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul R. Bohman
Sent: Friday, August 18, 2006 8:59 PM
To: = EMAIL ADDRESS 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)

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
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul R. Bohman
> Sent: Friday, August 18, 2006 8:59 PM
> To: = EMAIL ADDRESS 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)
>
>
>
>
>
>


--
Blog: http://www.tech.port.ac.uk/staffweb/duke-wie/blog/

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.

-----Original Message-----
>From: "Jukka K. Korpela" < = EMAIL ADDRESS REMOVED = >
>Sent: Aug 19, 2006 7:10 AM
>To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [WebAIM] Lists of links to alternative formats
>
>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/
>
>
>
>


________________________________________
PeoplePC Online
A better way to Internet
http://www.peoplepc.com