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 toolmakers 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 01:05:11 UTC