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,