WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: please test this method of identifying document icons with hyperlinks

for

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

From: Angela French
Date: Tue, Oct 04 2011 12:24PM
Subject: please test this method of identifying document icons with hyperlinks
No previous message | Next message →

Hello,
I am hoping a screen reader user or two will test this page for me. At the top of the test page is the method our site currently uses for representing documents for downloads on a page. Under that I have a new way to do it that I'd like your opinion on.

I have put the document icon type image inside the anchor tag so that it is part of the hyper link. My intention is to alert the screen reader user what kind of document the link goes to. Does this work as intended? Does it cause any confusion? Does it just get in the way when browsing by links? How does the reader read it (what do you hear)?

I have tried have tried the CSS solution: a[href$='docx'] , but it does not hold up visually on long links that wrap to the next line (we have some long titled reports!)

I have also experimented with: a[href$='doc']:after , but IE7 does not support this.


Here is the link to my test page: http://sbctc.edu/general/t_downloads.aspx .

Thank you so much. As always, I am open to other suggestions.

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

From: Rick Hill
Date: Tue, Oct 04 2011 12:36PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

I would think that the table method at the top also would work. Could list
the actual document name with file extension too:

Equipment Exemption Form.docx

Genearl question for all. Is there a need to post information on how to
view Word documents (like you're supposed to for PDF's). We plan to just
have a link in the footer to a page that lists helper tools for viewing
different non-HTML content/documents (rather than post the links on each
page where the content occurs).

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
Rick Hill, Web CMS Administrator
University Communications, UC Davis






From: Angela French
Date: Tue, Oct 04 2011 12:42PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

So Rick, you think just making the link on the title (and not on the icon) would suffice for screen reader users? It bugs me that a table is used for this (as a table-less kinda of designer). Also, it just takes up so much more room vertically on the page than a simple list. However, in terms of going back in fixing all the pages that do this, it would be a heck of a lot easier to just switch the link from the icon to the title. My intent was to provide a means for screen reader users to know what kind of doc (or to an external site) is being linked to. What do others think?

Just this week I created a Document Readers page which will be linked to from any page that has documents for download. It will be added as I go through the site and edit these inaccessible doc download methods.

http://sbctc.edu/readers.aspx

>

From: Angela French
Date: Tue, Oct 04 2011 1:00PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Rick, The other problem with these tables is that they use an h5 heading in them which is not semantically correct for the page structure.
Here is an example: http://sbctc.edu/college/_e-abe_grant_rfp.aspx . I suppose that moving these titles to a caption tag would be more appropriate and could be styled similarly, though it doesn't appear that Contribute provides a means for assigning a caption tag.



>I would think that the table method at the top also would work. Could list the
>actual document name with file extension too:
>
>Equipment Exemption Form.docx
>
>Genearl question for all. Is there a need to post information on how to view
>Word documents (like you're supposed to for PDF's). We plan to just have a
>link in the footer to a page that lists helper tools for viewing different non-
>HTML content/documents (rather than post the links on each page where the
>content occurs).
>
>
>Rick Hill, Web CMS Administrator
>University Communications, UC Davis
>
>
>
>
>
>
>

From: Andrews, David B (DEED)
Date: Tue, Oct 04 2011 1:06PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

I looked (listened) to your test page with JAWS 12, and IE8. It worked great, your method worked, and for those that navigate by bringing up a links list in JAWS insert-F7, it is especially useful.

Dave



From: Angela French
Date: Tue, Oct 04 2011 1:51PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Dave so what does the reader say?
Does it say "Word document" + the link label?

>

From: Rick Hill
Date: Tue, Oct 04 2011 2:06PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Just thinking that the name of the document is associated with the icon
link in the table. Not advocating using the table layout per se. I know we
had multiple documents available in multiple formats (some Word, some
Excel, some PDF, Some Word and PDF and so on). So we sued a multicolumn
table to lay it out. I believe we labelled the columns appropriately
header columns with using < th scope=col> labelled "Document", "Word",
"Excel" and "PDF" and also had the document name cells as th as well with
scope row.

I think your the examples will probably also be fine. I only suggest using
the file extension in the document name to make it clearer. Could also
make the document names the link and add the doc type in parens:

Equipment Exemption Form (Word)

Which may even be clearer. You could then style (Word) to be replaced with
a Word background image. Though that hides the text description of the
document type from sighted users leaving them only with an icon ...


­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
Rick






