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
products to meet national or local government requirements. I see this as a
uniquely negative outcome. First, the cost of developing this repair tool or
acquiring a company that makes one would easily exceed the budget and
resources we allocate to accessibility on an annual basis - for all products
- by at least an order of magnitude. This means I would not be able to do
any AT interoperability work, no authoring support for new technologies, and
no support for new OS level APIs (there are at least three major new APIs
due out soon). Rather than leveraging the existing market, we will force
companies like mine to stop moving forward while we absorb this cost.

 

If we assume that we were indeed to build these features ourselves or
acquire them, that does not mean we will have the resources to devote to
maintaining these features over time. Unlike the companies in the ER market
today, we do not have the resources to assign five to ten people to stay
abreast of repair tools AND with at least one less company making such
tools, we actually find ourselves squandering the expertise that exists
today. 

 

I see the repair requirements as an over-extension of the guidelines
themselves. At best, ATAG would have a drastic and negative impact on the
marketplace. At worst, ATAG would be ignored and thus be irrelevant. I
strongly believe that ATAG should push industry and move us all in a
direction toward creating accessible content. However, I also believe there
are limits that have been crossed here. 

 

Cheers,
Bob


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




 

Received on Friday, 25 February 2005 03:05:50 UTC