- 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) true > 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 yes >. . . 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. Regards, Phill Jenkins
Received on Saturday, 8 August 2009 00:50:46 UTC