- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 25 Jan 2006 22:18:24 -0600
- To: "'Christophe Strobbe'" <christophe.strobbe@esat.kuleuven.be>, <w3c-wai-gl@w3.org>
At 19:30 25/01/2006, Gregg Vanderheiden wrote: <blockquote> I'm trying to work out the implications here. Would this have the effect of making only markup languages conform (declarative) but not script (imperative)? </blockquote> Christophe Strobbe wrote: To my understanding, scripts would not conform, so this will never be accepted at a level higher then L3. Also, I don't know what this does for PDF and Flash (to name just two examples). GV: I'm not sure I follow. Are you saying that "programmatically determined could only be at level 3? Or that scripting techniques could only be used at level 3? Or something else? If Scripting is in the baseline - it should be ok to use at any level. Gregg: <blockquote> Also, declarative doesn't mean that AT can actually access it - even if it is static. </blockquote> I pointed out the distinction between declarative and imperative under the assumption that declarative code would make changes of context (or any other events) much easier to determine programmatically. As far as I know, we can't make it easier than that. For example, for changes of context, imperative code specifies how certain events should be handled, but declarative code specifies what should happen and the "how" could be left to the user agent. User agents may then (hopefully) handle certain events in a way that is less confusing than what we now get with JavaScript. In markup languages, VoiceXML and XForms are the only technologies that I know of that use declarative events and handlers. GV: Don't follow what you are saying. Not having script is easier than with it. But if AT can handle it - then it shouldn't be barred. Gregg: <blockquote> Our problem was that we can't define AT specifically without naming specific AT (since there is no AT interop standard). And this doesn't seem to address that. </blockquote> No, the suggested approach is different: instead of naming AT, name specific types of technology features that they should be able to determine programmatically. GV: This gets back into theoretical accessibility. It isn't whether a person with a disability can access the content. It is whether theoretically they should be able to if the AT existed. This is something we have talked about. But so far - we have been thinking that baselines would be selected based on what actually did work. Gregg: <blockquote> It is a very interesting thought though. Just not sure if it addresses the key problem. </blockquote> It does not make a difference to 3.1.1 (normally). It makes a difference for content that is inserted, deleted or modified as a result of events, so it affects 1.3.1, 1.3.2, 1.3.3, 1.3.5, 2.4.1, 3.1.2. It is very important for components or controls that are very frequently manipulated by scripts, especially form controls, so the distinction between declarative and imperative has a high impact on 4.1.2, 4.1.3, 4.1.4, 4.1.5. (References are to the editor's draft of 17 January, at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20060117/guidelines.html). GV: Yes PD does affect a lot of the success criteria, either way. Thanks for the ideas. Regards, Christophe -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Christophe Strobbe Sent: Wednesday, January 25, 2006 11:54 AM To: w3c-wai-gl@w3.org Subject: programmatically determined and AT Hi, We still don't have a satisfactory solution for "programmatically determined" and AT. "Theoretically programmatically determined because defined in formal specifications" is not sufficient because there may be features in specifications that no AT has implemented yet. On the other hand we can't just say "AT" without saying which AT. What we have not discussed so far is the distinction between - programmatically determined in a declarative manner, and - programmatically determined in an imperative manner. This distinction is based on the distinction between declarative and imperative (programming) languages: - imperative languages basically describe sequences of operations, - declarative languages basically describe what is computer.[1] We deleted the old SC 3.2 L1 SC1 ("Any change of context is implemented in a manner that can be programmatically determined.") on the basis that any change of context that cannot be programmatically determined will simply never happen because a UA cannot detect that it is supposed to happen. The SC would not have been removed if it had read: "Any change of context is implemented in a declarative way". That would have ruled out changes of context caused by JavaScript (which is an imperative language), which many will find to strong at level 1. The distinction between declarative and imperative is interesting because it is what gave rise to the XML Events spec (http://www.w3.org/TR/2003/REC-xml-events-20031014/) and the use of XML Events in XForms (http://www.w3.org/TR/2003/REC-xforms-20031014/). Many things that HTML form authors do with JavaScript (imperative code) can now be done with XML Events (required fields, hints, context-sensitive help, adding fields based on the value of other fields, etc). This has the advantage that events (and therefore changes of context) are "statically analyzable": there's no need for AUs to actually run any code (JavaScript) to find out what kinds of events might happen. Can this be a way out of this catch-22? [1] More on this subject at http://www.csc.liv.ac.uk/~frans/OldLectures/2CS24/declarative.html and http://en.wikipedia.org/wiki/Declarative_programming. Regards, Christophe Strobbe -----End Original Message----- -- Christophe Strobbe K.U.Leuven - Departement of Electrical Engineering - Research Group on Document Architectures Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Thursday, 26 January 2006 04:18:39 UTC