Re: Text links 2.4.4 with PDF's

Hi Richard,

It is indeed very helpful to know which technologies are used or that  
would need for a particular document before you go there.
It would also be nice to know before you click on a link whether you  
have the technologies in your browser to handle the HTML page and  
other technologies on it  -- or whether it will even work with your  
browser  -- before you click the link.

Authors could decide to include either type of information in a  
link.   And in some cases that might be best practice.

However neither is required by WCAG.

Please note that there are many things that are useful to people with  
disabilities that are not required by WCAG for various reasons.    So  
the fact that something would be useful to some or all people with  
disabilities does not make it required by WCAG.   Only those things  
specifically required by one of the success criteria (or the  
conformance requirements) are required by WCAG.

We DO have advisory techniques that document things that would be  
useful and that go beyond the requirements of WCAG.  If you have a  
suggestion for a new technique we have a form that people can use to  
send it in.  The form is at

PS   With regard to 3.2.5: going to a new page is always a change of  
context - even if the new page is HTML.   Clicking on a link however  
is 'initiated by a user' so 3.2.5 does not apply to anything that  
happens after the person 'clicks' on a link .

Gregg
-----------------------



On Aug 7, 2009, at 10:40 AM, Richard Warren wrote:

> 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
>
>
>
>
>