W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 2005

RE: Requirements on repair

From: Roberto Scano (IWA/HWG) <rscano@iwa-italy.org>
Date: Fri, 25 Feb 2005 09:03:51 +0100
To: <bregan@macromedia.com>, <w3c-wai-au@w3.org>
Message-Id: <200502250300765.SM06912@Inbox>

Hi Bob,
I see ATAG 2.0 as a future rec., like xhtml 2.0: at now there are no browser conformed.
Also there is a previous version of ATAG (1.0) for what existent products should conform.
It is true that potentially there are no tools that conform, like is true that since few months ago nobody (=editor producers) was interested to create code conformance.
The born and success of plug-ins (see ektron, xstandard, and the "old" tidy) show that developers need these enchangements.

----- Messaggio originale -----
    Da: "Bob Regan"<bregan@macromedia.com>
    Inviato: 24/02/05 23.28.36
    A: "w3c-wai-au@w3.org"<w3c-wai-au@w3.org>
    Oggetto: Requirements on repair
      I want to raise a serious concern I have with the current state of the draft
    of ATAG. 
    The current draft requires a number of elements that are not currently
    available in mainstream authoring tools. Specifically, these include:
    (3.3) Assist authors in repairing accessibility problems.
    (3.2) Check for and inform the author of accessibility problems.
    (3.5) Provide functionality for managing, editing, and reusing alternative
    To my knowledge, there are no authoring tools on the market that current
    perform these tasks. As a result, ATAG requires one of two things. Either
    (a) customers need to buy or install additional tools or (b) Macromedia
    would need to acquire these technologies. Neither is a positive outcome for
    The former represents the status quo in many respects. There are a number of
    specialty products available today to validate and repair for accessibility.
    These are tools like LIFT, AccRepair, A-Prompt etc. Today, many of us
    encourage authors to make use of a collection of tools to ensure that
    accessibility of their content and applications. This is in many ways a
    productive division of labor. These companies devote a tremendous amount of
    effort to looking at accessibility evaluation and repair issues. As small,
    focused companies and funded academic efforts, these groups are able to
    devote a level of attention that is very hard to get within the medium to
    very large companies that build the actual authoring tools. I liken this
    division of labor to the one between makers of user agents and assistive
    My first concern is that the current draft does not allow any one tool
    available to meet the requirements of ATAG. From a vendor perspective, this
    will come back from customers as, "Dreamweaver is not ATAG compliant." ATAG
    is not written as a procurement standard. It is written as a development
    standard for authoring tool makers. Customers will have a hard time
    understanding that they need get an additional tool to meet atag. They will
    have a harder time accepting that they will likely have to pay for those
    tools. The bottom line in this case is that an ATAG compliant tool will
    likely never exist. 
    The latter case where these smaller companies are acquired or put out of
    business is the more drastic scenario. I see this as a possible outcome if
    customers continue to fail to understand the need to assemble collections of

[Messaggio troncato. Toccare Modifica->Segna per il download per recuperare la restante parte.]
Received on Friday, 25 February 2005 08:03:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:52 UTC