- From: Charles McCathieNevile <charles@w3.org>
- Date: Fri, 19 May 2000 06:07:02 -0400 (EDT)
- To: Marjolein Katsma <access@javawoman.com>
- cc: Heather Swayne <hswayne@microsoft.com>, Authoring Tools Guidelines List <w3c-wai-au@w3.org>, "'Gregory J. Rosmaita'" <unagi69@concentric.net>, "'love26@gorge.net'" <love26@gorge.net>, "'charlesmccn@yahoo.com'" <charlesmccn@yahoo.com>
I agree that a tool can be compliant if it ships with the default of all things accessibility-related turned off - provided that they are clear and obvious, as required by the P2 checkpoints in Guideline 5, (and the other stuff like GL6 is done). If I were doing a conformance review I would make it explicit that it conforms when in mode XYZ, but I don't see that as contradicting the statement that this tool conforms. Charles McCN (I have almost zero email access. Sigh) On Thu, 18 May 2000, Marjolein Katsma wrote: In a tool like HomeSite, by its very nature, all prompting for anything is always off - prompting never occurs unless the user actually requests a prompt. After all, the core is a text editor - any user can choose to just type text. Accessibilty checking would just be one of the tools made available, just like dropdown lists, inspectors and dialogs are now tools made available to the user - but none of the avaiable tools can ever be "forced" on the user. There are now some options for automatic alerts though (spell check and syntax check) - a similar option might be used for accessibility. Again, by the very nature of the product, even if the alerting is on (it can be turned off) it's still up to the user to ignore, repair manually (just type) or trigger a prompt. A prompt at saving is also out of the question: depending on the work method some documents will have to be saved literally hundreds of times while being worked on, before it's finalized. Also we should take into account that frequently the document being created or edited is not itself HTML but (a combination with) server-side code which will ultimately _generate_ the HTML to be sent to the browser; accessibility does not apply to server-side code, so even (forced) prompting at deployment time (as opposed to saving) is not an option in many cases: the server-side code is what will be deployed but only the resulting HTML (i.e., after deployment) can be checked. ==> I'll maintain that an authoring tool is compliant if it _provides_ the user with the necessary tools for alerting and prompting for accessibility. Whether those tools need to be or even can be switched on by default depends completely on the nature of the tool and its intended users (and languages supported!). At 15:08 2000-05-16 -0700, Heather Swayne wrote: >I request a poll or vote to see were the other members of the Authoring >Tools Working Group stand on this issue: > >Does an Authoring Tool comply with guideline 3.1 if the default setting of >their accessibility option is set to "no-prompting"? >Assuming: >1) Guideline 3.1 requires authoring tools to "prompt" (confront the user >with a dialog that would allows them to enter alt+text) at some time between >an image being inserted and the document being saved (saving does not >guarantee that the author has finished the editing process but it is the >first time that a user could potentially interact with the page and would >therefore would need to be compliant with Web content guidelines). >2) An authoring tool implements a "configurable" solution (allows authors to >choose/set the level of prompting ranging from no-prompting to force me to >make corrections as soon as an accessibility related error is detected). > >Asking the author questions during setup is not a reliable solution since we >cannot guarantee that the author (owner of the computer) has explicit >control over the setup of the computer (computers come pre-installed with >applications, a friend or IT professional could sets up the computer for the >author, a company could perform a silently install/upgrade or lock down the >installation preferences). > >I have an outstanding action item to submit a proposed definition for >prompting, but if the majority of the Authoring Tools working group feels >that the answer to the above question is "yes", then I will agree that >authoring tools came comply with guideline 3.1 as currently defined, but >will submit a request to include this example within the techniques >document. > >Related comments on this area: >-----Original Message----- >From: Gregory J. Rosmaita [mailto:unagi69@concentric.net] >Sent: Tuesday, May 02, 2000 5:04 PM > >as for "out-of-the-box" prompts and alerts, the user could choose/set the >level of prompting during the installation routine, provided that -- if the >user chooses "No Prompts or Alerts", he or she is presented with a "Readme" >type dialog box/application window, before the installation process ends, >in which (a) the benefits of checking for accessibility, (b) the means of >checking for accessibility available through the tool, and (c) how to turn >them on, off, and configure them are explained _in full_ to the user... i >would also argue that in order to comply, you would have to provide a >warning and a "more information" button when the user who has turned off >all accessibility checking issues the "Save" command, as well as a "Fix It >Now" mechanism (which i would prefer to "see" on the dialog that pops up >when the user who has disabled all of the accessibility >checking/prompting/alerting features of the tool off, rather than as part >of the "More Information" interface, but that is, i suppose an >implementation decision... > > >-----Original Message----- >From: Charles McCathieNevile [mailto:charlesmccn@yahoo.com] >Sent: Wednesday, May 03, 2000 7:33 AM > >In the discussion about whether or not a tool conforms out of the box, >I would follow the precedent set by Wendy Chisholm's evaluation of >HotMetal, in which she said that in accessibility mode the tool >conforms, and I would regard that as a conforming tool (subject to the >provisions of guideline 5). > > >-----Original Message----- >From: love26@gorge.net [mailto:love26@gorge.net] >Sent: Tuesday, May 02, 2000 3:59 PM > >HS:: "Any tools that followed this suggestion would not be single-A >compliance "out-of-the-box", unless the accessibility option was set to >force prompts." > >WL: I believe that this misunderstanding is at the root of a problem we >are experiencing. The configurability *INCLUDING THE DEFAULT SETTINGS OF >THE VARIOUS ACCESSIBILITY FEATURES* does not affect the conformance >level of the tool. That is my understanding. > >If the tool makes all the important features an integral part of the >regular look/feel, (even though these features may be set to "off" by >the user) it can be triple-A conformant - even if it is "shipped" in a >default mode that some insensitive sales/marketing department has >decided is the "best practice" for their customers. > >Even though many will have the opinion that: people don't want >"in-your-face" warnings when they're creating Web materials; surveys >show that these features aren't important to most purchasers - the >market for accessible (for which read "usable") sites and especially >tools that are easily able to create such sites is much larger than >expected. Marjolein Katsma HomeSite Help - http://hshelp.com/ Bookstore for Webmasters - http://hshelp.com/bookstore/bookstore.html -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053 Postal: GPO Box 2476V, Melbourne 3001, Australia
Received on Friday, 19 May 2000 06:09:15 UTC