W3C home > Mailing lists > Public > wai-xtech@w3.org > December 2003

Re: Classification of AT in ATAG2

From: Geoff Deering <gdeering@acslink.net.au>
Date: Sun, 14 Dec 2003 01:55:48 +1100
Message-ID: <3FDB2874.8010404@acslink.net.au>
To: Charles McCathieNevile <charles@sidar.org>
Cc: WAI-XTech <wai-xtech@w3.org>

Charles McCathieNevile wrote:

> I think this is really an issue for the ATAG group, so I will bounce my 
> response to them.

I was not allowed access to the ATAG list even though I eventually said 
I would agree to the charter (do the work necessary to address these 
issues), so I was given access to this list as the appropriate one and 
told to post it here.

> 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. (

Are you saying that a collection of web forms should and can conform to 
all these guidelines?

> Note pad or 
> emacs would be relatively easy tools to build as conformant, ut neither 
> of them do as available...)

Are you saying that a product like Notepad, or something similar could 
be made to conform to ATAG2 guidelines without inherently changing the 
application into something to far beyond what it inherently is?

> Anyway, I have gone through and listed ways I think such systems can 
> conform to each checkpoint from the latest internal draft (october).

If you are saying explicitly that these other tools "conform to each 
checkpoint (all)" I beg to differ and am willing to expand on my points 
to show my case, which is why I raise this issue.

> 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).
> 

There are two areas here, the direct interface to the wiki and the wiki 
backend, and this is why I am concerned, there seems to be a falling 
down of technical clarity and distinction that I feel is very important 
to clarify.

I will address the following once I receive a response to the above.

> 
> 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
Received on Saturday, 13 December 2003 10:34:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:29 UTC