Re: Text links 2.4.4 with PDF's

Dear Andrew

Ah - Ah - that old chestnut - "a disabled person must not be disadvantaged more than a non-disabled person - so if everyone is disadvantaged the same way it is not an accessibility issue". Here we could have a long and interesting discussion on this philosophical (sp!) point, but if we just concentrate on the link text issue I will explain my reasoning that poorly written link text does disadvantage some disabled users more than non-disabled users.

When a sighted user with a standard web browser focuses on a link using a mouse or keyboard the destination of the link is presented in the status bar at the bottom of the browser. This destination includes the document type extension (usually HTML, but in our case it would be PDF). Thus, as a sighted user, I can see that the link I am focused on goes to a file named "Report.pdf". I can therefore deduce that the destination is a PDF file and can avoid it if I have a slow connection.

Now if I have very limited vision and use an application such as Zoomtext 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. I thus have no way of knowing that the link is to anything other than a HTML file.

Now if I have no vision and use a basic screen reader to list out the links on the page I hear just the link text. You might argue that most screen readers also read out the detination file name, but I am not sure that this is universally so

Now if I have no vision and use a braille pad I only get one line at a time so I only get the link text as you would see it on the screen. I am no braille expert so someone who knows better may know if the destination file name itself can be read out before a link is selected but I have not seen it happen myself.

Now supposing I have good vision but am new to the web, or have learning dificulties, or am just too impatient to check the bottom of the browser every time I select a link - well perhaps I am streatching the point here.  I am sure others can think of more, better examples.

HOWEVER -  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 eqallly and your point is valid - on condition that both the disabled person and the non-disabled person only have access to a mobile phone. 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 (Remember the "baseline technology" concept)

Have a nice weekend

Richard



  ----- Original Message ----- 
  From: Andrew Kirkpatrick 
  To: Richard Warren ; w3c-wai-ig@w3.org 
  Cc: Gregg Vanderheiden 
  Sent: Friday, August 07, 2009 4:52 PM
  Subject: RE: Text links 2.4.4 with PDF's


  Richard,

  I understand that you disagree, but this is not an accessibility issue since the situation is the same for all users, irrespective of the presence or absence of any disability.

   

  Thanks,

  AWK

   

  Andrew Kirkpatrick

   

  Senior Product Manager, Accessibility

   

  Adobe Systems 

   

  akirkpat@adobe.com

   

  From: Richard Warren [mailto:richard@userite.com] 
  Sent: Friday, August 07, 2009 11:41 AM
  To: Andrew Kirkpatrick; w3c-wai-ig@w3.org
  Cc: Gregg Vanderheiden
  Subject: Re: Text links 2.4.4 with PDF's

   

  Hi Andrew,

   

  Sorry, I disagree. From my blind colleagues I know that a link to a PDF file that does not include a warning in the link text can be a real pain. I know Jaws 10 tells me the format (after the link text), but not all Assistive technology is that good. Anyway you are asking about the documented guidelines, so let's have a look.

   

  At Level A we have 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. 

   

  Here "purpose of link is clarified as "nature of the result obtained by activating a hyperlink". The result of activating a hyperlink is normally to open another HTML document (web page) or to jump to a specific part of an HTML page. This can be considered to be the default setting for hyperlinks. A PDF (or MSWord) document is not an HTML document. Not all browsers recognise the PDF format, Try following a PDF link when using Lynx. So the format is part of the purpose of the link (telling the user what will happen if the link is activated) because part of the purpose of this particular link is to open a PDF reader or a new window if you have a modern browser. This is different to the default (HTML) so needs to be clearly specified within the link text so that assistive software can present the links out of context and still warn teh user if it is not a link to a HTML document.

   

  Example 5 at http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H30.html shows one way to do this by including the PDF icon in the link text (with appropriate alt tag). But you can just use text as "<a href="WMFP.pdf">Woodend Music Festival Program (PDF)</a>. 

   

   

  At level AAA we have 3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

   

  Here change of context includes user agents (defined as "any software that retrieves and presents Web content for users") so changing from a web-browser to Acrobat Reader is a change of context. So we need to warn the user that there will be a change of context if the link is selected. Thus allowing the user to either avoid the link, or be prepared for the resulting change of context.

   

   

  So, although the WAI guidelines do not catagorically state that "you should include any non-html format in the link text", it is clearly implied and demonstrated throughout the documentation and suggested solutions that the format should be indicated within the link text. Exactly how you indicate the format is up to the author. I don't think you need the word "format" as that is implied, but the PDF (or Word or Powerpoint etc) logo or the file format extension (PDF, DOC, PPT etc.) should be adequate.

   

  With Section 508 you are probably correct, it is not a requirement. However I would argue that 508(m) "Web page requires an applet... the page must provide a link to the plug in or applet" shows that they are aware of the problem, but they only require a link to Adobe Acrobat on the page.

   

   

  Richard

   

    ----- Original Message ----- 

    From: Andrew Kirkpatrick 

    To: w3c-wai-ig@w3.org 

    Cc: Gregg Vanderheiden 

    Sent: Friday, August 07, 2009 2:42 PM

    Subject: RE: Text links 2.4.4 with PDF's

     

    From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Chris Reeve
    Sent: Friday, August 07, 2009 1:01 AM
    To: w3c-wai-ig@w3.org
    Subject: Text links 2.4.4 with PDF's

     

           

          I understand that the word (PDF format) in the text link is required.

           

          Geez - I guess no one believes me, but the indication that it is a PDF document that is being linked to is _not required_ by WCAG 2.0.  You may still want to do it, but this is not mandated by WCAG 2.0 or Section 508.

           

          Gregg, do you agree with this?

          Thanks,

          AWK