Re: Call to embrace new technologies (Was: RE: issue with Guideline 4.2 )

The result of the transcoding option is that people can pioneer new
accessibility techniques and technologies without being stopped by backward
compatibility and adoption issues.

So asking in asking  adoption we are just asking for a serverside interim
solution.


Keep well
Lisa


  ----- Original Message ----- 
  From: Gregg Vanderheiden
  To: 'Lisa Seeman' ; 'Yvette P. Hoitink' ; w3c-wai-gl@w3.org
  Sent: Sunday, December 19, 2004 8:16 PM
  Subject: RE: Call to embrace new technologies (Was: RE: issue with
Guideline 4.2 )


  Thanks Lisa



      This is good to note.   If invokable by users - then these servers
become user agents and there would be user agents that support.



  If invoked by web sites themselves, they become part of what the website
is serving so their effect is included in the 'delivery unit'.



  So these server techniques can be used two ways to solve the problem.



  The problem then comes down to when there are no transcoding servers to
change the technology into accessible technology

  .




  Gregg

   -- ------------------------------ 
  Gregg C Vanderheiden Ph.D.
  Professor - Ind. Engr. & BioMed Engr.
  Director - Trace R & D Center
  University of Wisconsin-Madison


----------------------------------------------------------------------------
--

  From: Lisa Seeman [mailto:lisa@ubaccess.com]
  Sent: Sunday, December 19, 2004 7:01 AM
  To: Gregg Vanderheiden; 'Yvette P. Hoitink'; w3c-wai-gl@w3.org
  Subject: Re: Call to embrace new technologies (Was: RE: issue with
Guideline 4.2 )



  >   - do we really want to say that something is accessible if it cannot
be
  >used by people with disabilities -- but theoretically could if someday
  > someone made a tool that allowed it?

  My 2 cents...

  When I started using RDF  (resources description framework) techniques to
enhance accessibility we had the same problem. It was clear that this
technology we could do much much more for different disability related
scenarios that using standard HTML techniques. However, if we weighted for
user agent support it would never happen. They will only support that
authors are doing, and authors will only use the techniques that work with
Assistive Technologies (AT). Catch 22 as they say - the one can not hapen
without the other.



  We got over the "chicken and egg" senario by adding a serversisde
transcoding/ middlewear service at the same time. We chose a few user cases
or "prepackaged" scenarios (general accessibility, page map visual
rendering/ enhanced navigation etc..) we then  applied the RDF to make
transcoded versions of the same content accessible and optimized  to the
different scenarios or user cases -but using HTML so it workes with current
Assistive Technologies.



  We hope more assistive technologies will support RDF directly. However, in
the mean time, if anyone wanted to use RDF to enhance accessibility, they
can use the serverside (free) service, and get it working today.



  The same technique can be other platforms -if they want to they can
provide sever side accessibility services until "AT" catches up and directly
supports their accessibility features.



  What does need to be tolerated is to allow different versions, based on
the same source document so long as you can easily reach the one version
from the other.



  Keep well

  L





  Yvette wrote:


  <snip>
  I would like to go even further and propose to delete the entire success
  criteria that there must be at least one  UAAG-compliant user agent for
the
  chosen technology.

  I strongly think WCAG 2 should embrace new technologies. Technology and
  accessible user agents are a chicken-and-egg thing. If we require to use
  only technologies for which UAAG *-compliant user agents exist, you can't
  use a new technology that doesn't already have accessible UA's. That means
  that only people who do not care about accessibility use that new
technology
  and the accessibility features are never used, to the manufacturers don't
  see the need to support those features. This leaves a lot of people in the
  cold.

  If, on the other hand, we say you can write your content on the (initially
  false) assumption that there is a user agent that is UAAG *-compliant,
  people will use the accessibility features of the technology and
  manufacturers will see the need to support the accessibility features.

  We have seen with WCAG 1 and Flash what can happen if we set a high bar on
  new technologies. Some of my own clients decided not to make parts of
their
  website accessible because they really wanted to use the capabilities of
  Flash and did not have the resources to make an equivalent accessible
  alternative as well. They didn't use the accessibility features of Flash
  because that would cost extra work and they thought that wouldn't help
  accessibility because they still would not conform to the minimum level of
  WCAG 1. This means that even now that Flash plug-ins support accessibility
  features, their Flash content is still inaccessible. I really want to
avoid
  this situation in WCAG 2.

  A simple fact of life is that organizations WILL use new technologies
  (unless forced by legislation). Instead of forbidding that, let's tell
them
  how to use the technologies in an accessible manner so more people will
have
  access to that content in the long run!

  Yvette Hoitink
  Heritas, Enschede, the Netherlands
  E-mail: y.p.hoitink@heritas.nl
  WWW: http://www.heritas.nl