Problems with OTACS-2

Hi,
 
After thinking long and hard I have come up with the following list of
problems I see with OTACS-2.  If anyone can explain them away to my
satisfaction then I am happy to withdraw my objections.  Please let me
know if I have not been clear enough in the following explanations.
 
OTACS-2:

*  assumes the site will only be accessible using certain tools

   *  eg. site is accessible only once stylesheets have been rendered. 
      What happens if stylesheets are turned off?  Will there be a
      clause "...if tools are turned off the site must still be
      functional..."?
      

*  
   is difficult to elucidate / explain.  Its premise has moved away from
   users and their access due to disabilities.  Appears to be appeasing
   developers/ content authors, when I believe WCAG's primary aim to
   help user groups, and our secondary aim is to make it as easy as
   possible for the authors.

   *  
      eg. what is the theory behind this (as explained to a business
      manager)?  WCAG 1.0 at least had a the beginnings of "do this
      because otherwise group x will not be able to access a, b and c on
      your web site".  OTACS-2 is moving one step away from this, it is
      essentially saying "do this because otherwise the tool y group x
      is using will not render a, b and c correctly".  And what about
      "do this because otherwise if group x doesn't use tool y, a, b and
      c will be unavailable"
      

*  
   assumes that the defined *tools* render the content in an accessible
   format

   *  
      eg. that the tools work as intended in a variety of OS/browsers,
      in conjunction with ATs, other tools etc. Leads us down the garden
      path of leaving out or ignoring certain *unusual* or *difficult*
      technologies because they do not allow for these *tools*
      

*  
   assumes users will know how to manipulate / activate these *tools*. 
   Takes the onus off *the site* to be accessible, and onto *users* and
   *tools*

   *  
      eg. the browser specification to notify the user whenever a new
      browser window is opened is a great idea - but rarely used,
      because users don't know it is there.  Therefore sites that are
      accessible, but "only in conjunction with certain tools" will end
      up mostly not being accessible, because users won't know:

      1. 
         What tools to manipulate / activate
      2. 
         How to manipulate / activate certain tools to get desired
         results.

*  will be difficult to test

   *  
      WCAG 1.0 was hazy on how to test each checkpoint, but at least the
      theory behind it was obvious - users must be able to access the
      information.  Thus if all else failed, the developer could use
      common sense and test to ensure that, for example:

      1. 
         the site worked in conjunction with ATs
      2. 
         the site worked in text-only browsers
      3. 
         the site worked without plugins
      4. 
         etc etc

*  will be difficult to sell

   *  
      it is difficult to encapsulate. WCAG 1.0 had "access for all
      users", OTACS-2 seems to have "access through particular tools". I
      believe the secret to selling accessibility is convincing people
      of the need. By moving away from users with disabilities I think
      the guidelines begin to appear bureacratic in the least and biased
      in the extreme.

*  sets up a category of tools that are no longer just "W3C approved"
   but "W3C compulsory"

   *  
      eg. tools without which accessibility is not possible.  If people
      feel they have to use certain tools to get the required
      accessibility compliance they may decide not to bother at all. An
      example is Lotus Notes as a CMS for web sites and the coding of
      tables. It is quite difficult to provide a table summary for
      tables in Lotus Notes, however a content author authoring in this
      tool would know that and ensure that the table summary is provided
      somewhere and that the table occurs in context. However, under
      OTACS-2, for example, a Table summary would have to be coded
      compulsorily, this content author could then say, "well it can't
      be done in this tool and this is the tool I have to work with".
      OTACS-2 does not appear to allow for the content author to provide
      alternatives dependent on the tool they are using. 
      
   *  don't want to have to make people become *experts* in a variety of
      tools.

*  
   WCAG 1.0 required the site work without plugins / device requirements
   etc.  Is OTACS-2 essentially a set of device requirements?

   *  
      eg. PDFs can be rendered "accessible" (according to Adobe).
      However the W3C does not approve of PDFs as the only means of
      content transmission because it relies on a plugin. Under OTACS-2,
      it appears PDFs would be accessible. Under WCAG 1.0 they are not.

*  by being reliant on tools for accessibility, sets up WCAG 2.0 to very
   quickly become obsolete as new technologies become popular.

   *  
      I don't think it's really possible for WCAG 2.0 to be written with
      future technologies in mind. Who knew Netscape would reinvent the
      wheel with Netscape 6.0?   : )

I welcome your comments.
 
Cheers,
Gian
 
Gian Sampson-Wild
Consultant
 
Member: Web Content Accessibility Group Working Group
W3C Web Accessibility Initiative
 
Stanley & Milford
A Software Communication Group Company
Level 16
644 Chapel Street
South Yarra VIC 3141
Australia
Tel. 613 9826 5829
Fax. 613 9826 8336
Mob. 0404 498 030
Email gian@stanleymilford.com.au

********************************************
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message you must not disseminate, copy or
take any action in reliance on it. If you have received this message in
error, please notify Software Communication Group immediately. Any views
expressed in this message are those of the individual sender except
where the sender specifically states them to be the views of Software
Communication Group.
********************************************