RE: Requirements on repair

Hi Roberto, 

I agree that there needs to be a balance. These guidelines not only need to
set the bar for today's tools but drive development in specific directions
going forward. 

That said, how far in the future are we willing to defer? In the case of
Dreamweaver, I do not see ATAG's repair requirements being adopted in any of
the next three releases. Assuming we stick to an 18 month development
schedule, that would be at least mid 2009 before I could start on this.

>From a development perspective, I am very concerned about the looming
changes in this market. Longhorn, Tiger and Linux all represent new API sets
to be release in the coming months. Along with those API sets will come AT
build upon those APIs. I know that any one of these projects could absorb
all of our resources for an entire release. I am also closely watching
changes in the content standards such as WCAG, JIS and 508. All are working
on next generations of their standards. Finally, from the authoring
standpoint, we are spending a lot of time improving the usability of our
standards based authoring workflow to ensure that work on accessibility
becomes more transparent and tightly integrated into the tool. 

Given the complexity and magnitude of these challenges, I simply can see a
requirement to build tools that already exist and are maintained in the
market as a disruption to these projects. Not to mention the damage it does
to the companies that build these tools. 

Cheers,
Bob


-------------------------------------------------------------------------
bob regan | macromedia | 415.832.5305






-----Original Message-----
From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf
Of Roberto Scano (IWA/HWG)
Sent: Friday, February 25, 2005 12:04 AM
To: bregan@macromedia.com; w3c-wai-au@w3.org
Subject: RE: Requirements on repair


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
    equivalents.
    
     
    
    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
    accessibility. 
    
     
    
    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
    technologies. 
    
     
    
    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 15:31:37 UTC