Re: source + try harder as an option

Hi,

I agree with Al that accessibility of a web site should not be measured only by
the accessibility of its broadest form.  This is why I've been thinking
of web page accessibility more like:

    "A set of versions of a web page can be considered accessible to
    a person with a disability if both of these conditions are true:
    
      a.  each version in the set has the exact same information and
          equivalent interaction with the information as that of any
	  other version in the set
	  
      b.  the set contains a version of the web page such that the person
          can understand the content on the page and be able to interact with
	  that information with the goal of being as effective and efficient
	  as a person without a disability when using the web page."


Client-side transformation can have draw-backs.  For example, how does the
web page  developer trust that the results of the transformation
is what the web page developer is actually trying to convey?  How does
the disabled person know that the transformation was accurately specified
and appropriate for the information the web page designer is trying
to convey?  Another concern is how many users have noth the technological
drive and ability to specify and test transformations.  My concern is that
many would just bail out.

I don't believe that a vanilla form is the universal answer, but is a very
important tool in attacking accessibility issues.  One draw-back to the
vanilla form is that its use of text could cause problems for
people with dyslexia.  This goes back to the issue of handling
the needs of some people which will conflict with the needs of other
people.

Scott

PS  It's interesting that Al has suggested a need for the ability to
examine transformations.  I'm just finishing up a configuring/transformation
system and have a feature where a long of the configuring/transformation
can optionally be included at the end of a generated web page.

> 
> ** Summary:
> 
> This is in the context of server-side polymorphism and the attempts to come up with a checkpoint for it.  It's not a single checkpoint, it's a rollup issue.  But I don't think that measuring a site's accessibility _only_ by the accessibility of its broadest form is the highest and best rating practice that we can recommend.
> 
> Some people with severe disabilities will not be able to use a vanilla form, just as some people with multiple disabilities may not be able to use any of a range of targeted forms.
> 
> Now, source form is not usable without above-usual effort in the client.  However, on application of above-usual effort in the client (to comprehend the semantic backups for a source form and present it in an optimized presentation), the result will be more usable for the targeted person with a disability, and this level of adaptive intervention will likely be _necessary_ for _some_ people with severe disabilities.
> 
> A polymorphic service should incorporate access to source form as well as vanilla form.  However, we should also be looking for ways to get content providers credit for the less-than-universal access benefits of pre-tailored forms as well.  Because for every tailored form there is a person with a disability who will find that form more usable than the vanilla form, and a friend of theirs with a severe functional impairment who will find they can't use the site with out that adaptation.
> 
> ** more
> 
> All people with multiple and severe disabilities are at serious risk of being left out, and our approach to serving them has to take into account "try harder" approaches, as I see it.  This is why a "source option" seems attractive.
> 
> In the XSL review we [PF, on behalf of the WAI] got language put in the specification requiring source option for any service which serves final form.  For people with severe disabilities, personally adapted forms would seem to be sometimes necessary.  The shortest path to a personally optimized presentation passes through the most semantic, most 'early' source form of the service or information that the service offeror can readily or reasonably afford access to.
> 
> I think of this as the "may I speak with your supervisor" customer right from retailing.
> 
> 
> It's just like the review of the invoice in your bill.  You have a right to ask "please explain how you figured that out?"  This is what my Computational Science colleaques who are doing physics by computer want.  They want someone else's conclusions, but they always want to be able to adjust their view to trace back through the data reduction to the origial sources and reconstruct new conclusions after joining new data to the basis for drawing conclusions.  This is the basic query that I am trying to get infiltrated into the way everyone does Web business through the pressure from science applications on Web Services offered in the Grid computing community and from there the Web.  If the backoffice interface is all in Web Services and the WSDL provides access to a sufficiently semantic model, then at the client option the derivation of final form can be re-constructed in the client from as much depth into the process as is required to derive a satisfactory result.
> 
> The above is as I see it the master plan.  Behind any canned form there should be an explanatory schema which explains the world that is being viewed through the document form, and a recipe or view-definition script (e.g. XSLT) that extracts the presentation in the existing documentary form from the information graph on which it is based.  This is the dream.  There's many a slip 'twixt the cup and the lip, of course.  One of the key gotchas is that schemas, like CSS styling practices, can contain garbage just as easily as they can contain the semantic model needed to synthesize an optimized adapted presentation of a service.  Here delivery of information content is included in "a service."
> 
> Most server side options are targeted to a range of thin clients.  We of the accessibility camp have to stand up for the thick client option, where the User Agent is prepared to try harder, as for example emacSpeak and Home Page Reader.  Any computer running assistive technology is in effect a de_facto thick client, a local cluster of services that are composed to deliver the goods.
> 
> Al
> 
> <quote cite="http://www.w3.org/TR/xsl/slice1.html"> 
>                                                                 . To
>    preserve accessibility, designers of Web systems should not develop
>    architectures that require (or use) the transmission of documents
>    containing formatting objects and properties unless either the
>    transmitter knows that the client can accept formatting objects and
>    properties or the transmitted document contains a reference to the
>    source document(s) used in the construction of the document with the
>    formatting objects and properties.
> 
> </quote>

Received on Sunday, 3 March 2002 12:39:46 UTC