E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Best Practice for linking to documents

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

From: Angela French
Date: Mon, Apr 11 2011 4:18PM
Subject: Best Practice for linking to documents
No previous message | Next message →

This question is directed to screen reader users primary, but since this groups provides such good conversation, I look forward to hearing from anyone.

I would like to know a best- practice accessibility method for linking to documents such as MS Word documents and PDFs, etc. In the past when I have hand coded sites, I have used the following method:

<a href="http://filepath.pdf">Title of Document [<img style="border:none;" src="/graphics/ /pdfLogo.gif" alt="Portable Document Format" /> 100<abbr title="kilobytes">KB</abbr>]</a>

I did it this way to provide both sighted users and screen reader users an indication of the type of document that would be opened and its file size. But this takes getting into the code. I am looking for a way to let content contributors to a site that is managed using Adobe Contribute create effective links to documents. They may be limited to what they can do. So, I'm wondering what do screen reader users need/prefer when linking to a document? If you have an example (either code or URL), I'd appreciate your input.

Thank you,

Angela French
Internet Specialist
State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED =
http://www.checkoutacollege.com<;http://www.checkoutacollege.com/>;

From: Jared Smith
Date: Mon, Apr 11 2011 4:27PM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

This looks good, except I'd lose the expanded alt text and the <abbr>.
Nobody calls a PDF by it's real name of "Portable Document Format".
Everyone else sees and knows PDF, so I'd just keep the alt text as the
more accurate and succinct "PDF". And using abbreviation for KB isn't
really useful. If the user doesn't know what KB means, showing them
the expanded abbreviation of "kilobytes" will probably only muddy the
waters even more.

And very good job in including this important information within the
link. We typically see this content immediately after the link, which
means it would not be read in the context of the link as screen reader
users navigate the page via links.

Jared

From: Angela French
Date: Mon, Apr 11 2011 4:48PM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

Jared - that's something I pulled from my old "code snippets" file. Thanks for the feedback. Since our Contribute users can't get to the code, I need to come up with something easy to implement. I see on Webaim.org this method below where a span tag is used to provide information and hidden of the viewable page. I suppose a similar technique could be used with linking to documents.

<a href="http://www.vischeck.com/vischeck/" title="Link to External Site" class="external">Vischeck - external link</a>

/* External links */
a.external span
{
position:absolute;
left:0;
top:-500px;
width:1px;
height:1px;
overflow:hidden;
}

a.external:link
{
background: url(/media/template/externallink.gif) no-repeat 100% 0;
padding-right: 20px;
}

From: Birkir R. Gunnarsson
Date: Mon, Apr 11 2011 5:54PM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

One thing that annoys me as a user is that I am never 100% sure from
just browing and looking at a link whether I will open the file or get
a download prompt to download the file to my computer.
I suppose this may be mostly controlled by IE security settings and
file type, for instance when I ahve a .PDF file and click on it it
usually opens, so if I want to download it I have to simulat a right
click and choose "save target as" from the right click menu.
I wish there was a way to make this behavior consistent, or include in
the link whether the file will automatically open or I will get a file
download prompt (in general I always prefer the latter,).
As a screen reader user I find this lack of predictability the most
anoying thing about downloading files.
Including the word "Dwonload" in the link is also g good practice, I
hate links that expand or move you to a different section of the page
whre there is an image that you click, which opens up a new site where
you have to input your email address and there are unlabelled series
of buttons ... and I am not even exaggerating. :)
hth
-Birkir

On 4/11/11, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
> Jared - that's something I pulled from my old "code snippets" file. Thanks
> for the feedback. Since our Contribute users can't get to the code, I need
> to come up with something easy to implement. I see on Webaim.org this
> method below where a span tag is used to provide information and hidden of
> the viewable page. I suppose a similar technique could be used with linking
> to documents.
>
> <a href="http://www.vischeck.com/vischeck/" title="Link to External Site"
> class="external">Vischeck - external link</a>
>
> /* External links */
> a.external span
> {
> position:absolute;
> left:0;
> top:-500px;
> width:1px;
> height:1px;
> overflow:hidden;
> }
>
> a.external:link
> {
> background: url(/media/template/externallink.gif) no-repeat 100% 0;
> padding-right: 20px;
> }
>
>

From: Ryan E. Benson
Date: Mon, Apr 11 2011 7:12PM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

Birkir,
This is all done at the user level, so as somebody making a page they
cannot force you to see that prompt. They can send the HTTP headers a
certain way, but you as the user can always override them.

--
Ryan E. Benson

On Mon, Apr 11, 2011 at 7:51 PM, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:
> One thing that annoys me as a user is that I am never 100% sure from
> just browing and looking at a link whether I will open the file or get
> a download prompt to download the file to my computer.
> I suppose this may be mostly controlled by IE security settings and
> file type, for instance when I ahve a .PDF file and click on it it
> usually opens, so if I want to download it I have to simulat a right
> click and choose "save target as" from the right click menu.
> I wish there was a way to make this behavior consistent, or include in
> the link whether the file will automatically open or I will get a file
> download prompt (in general I always prefer the latter,).
> As a screen reader user I find this lack of predictability the most
> anoying thing about downloading files.
> Including the word "Dwonload" in the link is also g good practice, I
> hate links that expand or move you to a different section of the page
> whre there is an image that you click, which opens up a new site where
> you have to input your email address and there are unlabelled series
> of buttons ... and I am not even exaggerating. :)
> hth
> -Birkir
>
>
> On 4/11/11, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
>> Jared - that's something I pulled from my old "code snippets" file. Thanks
>> for the feedback. Since our Contribute users can't get to the code, I need
>> to come up with something easy to implement. I see on Webaim.org this
>> method below where a span tag is used to provide information and hidden of
>> the viewable page. I suppose a similar technique could be used with linking
>> to documents.
>>
>> <a href="http://www.vischeck.com/vischeck/" title="Link to External Site"
>> class="external">Vischeck - external link</a>
>>
>> /* External links */
>> a.external span
>> {
>> position:absolute;
>> left:0;
>> top:-500px;
>> width:1px;
>> height:1px;
>> overflow:hidden;
>> }
>>
>> a.external:link
>> {
>> background: url(/media/template/externallink.gif) no-repeat 100% 0;
>> padding-right: 20px;
>> }
>>
>>

