Re: 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

Received on Saturday, 13 December 2003 06:26:36 UTC