- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 18 May 2005 09:12:14 -0500
- To: "'Michael Cooper'" <michaelc@watchfire.com>, <w3c-wai-gl@w3.org>
I see your issue. Hmmmm The problem isnt with PDF or some 'mainstream' technology. The problem is with plug-ins and applets that are not something that you can assume a person has. Or - in the case of PDF - a plug in where you won't have the right one. With PDF - there was the standard plug in - -then there was a special one that you had to know about or the content wasn't accessible. (this is no longer true to my understanding). Baseline doesn't solve it because the user doesn't have the technology. OR you have a very limiting situation where the author CANNOT use a technology because it isn't in the baseline - so they can't depend on it - even if they will provide it. But the proposed wording may not work either. Do we assume that a plug in must be available for all platforms??? Boy - you raise another interesting question with this cross platform issue. Do we have to assume that technologies work across platform? If so how many? Must a technology work for windows and mac and linux? And GO? And Symbion? And .... Many plug-ins don't. or the accessible versions are only available on one platform. So can one use them in a baseline? Ouch. Oh - and the one you suggested also has a problem A mechanism is available and associated with the content for downloading a user agent that renders the content in a manner that allows the content to conform to these guidelines. This sounds like all pages would need a link to a site to download IE or HPR or some accessible browser. Oops- again - for what platforms. This one just keeps getting harder. But just tossing it over the side doesn't work I don't think. Baseline and UAAG only apply to things that the user can get in advance. Not to things that the author requires you to download on the fly. And especially not to custom engines for accessing data for presentation. Applets certainly fall in this category. Plug-ins may or may not depending on how 'standard' they are. But I routinely hit sites where I need to go get things to view them - especially the first 3 months after buying a new computer. And I don't know where to get accessible versions of things - nor is there any mechanism for requiring that authors provide them if it is not in the WCAG. Hmmmmmmm Loretta, you sure volunteered for a tough one. Gregg Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Michael Cooper Sent: Wednesday, May 18, 2005 8:02 AM To: w3c-wai-gl@w3.org Subject: RE: addition proposal, GL 4.2 I'm uncomfortable with a proposal to say something about plugins, because the differentiation between "browser" and "plugin" is somewhat a characteristic of the present time which I think will disappear. It's also somewhat HTML-centric since I think most other content types don't render included content via a mechanism that we would consider a plugin. Joe points out that even across operating systems in the present day the situation may vary. In my opinion the entire issue is covered by the baseline. When you choose a baseline, you assume the user agent is capable of rendering the content, by definition. Whether the user agent requires a plugin to do so is not our concern. When choosing a baseline intelligently we would want to consider widespread availability of user agents capable of rendering the content in an accessible manner, but we would not concern ourselves with whether those user agents are called "browsers" or "plugins". For this reason I don't think this proposed success criterion is necessary or desirable, and would proceed with the decision to remove 4.2 altogether. However, if the group feels it is important to adopt this success criterion, we would need to generalize it. As a first stab, let's try: <proposal> A mechanism is available and associated with the content for downloading a user agent that renders the content in a manner that allows the content to conform to these guidelines. </proposal> Note 1: I see the problem here that I'm saying "provide in your content a way to get a user agent that can render the content". That could be pretty useless if done badly, e.g., the link to download the Acrobat viewer was in the PDF file. Note 2: To underscore, this is a _fallback proposal_. My _actual_ proposal is to not add this success criterion. Michael > -----Original Message----- > From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On > Behalf Of lguarino@adobe.com > Sent: May 16, 2005 9:55 AM > To: w3c-wai-gl@w3.org > Subject: addition proposal, GL 4.2 > > > > Although we have proposed additional success criteria to cover general > user agent requirements, the GL 4.2 subgroup feels that we may still > need to keep guideline 4.2 to deal explicitly with plugins and > applets. We propose the following Level 1 Success Criterion: > > <proposal> > When rendering or operating content requires a plug-in or applet, a > mechanism is available and associated with the content for downloading > a version of the plug-in or applet that allows the content to conform > to these guidelines. > </proposal> > > > >
Received on Wednesday, 18 May 2005 14:16:14 UTC