From: Jukka K. Korpela
Date: Tue, Apr 12 2011 1:03AM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

Birkir R. Gunnarsson wrote:

> One thing that annoys me as a user is that I am never 100% sure from
> just browing and looking at a link whether I will open the file or get
> a download prompt to download the file to my computer.
> I suppose this may be mostly controlled by IE security settings and
> file type,

It depends on the browser and its settings, on the media type of the data,
possibly the filename suffix too, and on the software installed in the
system. It is unavoidably unpredicable, from an author's point of view at
least. Any note on this by the author is a shot in the dark, sometimes an
educated guess that is mostly correct, but it may really confuse when it
isn't.

> I wish there was a way to make this behavior consistent, or include in
> the link whether the file will automatically open or I will get a file
> download prompt (in general I always prefer the latter,).

An author can (and usually should) indicate the media type of the data, such
as "PDF" (which is surely the most widely understood expression for that
type). He may also use the type attribute in markup, as in
type="application/pdf", to express the same thing in machine-readable form
that browsers may make use of

> Including the word "Dwonload" in the link is also g good practice

Any link can be used as a download link by the user, and any link might open
directly in the browser or in a plugin or external program. So the word
"download" would be misleading. If the link points to a PDF document, then
the odds are that many people wish to download it instead of directly
opening it, but this is implicit in its being PDF, and I don't think there's
any better way to express this than the name "PDF".

> I hate links that expand or move you to a different section of the page
> whre there is an image that you click, which opens up a new site where
> you have to input your email address and there are unlabelled series
> of buttons ... and I am not even exaggerating. :)

And you didn't even mention links that are no links because they rely on
Javascript that might be turned off, or have been poorly written in
Javascript in a manner that does not work on all browsers. Links can cause
many kinds of problems, and some of the problems can be alleviated by
annotations, but there's no agreement on how this should be done. One of the
few areas where there is reasonable uniformity is that links to PDF
documents are followed by the name "PDF" in parentheses or an icon for PDF
or both.

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

From: Peter Krantz
Date: Tue, Apr 12 2011 1:21AM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

On Tue, Apr 12, 2011 at 09:04, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
>
> It is unavoidably unpredicable, from an author's point of view at
> least. Any note on this by the author is a shot in the dark, sometimes an
> educated guess that is mostly correct, but it may really confuse when it
> isn't.
>

This is a fact that many web authors have a hard time understanding.
Compared to printed material (where you get to control almost every
aspect of the medium that carries the information) the web only
provides you with a set of suggestions. End users are getting better
and simpler configuration settings for downloads, windows, tabs and
other user interface aspects. It is time to let go.

Regards,

Peter

From: Waltenberger, Lon (LNI)
Date: Tue, Apr 12 2011 3:57PM
Subject: Re: Best Practice for linking to documents
← Previous message | Next message →

We use a method demonstrated at the bottom of
http://www.lni.wa.gov/ClaimsIns/Insurance/Learn/StateFund/RelatedInfo/De
fault.asp.

With some CSS and a we provide linked file info to both sighted
readers and those using screen readers. We also note the root URL for
offsite links.

Screen readers users get all the info whether they're going through the
page or listing links. Sighted readers get the info because it's
readable but visually doesn't look like part of the link.

We use null alt text on the PDF icon because it's solely for sighted
readers.

If a file is over 400KB we use Numion's calculator at
http://numion.com/Calculators/Time.html. We add 20% overhead and round
up for whole minutes at 56 Kbps.

It's fairly simple but your content providers may not be up to it
without some training. I don't know anything about Adobe Contribute.

From: John Foliot
Date: Wed, Apr 13 2011 7:18PM
Subject: Re: Best Practice for linking to documents
← Previous message | No next message

Angela French wrote:
>
> <a href="http://www.vischeck.com/vischeck/" title="Link to External
> Site" class="external">Vischeck - external link</a>
>
> /* External links */
> a.external span
> {
> position:absolute;
> left:0;
> top:-500px;
> width:1px;
> height:1px;
> overflow:hidden;
> }
>
> a.external:link
> {
> background: url(/media/template/externallink.gif) no-repeat 100% 0;
> padding-right: 20px;
> }

When it comes to linking to external documents, we can do something
similar - I always recommend that files sizes be indicated as well.

While this doesn't solve all of the problems, it does solve *one* of the
problems: have your CSS place an identifying icon into the page
'automagically'. (Replace the file extension with others of your
choosing):

a[href$='.pdf'] {
background-image: url(../images/icons/pdf_gray.png);
background-position: right;
background-repeat: no-repeat;
padding-right: 16px;
border:none;
line-height:16px;
border-bottom: 1px dotted gray;
}

a[href$='.pdf']:focus, a[href$='.pdf']:hover {
background-image: url(../images/icons/pdf.png);
background-position: right;
background-repeat: no-repeat;
padding-right: 16px;
border:none;
line-height:16px;
color:#830000;
border-bottom: 1px dotted #830000;
}

Works great in CMS solutions.

JF

(P.S. - For Microsoft Word, don't forget to use both .doc *AND* .docx -
ditto for PowerPoint: ppt/pptx)