RE: Text links 2.4.4 with PDF's

My boss is against displaying the file type and/or file size in the text link. 
 
He said if I displayed it as suggested in G189, use C7 to hide that section of the text link.
 
1) One option I thought of last night was alt tag. There is a sample where there is a link to <"pdficon.gif" alt="PDF format"> H30. I was wondering, can I use <alt="PDF format">, even if the destination site does not have the alt image for the pdf icon? At the moment G189is used and file type and file size is in my source code, but to satisfy my boss, I used C7
2) If the destination site already complies with 2.4.4 (by specifying file type and size) for downlodable documents, why do I need to comply?
3) Some pages we link to have bits one several PDF's. Combining all PDF's equals the intent ot the developer. They cannot use the technique of using one PDF.  Can I link to the page providing multiple PDF that make up one PDF?
4) A previous posting to the WAI Interest Group suggest to link to their html/text version. If I link to their html/text version (assuming it is provided), can I ignore the rest of the criteria stated at WCAG 2 to satify Succession Criteira 2.4.4
 
 
At the moment G189 is used and file type and file size is in my source code, but to satisfy my boss, I used C7. If you used view source code, G189 will show the file type and file size, but I created a style sheet for invisibility. As a sample from http://www.w3.org/WAI/WCAG20/versions/. It shows file type and file size. My invisibility style sheet would show "WcAG 2.0" and "Understanding WCAG 2.0", eventhough the source code would show a complete sample.
 
Gregg, I chose to cc you because this is the fourth time I have responded to the WAI Working Group on text links associated with PDF's. I will get let you know what each member thinks. Please follow up with me and let me know who is correct. As a remiinder I am currently adopting technique G189+C7. Reason: My boss is against using technique G189 in a text link.
 
I need options that can satisfy Succession Criteria 2.4.4 for downlodable documents, and my boss.
 
Sincerely,
Chris

--- On Mon, 8/10/09, Phil Spencer <spencer_phil@hotmail.com> wrote:


From: Phil Spencer <spencer_phil@hotmail.com>
Subject: RE: Text links 2.4.4 with PDF's
To: "Richard_Userite" <richard@userite.com>, "WAI Interest Group" <w3c-wai-ig@w3.org>, "Phill Jenkins" <pjenkins@us.ibm.com>
Date: Monday, August 10, 2009, 8:36 AM




#yiv1365175372 .hmmessage P
{
margin:0px;padding:0px;}
#yiv1365175372 {
font-size:10pt;font-family:Verdana;}

What about using the title attribute:

<p>Read my document <a href="document.pdf" title="this document is in PDF format">my document</a> </p>

To my mind this is correct use of the title attribute - to add contextual information. The information is problematically available and is attached to the element to which it relates. Whether or not this would be practically useful I don't know, e.g. Jaws doesn't seem to read title attributes on links in it's default set up.

Since the technique uses standard markup that would make the information available to all ATs? And thus would technically meet requirements?

Any thoughts?

Many thanks,
Phil Spencer.



From: richard@userite.com
To: w3c-wai-ig@w3.org; pjenkins@us.ibm.com
Date: Fri, 7 Aug 2009 22:58:18 +0100
Subject: Re: Text links 2.4.4 with PDF's





I was going to ponder Phil's reply over the weekend, but what the heck - yes he is right and I was wrong - compliance can be achieved without including the non-html format of a link target PROVIDING THAT there is no other indication on the page itself (other than the status bar) that the links are to a different (non-html) format. 
 
The following would not comply because sighted users would see the warning whilst AT users who list the links out of context would not.
 
<p> Read my document <a href="document.pdf">my document</a> , warning, this is a large PDF file </p>
 
However, this would comply
 
<p> Read my document <a href="document.pdf">my document</a> </p>
 
The second example may have usability problems, but as far as compliance with WCAG goes it does not disadvantage disabled people more than non-disabled, This may be perverse but it is compliant thanks to the last part of 2.4.4 "except where the purpose of the link would be ambiguous to users in general." 
 
So if you want to comply with level A or level AA, and do not want to "clutter up" your link text with document format information, make sure that you do not include links to Adobe acrobat or any other warnings about the different format of the link targets on the page.
 
Now, thanks Phil, I will go and read the fine manual and learn how to jump to the status line <G>
 
Richard
 
----- Original Message ----- 

From: Phill Jenkins 
To: WAI Interest Group 
Sent: Friday, August 07, 2009 7:49 PM
Subject: Re: Text links 2.4.4 with PDF's


Richard wrote: 

":...I only see a small portion of the screen at any one time and do not get a staus bar at the bottom (my whole screen is focused on a small area." 

True 

" I thus have no way of knowing that the link is to anything other than a HTML file." 

False.  Most all screen magnifiers and screen readers have a way, hot key, to jump and read the status line.  The status line is a known part of the user interface and its contents can be accessed.  Yes there are problems with so called moving content in the status line, but that is a different issue. 

So just as a sighted user can "move his eyes" and read the status line without moving the PC cursor, so can the AT user moves his reading cursor (a.k.a. point of regard) and read information without moving the PC cursor and move or jump back to the reading point where he last was.  Sure the sighted user may be able to "move his eyes quicker" but that is not the point either. The users using an AT is not anymore disadvantaged. 

"Now supposing I . . . have learning difficulties, or am just too impatient to check the bottom of the browser every time I select a link - well perhaps I am stretching the point here.  I am sure others can think of more, better examples." 

No I can't think of any better examples, except for mobile, which you discuss next. 

". . . if you are using a PDA or mobile phone does the destination file name appear on the screen? I think not (at least not on my daughters mobile). So here you can claim that everyone is disadvantaged equally"   

Yep. I agree you are making a point for usability for all users. 

"But in this case you would need to claim in your compliance certificate that the site was only to be used on mobile phone technology." 

Nope, because all the information is available equally to everyone, maybe not as usable as you would like, but accessible.  AND, there is plenty of argument for the opposite, to eliminate the file type or format - many users do not know the difference between HTML, PDF and Word - they just want to get the information.  They select the link and the new information is there to get.  Why should the author go through extra effort to confuse some users?  I personally agree with explaining the formats when given a set of choices, but often it really doesn't make any difference if it is PDF, Word, or HTML as long as it complies with accessibility guidelines, my AT supports it, and I have the plug-in installed, yada yada yada.. 
  
  
Regards,
Phill Jenkins, 




Celebrate a decade of Messenger with free winks, emoticons, display pics, and more. Get Them Now