The Problem of Web Based Authoring (revisited)

Hi,

Regrets for being off list for a bit over a month.  But I have still be
thinking about matters I have raised before.  I did begin work on writing a
long technical article covering items I have raised, but I don't think that
is a good approach, unless those here want to engage in a technical
discussion.

This is the crux of my point, that in spirit ATAG is heading in the right
direction, but I feel it is seriously flawed by it's naivety at addressing
technical issues and clarifications.  And I feel these issues of technical
inadequacies are so serious as to have the effect to alienate and loss the
developer community, specifically ones that are building web based authoring
tools.

I will just briefly make these points, and if anyone wants to discuss them,
then I am willing to expand on them and clarify these issues.

As I have said before, there is a problem with grouping all these guidelines
together and applying them generically to all the Authoring Tool categories
(http://www.w3.org/TR/2004/WD-ATAG20-20040224/#what-auth-tool).

First point, "Software Accessibility Guidelines" and WCAG share the same
focus and aims, but they are aimed at technically different types of
application that run under different programming environments and are
therefore subject only to the rules governing those environments, one is
aimed at software that operates on APIs, and the other is based on markup
render via a user agent.  I believe ATAG has to be very clear which is which
and technically correct, otherwise the effort put into these guidelines will
be wasted on the developer community they are aimed at.  To see some of my
initial points, please refer to;

http://lists.w3.org/Archives/Public/wai-xtech/2003Dec/0002.html

I feel there is need clarify this document so that the right guidelines are
applied to the correct type of authoring tool.

I am also afraid to say that I feel there is a need for a third type of
category (1. Software Accessibility 2. Web Content Accessibility Guidelines
3. Web Application Accessibility), the problem is that *every" "Web Based
Application Tool/ CMS Interface" I have seen does not comply with WCAG1
Priority 1.  All of them rely on scripts (Java, JavaScript), many rely on
popups for certain functions of the user interface, etc.  I just cannot see
any of them seeing the benefits of transferring all scripting to the server
side and trying to become ATAG compliant.  They are all script dependant.

I did 2 days of Interwoven Teamsite training a few weeks back, and I just
could not see any reason why they would try and comply to the letter of
these guidelines.  What is the benefit to any of the CMS developers to
follow ATAG, because it will surely kill their product in the general
market, it will put them so far behind their competitors.

Can anyone else see these issues, or am I a lone voice on this list in this
regard?

Geoff Deering

Received on Sunday, 7 March 2004 22:41:55 UTC