RE: Requirements on repair

Unfortunately I can't join the conference call tomorrow. I have a long
standing conflict. 

I believe the notion of 'bundling' applications for compliance potentially
does more harm than good. 

First, as I said earlier, I do not believe that authors will understand this
concept. I know those of us in industry will commonly hear 'Dreamweaver is
not ATAG compliant' or 'GoLive is not ATAG compliant'. 

Second, if we assume that a customer does overcome this challenge, it still
places a significant dependency on this smaller company. Given the
challenges associated keeping versions of AT in sync with commercial
products, we should be prepared to address how scenarios in which a delay on
the part of a small vendor should impact sales of the other tools. The
opportunity for abuse is significant. 

Thus, we get back to my initial assertion. In effect, the W3C would be
requiring the larger software manufacturers to buy the smaller ER vendors,
or simply just put them out of business. If that is the requirement, I want
to make sure we get that out in the open as we address this issue in debates
over whether ATAG should be adopted at a national level. 

My suggestion is that all of these requirements be dropped altogether. There
is an ER working group. I would place the requirements on the makers of
these tools. At that stage, the W3C would be free to introduce ATAG and ER
requirements as the basis of standards at the same time. This would allow
each country to make decisions about the impact on their markets. 


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 Jan Richards
Sent: Saturday, February 26, 2005 5:05 PM
To: w3c-wai-au@w3.org
Cc: Bob Regan
Subject: RE: Requirements on repair


Leaving aside 3.5 for now (since it is a priority 3 checkpoint), I would 
contend that the checking and repair requirements should remain in ATAG 
because without checking and repair for accessibility problems, there will
be 
no way to remove accessibility problems that are almost inevitably
introduced 
without extremely tight restrictions on author actions (e.g. by typing in a 
code view, opening pre-existing content, etc.. 

Of course, not all authoring tools will have to meet these requirements.
ATAG 
takes a full view of the process by which Web content is produced, allowing 
multiple tools to be bundled for a conformance claim, rather than making 
requirements of specific classes of tools. 

I think that this approach is a good one because it acknowledges that 
different tolmakers divide up the content production process in different 
ways, defying classification schemes, and resulting in a variety of threats
to 
and opportunities for accessibility. Some tools specialize on one or more 
specific tasks in a production process (e.g. creating style sheets, editing 
images, checking and repairing accessibility problems, etc.), while other
"end-
to-end" tools such as FrontPage and DreamWeaver automate most or all of
them, 
and still others innovate completely new tasks to automate.

For tools that market themselves as "end-to-end", I understand that there
are 
tough choices as things stand. The bundling option is problematic because it

endangers the meaning of "end-to-end", in-house development of an 
elementary "manual" system may be a waste of time if users used to
automation 
in the rest of the won't accept it, and development of an automated system
or 
acquisition of a third party checking and repair tool is expensive.

How then to get credit for developers who have already put in a great deal
of 
effort and also encourage developers to continue to make substantial 
incremental efforts towards tools that increase accessibility without 
negatively impacting author experience or market share?

Perhaps one way forward would be to reopen a debate on the structure of the 
conformance mechanism of ATAG to reduce somewhat the requirements that a
tool 
(or group of bundled tools) needs to meet before achieving even the entry 
level of ATAG conformance.

Cheers,
Jan

-- 
Jan Richards, User Interface Design Specialist 
Adaptive Technology Resource Centre (ATRC), University of Toronto 

  Email: jan.richards@utoronto.ca 
  Web:   http://jan.atrc.utoronto.ca
  Phone: 416-946-7060 
  Fax:   416-971-2896


Quoting Bob Regan <bregan@macromedia.com>:

> 
> 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 Sunday, 27 February 2005 19:17:56 UTC