W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2002

source + try harder as an option

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 01 Mar 2002 12:09:41 -0500
Message-Id: <Version.32.20020222151012.00c0fd80@pop.iamdigex.net>
To: <w3c-wai-gl@w3.org>
** 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>



At 01:32 PM 2002-02-15 , Gregg Vanderheiden wrote:
>
>NEW CHECKPOINT PROPOSAL 
>Based upon our discussions at the meeting yesterday
>
>Checkpoint 4.S.1
> If you are serving content in different forms to different users to
>comply with the guidelines, then at least one version must meet all the
>guidelines (with which compliance is asserted) and that form must be
>complete and up to date:
Received on Friday, 1 March 2002 12:09:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:18 GMT