WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Lists of links to alternative formats

for

From: Emma Duke-Williams
Date: Aug 21, 2006 4:00AM

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 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 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)
>
>
>
>
>
>


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