W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2009

RE: Text links 2.4.4 with PDF's

From: Phil Spencer <spencer_phil@hotmail.com>
Date: Mon, 10 Aug 2009 09:36:41 +0100
Message-ID: <BAY124-W3ACB2A5EA5C3F1FFBC8C8F1060@phx.gbl>
To: Richard_Userite <richard@userite.com>, WAI Interest Group <w3c-wai-ig@w3.org>, Phill Jenkins <pjenkins@us.ibm.com>

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, 



_________________________________________________________________

Upgrade to Internet Explorer 8 Optimised for MSN.  

http://extras.uk.msn.com/internet-explorer-8/?ocid=T010MSN07A0716U
Received on Monday, 10 August 2009 08:37:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:32 GMT