Re: Fwd: Classification of AT in ATAG2

Geoff,

You raise a number of very good points that are directly related to 
issues we are presently attempting to tackle in the working group. I 
second Jan's invitation to join the working group so that we can 
benefit directly from your views and ideas.

Jutta

At 10:30 PM +1100 12/13/03, Charles McCathieNevile wrote:
>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 Tuesday, 16 December 2003 09:15:15 UTC