From: Angela French
Date: Tue, Oct 04 2011 2:30PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Rick, when you say that "Word" could be replaced with a background image, do you mean something where two styles would be applied: one to make Word display:none, and another to apply the background image (as shown in this article: http://stopdesign.com/archive/2003/03/07/replace-text.html )? I don't believe this technique could be implemented in Contribute as I don't think it provides a means of applying two styles to one element. Or did you have some other method in mind for this replacement?

Angela


>I think your the examples will probably also be fine. I only suggest using the
>file extension in the document name to make it clearer. Could also make the
>document names the link and add the doc type in parens:
>
>Equipment Exemption Form (Word)
>
>Which may even be clearer. You could then style (Word) to be replaced with
>a Word background image. Though that hides the text description of the
>document type from sighted users leaving them only with an icon ...
>
>
>
>Rick
>
>
>
>
>
>
>

From: Andrews, David B (DEED)
Date: Tue, Oct 04 2011 2:42PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Yes, that is what it says.

Dave



From: Jon Mires
Date: Tue, Oct 04 2011 2:48PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

You can just apply a class to it, if you have the CSS set up correctly:

Lorem ipsum <span class="word">(Word)</span>

then in your CSS:

.word {background: url('path-to-word-icon.png') no-repeat; text-indent:
-999em;}
/* you may also need to put an explicit width/height on this to match the
dimensions of your icon (and change the display), so it doesn't get cut off
*/

This shows the sighted users the Word icon, but lets the screen readers hear
the "(Word)" text. But, as Rick points out, a potential drawback is sighted
users get the icon only - no text.

Cheers,
Jon

Jon Mires
Center for Accessible Technology
Ed Roberts Campus
3075 Adeline St, Suite 220
Berkeley, CA 94703
= EMAIL ADDRESS REMOVED =
510-841-3224 x2017



On Tue, Oct 4, 2011 at 1:27 PM, Angela French < = EMAIL ADDRESS REMOVED = > wrote:

> Rick, when you say that "Word" could be replaced with a background image,
> do you mean something where two styles would be applied: one to make Word
> display:none, and another to apply the background image (as shown in this
> article: http://stopdesign.com/archive/2003/03/07/replace-text.html )? I
> don't believe this technique could be implemented in Contribute as I don't
> think it provides a means of applying two styles to one element. Or did you
> have some other method in mind for this replacement?
>
> Angela
>
>
> >I think your the examples will probably also be fine. I only suggest using
> the
> >file extension in the document name to make it clearer. Could also make
> the
> >document names the link and add the doc type in parens:
> >
> >Equipment Exemption Form (Word)
> >
> >Which may even be clearer. You could then style (Word) to be replaced with
> >a Word background image. Though that hides the text description of the
> >document type from sighted users leaving them only with an icon ...
> >
> >
> >
> >Rick
> >
> >
> >
> >
> >
> >
> >

From: David Farough
Date: Tue, Oct 04 2011 3:00PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Hi Angela:
First the screen reader speaks "Word document" followed by the document
title. This is fine.

however, you could argue that the title might be of more importance to
the user than the application or format of the document. This is a
judgement call.

Having the Word Document appear first in the link will cause all of the
Word documents to be grouped together if the user brings up the links
using the links list. So this is an argument for presenting the links
in this way.



David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: = EMAIL ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779

>
This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.
>
Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.

From: Angela French
Date: Tue, Oct 04 2011 3:21PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

So a links list reads the links in alphabetical order?

So what do others think:
Icon before the link (reads "Document Type" + "link label") or
Icon after the link (reads "Link label" + "Document type")?

I would think the latter would be preferable.

Thank you for your opinion.

>however, you could argue that the title might be of more importance to the
>user than the application or format of the document. This is a judgement
>call.
>
>Having the Word Document appear first in the link will cause all of the Word
>documents to be grouped together if the user brings up the links using the
>links list. So this is an argument for presenting the links in this way.
>
>
>
>

From: Jennifer Sutton
Date: Tue, Oct 04 2011 3:45PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Angela et al:

At 02:17 PM 10/4/2011, you wrote:
>So a links list reads the links in alphabetical order?
>
>JS: It CAN, but it may not necessarily. In JFW, as only one screen
>reader example, I can choose to read the list of links in either tab
>order or alphabetical order.

Perhaps it'll help to mention that, if I know a site well, I may
choose to navigate the links list by pressing the first letter of the
link I want to activate.

I haven't been following the discussion closely, so I will conclude
by mentioning a little story.

I once worked with folks on a site where they insisted on putting
"opens in a new window" at the beginning of every link. It didn't
matter in how many different ways I tried to explain the problem with
the approach.

Yes, it was "accessibility gone wild," especially since these were
pages of resources that were external to the site I was developing.

As a result of this decision, when navigating the links list, every
link started with o.

My vote is that the name of the document (or the site resource) that
I may or may not want to read is more important to me than the
filetype; I'd like to hear the filetype second.

Jennifer




>So what do others think:
>Icon before the link (reads "Document Type" + "link label") or
>Icon after the link (reads "Link label" + "Document type")?
>
>I would think the latter would be preferable.
>
>Thank you for your opinion.
>
><snip>

From: Lucy Greco
Date: Tue, Oct 04 2011 3:57PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

I always tell people to put the unique part first because of the links list word doc is meaningless as the first part of the link

Lucy Greco
Assistive Technology Specialist
Disabled Student's Program UC Berkeley
(510) 643-7591
http://attlc.berkeley.edu
http://webaccess.berkeley.edu


From: David Farough
Date: Wed, Oct 05 2011 7:42AM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

I agree with Jennifer. The title followed by the document type would be
my preference. I can see though, that people might prefer to have the
icon appear first so that everything lined up vertically, but doing this
causes the problem that Jennifer explained so well. There you have it,
accessibility/usability verses aesthetics.

David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: = EMAIL ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779

>>> Jennifer Sutton < = EMAIL ADDRESS REMOVED = > 05:42 PM Tuesday, October 04,
2011 >>>
Angela et al:

At 02:17 PM 10/4/2011, you wrote:
>So a links list reads the links in alphabetical order?
>
>JS: It CAN, but it may not necessarily. In JFW, as only one screen
>reader example, I can choose to read the list of links in either tab
>order or alphabetical order.

Perhaps it'll help to mention that, if I know a site well, I may
choose to navigate the links list by pressing the first letter of the
link I want to activate.

I haven't been following the discussion closely, so I will conclude
by mentioning a little story.

I once worked with folks on a site where they insisted on putting
"opens in a new window" at the beginning of every link. It didn't
matter in how many different ways I tried to explain the problem with
the approach.

Yes, it was "accessibility gone wild," especially since these were
pages of resources that were external to the site I was developing.

As a result of this decision, when navigating the links list, every
link started with o.

My vote is that the name of the document (or the site resource) that
I may or may not want to read is more important to me than the
filetype; I'd like to hear the filetype second.

Jennifer




>So what do others think:
>Icon before the link (reads "Document Type" + "link label") or
>Icon after the link (reads "Link label" + "Document type")?
>
>I would think the latter would be preferable.
>
>Thank you for your opinion.
>
><snip>

From: Jim Allan
Date: Thu, Oct 06 2011 2:33PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | Next message →

Here in Texas we are wrestling with the issue of accessible viewers.
In testing the Office document views from Microsoft are NOT accessible
to a screen reader (Jaws 12).
Additionally if you want user to view a .docx file they must also
download the MS Office Compatibility Pack. Then they must first
convert the file to .doc, then open in WordViewer. This is starting to
get very cumbersome for the end user.

From the viewer site: http://www.microsoft.com/download/en/details.aspx?id=4
The Word Viewer, together with the Microsoft Office Compatibility Pack
for Word, Excel, and PowerPoint File Formats, allows you open Word
documents saved in the following formats:

Word Document (.docx)
Word Macro-Enabled Document (.docm)
Rich Text Format (.rtf)
Text (.txt)
Web Page formats (.htm, .html, .mht, .mhtml)
WordPerfect 5.x (.wpd)
WordPerfect 6.x (.doc, .wpd)
Works 6.0 (.wps)
Works 7.0 (.wps)
XML (.xml)

Acrobat Reader is accessible.

We are considering linking to IBM Lotus Symphony , which will read
MSOffice office documents and is accessible (still doing a bit of
testing) BUT it is a 450+ mb download. There must be an easier less
convoluted solution.

Jim

On Tue, Oct 4, 2011 at 1:40 PM, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
> So Rick, you think just making the link on the title (and not on the icon) would suffice for screen reader users?  It bugs me that a table is used for this (as a table-less kinda of designer). Also, it just takes up so much more room vertically on the page than a simple list.  However, in terms of going back in fixing all the pages that do this, it would be a heck of a lot easier to just switch the link from the icon to the title.  My intent was to provide a means for screen reader users to know what kind of doc (or to an external site) is being linked to.  What do others think?
>
> Just this week I created a Document Readers page which will be linked to from any page that has documents for download.  It will be added as I go through the site and edit these inaccessible doc download methods.
>
> http://sbctc.edu/readers.aspx
>
>>

From: Angela French
Date: Thu, Oct 06 2011 2:48PM
Subject: Re: please test this method of identifying document icons with hyperlinks
← Previous message | No next message

Not sure the protocol for changing subject lines in threads, but can we do that on this one and keep this document viewer discussion going?
Angela French


>Here in Texas we are wrestling with the issue of accessible viewers.
>In testing the Office document views from Microsoft are NOT accessible to a
>screen reader (Jaws 12).
>Additionally if you want user to view a .docx file they must also download the
>MS Office Compatibility Pack. Then they must first convert the file to .doc,
>then open in WordViewer. This is starting to get very cumbersome for the
>end user.
>
>From the viewer site:
>http://www.microsoft.com/download/en/details.aspx?id=4
>The Word Viewer, together with the Microsoft Office Compatibility Pack for
>Word, Excel, and PowerPoint File Formats, allows you open Word documents
>saved in the following formats:
>
> Word Document (.docx)
> Word Macro-Enabled Document (.docm)
> Rich Text Format (.rtf)
> Text (.txt)
> Web Page formats (.htm, .html, .mht, .mhtml)
> WordPerfect 5.x (.wpd)
> WordPerfect 6.x (.doc, .wpd)
> Works 6.0 (.wps)
> Works 7.0 (.wps)
> XML (.xml)
>
>Acrobat Reader is accessible.
>
>We are considering linking to IBM Lotus Symphony , which will read MSOffice
>office documents and is accessible (still doing a bit of
>testing) BUT it is a 450+ mb download. There must be an easier less
>convoluted solution.
>
>Jim
>
>
>