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

Re: Text links 2.4.4 with PDF's

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Fri, 7 Aug 2009 19:49:57 -0500
To: "Richard Warren" <richard@userite.com>
Cc: "Andrew Kirkpatrick" <akirkpat@adobe.com>, "Gregg Vanderheiden" <gv@trace.wisc.edu>, w3c-wai-ig@w3.org, w3c-wai-ig-request@w3.org
Message-ID: <OFF9A635D9.55EB65D5-ON8625760B.0082EFA5-8625760C.0004931A@us.ibm.com>
>  . . . 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 . . . 

Not in my opinion, the developer/author it is not required to add the doc 
type with text.  2.4.4 includes the phrase "or from the link text together 
with its programmatically determined link context." 

if the doc type is available programmatically, then I believe that meets 
2.4.4.  Personally I can't justify why the doc type, size or anything else 
is required ALL the time when its available if I want it.  It is 
definitely confusing to some user and requiring it in the text is starting 
to border on reading the source HTML code, ugh.

'context' here is ALSO to be considered, so that if the purpose of the 
link is to, perhaps, download a file, then that should be available in the 
context to meet 2.4.4, not necessarily in the text of the link itself.  . 

>Try following a PDF link when using Lynx.

Does anything happen differently to a user with or without a disability, 
with or without a screen reader using LYNX? 
I would suspect not, so how is it an accessibility issue?  although I 
agree it is an equally bad issue for everyone using LYNX.

Remember too that H30 is a 'sufficient' technique, not a 'required' 
technique.  And I agree that "including the PDF icon in the link text 
(with appropriate alt tag)" could just as easily be done by adding the 
'(PDF)' text string but I believe usability studies show that adding icons 
make is easier for sighted user with cognitive disabilities, so I 
personally would recommend the icon with alt attribute.

>. . . level AAA we have 3.2.5 Change on Request: . . . Here change of 
context includes . . . changing from a web-browser to Acrobat Reader


>. . .  So we need to warn the user that there will be a change of context 
if the link is selected.

Not in my opinion.  Most all links cause context changes.  A new page is 
also a change of context.  The point of the requirement is that the user 
needs to initiate the change, that it NOT happen without the user's 
request i.e, clicking the link.  The "warning: is only needed in my 
opinion if additional or un requested changes occur - for example, the 
server will disconnect after 20 minutes of inactivity - that is the issue.

> So, although the WAI guidelines do not categorically state that "you 
should include any non-html format in the link text"

Correct, and that is on purpose I believe

> it is clearly implied and demonstrated throughout the documentation . . 
. Exactly how you indicate the format is up to the author. but the ... 
logo or the file format extension (PDF, DOC, PPT etc.) should be adequate

I agree it is used often in the guidelines, but it is not implying that 
file type is required.  It is implying that when you have 3 similar links 
together that go to different places, a sufficient (but not required) way 
to do it is with the 3 icons or additional file type in the link text. 
Maybe we need more or better techniques.  But we still give the 
developer/author some flexibility and the standards writers some future 
capability to share new and improved examples.  Wouldn't it be "easier and 
more accessible" for me to set a setting in my browser or AT to always 
give me my preferred format when there is a choice? DO I want the CSS 
version for printing or the PDF version for printing?  maybe I don't need 
to even be confused with the choice if it really doesn't matter.

Phill Jenkins
Received on Saturday, 8 August 2009 00:50:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:34 UTC