Fwd: Classification of AT in ATAG2

Début du message réexpédié :

> Resent-From: wai-xtech@w3.org
> De: Charles McCathieNevile <charles@sidar.org>
> Date: Sat 13 Dec 2003  22:25:30 Australia/Melbourne
> À: gdeering@acslink.net.au
> Cc: WAI-XTech <wai-xtech@w3.org>
> Objet: Rép : Classification of AT in ATAG2
>
>
> Hi Geoff,
>
> I think this is really an issue for the ATAG group, so I will bounce 
> my response to them.
>
> I think the guidelines are pretty clear that a collection of web forms 
> are covered as an authoring tool, and that they should conform. Of 
> course many of the simpler systems, that literally just use a 
> textarea, are not going to be able to conform, just as any tool which 
> is poorly designed and has very limited capability will not conform. 
> (Note pad or emacs would be relatively easy tools to build as 
> conformant, ut neither of them do as available...)
>
> Anyway, I have gone through and listed ways I think such systems can 
> conform to each checkpoint from the latest internal draft (october).
>
> Assumptions: I have in mind tools like WikiWiki, or MkDoc (two very 
> different types of tool, but both using basic web forms as the 
> interface). These keep a local copy of the document they are dealing 
> with, and they rely on some kind of server side processing (in order 
> to comply with accessibility guidelines for their environment they do 
> not rely on Javascript, although they could use it to speed up some 
> processes for some users).
>
> cheers
>
> Chaals
>
> GUIDELINE 1: Ensure that the tool itself is accessible
> 1.1 Ensure that the authoring interface follows applicable software 
> accessibility guidelines. ([Priority 1] for required elements of the 
> software accessibility guidelines; [Priority 3] for recommended 
> elements of the software accessibility guidelines.)
>
>   This should be straightforward - the applicable guidelines in this 
> case are WCAG.
>
> 1.2 Ensure that the authoring interface enables accessible editing of 
> element and object properties. [Priority 1]
>
>   Hmm. This isn't one hundred percent clear - does accessible mean 
> that you can substitute easy-to-uunderstand images for bizarre bits of 
> code? Anyway, at a trivial level accessible only to people who don't 
> have certain disabilities, Wiki software allows structure to be edited 
> relatively easily in a textarea.
>
> 1.3 Allow the display preferences of the authoring interface to be 
> changed without affecting the document markup. [Priority 1]
>
>   This is a matter of being able to apply a stylesheet for the 
> authoring interface page. The possibilities that browsers offer for 
> textarea elements themselves at the moment are surprisingly limited, 
> for no particularly obvious reason. This is the sort of thing that 
> Xforms (a W3C Recommendation with a number of implementations) does a 
> lot better than old-fashioned forms, so we can expect a steady 
> improvement in this area.
>
> 1.4 Ensure that the authoring interface enables the author to navigate 
> the structure and perform structure-based edits. [Priority 2]
>
>   One way to do this is to provide an interface directly to the 
> structure - something like Amaya's structure view - which allows for 
> selecting parts of the structure and performing assorted operations on 
> them. There are plenty of tools that layout an outline view - doing 
> this in a form, where you can select things like changing the nesting 
> level of lists or list items, or the level of headings, is not very 
> hard. Selecting a section and moving it to another part is slightly 
> more complex - you need to implement a few functions at once - but 
> hardly rocket science. A copy/paste buffer isn't exactly a new idea, 
> for example - even one that holds multiple items.
>
> 1.5 Ensure the authoring interface allows the author to search within 
> the editing views. [Priority 2]
>
>   Web pages do this pretty much automatically. Being able to look for 
> particular structures would be a neat improvement that this kind of 
> tool could offer.
>
> GUIDELINE 2: Ensure that the tool is designed to produce accessible 
> content
> 2.1 Ensure that markup which the tool automatically generates is valid 
> for the language the tool is generating. [Priority 1]
>
>   This should be something that tool developers do as a matter of 
> course. But then people who pay real money for tools that can't do 
> this are not helping the case.
>
> 2.2 Use the latest versions of W3C format Recommendations when they 
> are available and appropriate for a task. [Priority 1]
>
>   A web-based tool isn't like a piece of application software that has 
> been burned onto a CD - it can check the RDF description of W3C 
> specifications to ensure that it is using the latest version of 
> whatever it is creating...
>
> 2.3 Ensure that the author can produce accessible content in the 
> markup language(s) supported by the tool. [Priority 1]
>
>   Again, this is something that should be a default, but often isn't. 
> Essentially it means reading the documentation before you implement a 
> tool to produce something, and providing a reasonable amount of 
> flexibility.
>
> 2.4 Ensure that the tool preserves all accessibility information 
> during transformations, and conversions. [Priority 1]
>
>   There aren't that many relevant operations - paste (where you might 
> want to allow paste of source as well as paste of content).
>
> 2.5 Ensure that when the tool automatically generates content it 
> conforms to the WCAG. [Relative Priority]
>
>  This is always interesting to implement, but shouldn't be any 
> different in a web-based tool - routines for generating code are 
> algorithms, so  the same things apply.
>
> 2.6 Ensure that all pre-authored content for the tool conforms to 
> WCAG. [Relative Priority]
>
>   Again, this ought to be blindingly obvious. The reason for it 
> belonging in the guidelines is that it clearly isn't, but there is 
> nothing special about web-based interfaces in this respect.
>
> 2.7 Allow the author to preserve markup not recognized by the tool. 
> [Priority 2]
>
>   This one again is hard in all tools, but there is nothing special 
> about any particular user interface mode (beyond the fact that source 
> editing makes it easier than WYSIWYG editing).
>
> GUIDELINE 3: Support the author in the production of accessible content
> 3.1 Prompt and assist the author to create accessible content. 
> [Relative Priority]
>
>   This is really about how the interface is designed. If you have a 
> bare form, and say "put stuff here", you can expect all kinds of 
> rubbish. If you guide the author,  as a useful tool does, you can do 
> this.
>
> 3.2 Check for and inform the author of accessibility problems. 
> [Relative Priority]
>
>   Web-based tools could always rely on the free online checkers for 
> some of this. Or they can integrate serious tools on the backend. Or 
> be developed with new and better tools included.
>
> 3.3 Assist authors in repairing accessibility problems. [Relative 
> Priority]
>
>   Explaining where the problem is, giving the author a chance to fix 
> the broken bit, and providing relevant help information, all in the 
> same page, is something that web-based interfaces should be extra good 
> at.
>
> 3.4 Do not automatically generate equivalent alternatives or reuse 
> previously authored alternatives without author confirmation, except 
> when the function is known with certainty. [Priority 1]
>
>   This is the same for any kind of tool.
>
> 3.5 Provide functionality for managing, editing, and reusing 
> alternative equivalents for multimedia objects. [Priority 3]
>
>   Being online, web-based tools can make use of the full richness of 
> the semantic Web more easily than most software can...
>
> 3.6 Provide the author with a summary of the document's accessibility 
> status. [Priority 3]
>
>   This is not materially affected by the tool being online.
>
> The following documentation checkpoints can be met for any tool - it's 
> just a case of writing it...
> 3.7 Document all features of the tool that promote the production of 
> accessible content. [Priority 1]
> 3.8 Ensure that accessibility is modeled in all documentation and 
> help, including examples. [Priority 2]
> 3.9 Document the workflow process of using the tool to produce 
> accessible content. [Priority 3]Note: The term "workflow" still needs 
> definition.
>
> GUIDELINE 4: Promote and integrate accessibility solutions
>
> The following are requirements on the things that are available in the 
> user interface, and how they are laid out, but there is no magic about 
> web-based systems that makes them significantly easier or harder, 
> beyond the fact that being online provides a potentially easier path 
> to a lot of existing information in its most up-to-date version.
>
> 4.1 Ensure that the most accessible option for an authoring task is 
> given priority. [Priority 1]
> 4.2 Ensure that accessibility prompting, checking, repair functions 
> and documentation are always clearly available to the author [Priority 
> 1]
> 4.X Ensure that accessibility prompting, checking, repair functions 
> and documentation are well integrated into the tool workflow. 
> [Priority 2]
> 4.3 Ensure that accessibility prompting, checking, repair functions 
> and documentation are naturally integrated into the overall look and 
> feel of the tool. [Priority 2]
>
> Cheers
>
> Chaals
>
> On Thursday, Dec 11, 2003, at 13:12 Australia/Melbourne, Geoff Deering 
> wrote:
>
>>
>> I was involved in a discussion on the WAI GL list a few months back 
>> regarding the problem with formatting authors input content into 
>> marking up via forms from TEXTAREA elements.  Many CMSs and Web log 
>> software, including forum software, often use a combination of 
>> javascript toolbars and backend filters to process the user text into 
>> marked up content.
>>
>> Someone on that list asked me to take a look at ATAG2, so I did, but 
>> have not had time to address the issues I found until now.  I did 
>> have a discussion off list with 2 W3C people related to these areas, 
>> but it seems that the issues I raised did not register as major 
>> concerns to them.  So I will endeavour to share it here.
>>
>> The problem I have with ATAG2 is that I feel there is a clear need to 
>> define tools according to the environment they operate.  Application 
>> software operates within the domain of the operating system API and 
>> therefore is bound by the SDK and the Interface Standards of that 
>> operating system.  The good thing is that amongst all the major 
>> operating systems, these standards are quite uniform and consistent.
>>
>> Web forms are also an authoring tool environment, but they are not 
>> subject to, nor do they have access to the operating system APIs.  
>> They are outside the domain of being able to call or interact with 
>> it.  They do not even have access to the user agents run time 
>> environment.  The user agent, as native application software has 
>> access to the operating system API, the Systems Metrics and their own 
>> runtime engine manipulating the resources according to user 
>> configuration.  Web based AT only have the basic form processing 
>> abilities and access to the DOM via the user agents DOM 
>> implementation.
>>
>> There are other authoring tools that utilise a WYSIWYG environment 
>> within the runtime environment of a particular user agent.  Then 
>> there is also sets of scripts and programs that could also be 
>> classified as authoring tools by their ability to be configured to 
>> interpret and parse documents and transform them according user 
>> configuration.
>>
>> My point is, as it stands, ATAG2 does not clearly define each of 
>> these authoring environments and classify its guidelines accordingly. 
>>  ATAG2, as a document, bundles all these tools into the one basket, 
>> not defining which classification of tools should be compliant with 
>> which set of guidelines.
>>
>> For instance, only authoring tools that are built as native software 
>> applications (ie Dreamweaver, FrontPage, etc) can comply with any of 
>> the guidelines under points 1.x.  (1,4 & 1.5 not impossible but 
>> improbable for non native apps).  You cannot apply these guidelines 
>> if your mandate is to develop a web forms authoring tool to meet all 
>> of ATAG2.
>>
>> What is needed is clear classifications of these AT in the document. 
>> For instance;
>>
>> Application software needs to comply with check point A,B,C, etc
>> Web Based form AT need comply with XYZ
>> Scripts need to comply with OPQ
>> whatever.
>>
>> You may say that everyone understand this, and lets just pretend that 
>> is so.  The problem then comes up in a business and functional 
>> specification when a business, department or vendor wants a web based 
>> interface authoring tool for their CMS and it has to comply with 
>> ATAG2 as laid out in the contract or specifications.  At that point I 
>> get very worried if this clarification is not in the document.  Why, 
>> because I have been in so many situations where the aim is not so 
>> much for a quality product, but to screw the software developers or 
>> create a back door for an escape clauses that show the software 
>> developers have not delivered on the product specified.  In such 
>> cases the flaw would lie squarely with the ATAG2 document.
>>
>> So I feel there is need to address these technical clarifications for 
>> ATAG2 to be a responsible document and be technically correct.
>>
>> Geoff Deering
>>
>>
> --
> Charles McCathieNevile                          Fundación Sidar
> charles@sidar.org                                http://www.sidar.org
>
>
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org

Received on Saturday, 13 December 2003 06:31:33 UTC