Re: Issue #10, disability specific information and server side stuff

I regard Paul's latest changes as a step in a positive direction.

In the IMS scenario, where there will be large collections of course
fragments,
it is important in building adaptive equivalents for a textbook or a lab
course
or whatever that the specific limitations of individual, composable object be
known so that they can be used in selecting materials to cover a syllabus. 
The
people creating the resource components don't know the syllabus, so they never
know if they have covered the subject, and they may or may not provide
equivalent alternatives that cover all the disability and device and so on
specific cases with respect to delivery context.  But there is clearly a case
for "this object is suitable for this use" kind of information which is not
bowdlerized to the extent as to be completely disability-independent.  We mark
wheelchair-accessible nature trails in the parks.  We don't fail to mark them
just because not all the trails are that accessible, or because the difference
in the trains matters not to a Deaf or semantic pragmatic visitor.

Partly this gets at the status of 'hints.'   There should be enough
discriminating information to support optimization as well as we know how; and
optimization takes place by the user with all the user's peculiarities in full
view.  But there should be enough access, independent of optimization, such
that any profile or mode of use applied to the resource base that has a prayer
of working, of being functional, is available under user selection control.

The absolutely first thing users should try is the optimization that the
author
has thought through.  But the author should be extremely cautious in asserting
constraints that prevent creative use of the resource components.

A possible formulation of the rules of the game -- and these are at a rather
high level -- is as follows.  This in particular tries to put server-side and
client-side adaptation under one set of basic rules.  The protocols for
coordinating client side and server side actions are developed under the
constraint of accomplishing these end-to-end conditions.

Principle 1:  The adaptation logic controlling how the actual transactions or
presentation is customized is determined by the application and the delivery
context, independent of where the adaptations are applied.

Theory:  The adaptation logic is held to be in the form of what mathematical
programming would know as a constrained optimization.  

WAI Position:  Constraints are constraints, without distinction as to where
they came from; one just doesn't violate them.  Preferences get to be traded
off.  Preferences are to be mediated by the protocol that the application has
the first word but the user has the last word.

giving the user the last word
 
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0099.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0099.html

Principle 2:  The expression of constraints and preferences by the
application,
and by the user, shall be such as to support the optimum outcome under all
conditions.  

Corollary 2a: This equates to independent requirements on each of "constraints
and preferences of the application" and "constraints and preferences from the
delivery context" which says that "constraints shall be minimally
constraining,
and preferences shall be maximally discriminating."  

Maximally discriminating means things like anything that can matter shall be
ranked, and any two things that may vary independently or wind up fungible
shall be covered by exchange prices to the greatest extent possible.

Market model:  The adaptation framework we come up with should be capable of
serving in all the cases outlined in

NCITS V2 Description adopted at Plenary #4
<http://www.ncits.org/tc_home/v2htm/V2docs/v201011.htm>http://www.ncits.org
/tc_home/v2htm/V2docs/v201011.htm

In particular, it shall apply when the user premises equipment is a more
capable device than device hosting the target service as well as the reverse. 
And when they are communicating via an ad-hoc two node network just as well as
when services are being passed via the WWW over the Internet.  The reason this
is highly desirable, at least from a PWD access perspective, is that a) the
interface and dialog technologies are the same, and b) the person with
multiple
or severe disabilities will have a unique custom device that they wish to
employ to access all target services, and the web services should be prepared
to play ball with this delivery context.  So a quad-G4 SMP Mac is not more
computer than the end-user device may be.

As a consequence of this market model hypothesis and Principle 1, it follows
that

Corollary 1b:  A framework for adaptation shall support without prejudice both
adaptation by customer premises equipment and by network-hosted services.

Part of the reason for this is the application to accessing home and office
equipment that is not on the Web.  The point is that the dialog technology,
both for expressing dialogs, and implementing physical interaction
environments, are the same both for the World Wide Web and for a paraplegic
controlling the toaster by sip an puff into their wheelchair-borne personal
digital infrastructure.

Principle 3:  The user may express application-specific preferences; the
application may not express user-specific preferences.

Al

At 02:17 PM 2001-08-22 , Paul Bohman wrote:
>Thanks, Wendy, for putting together the list of open issues. It is very
>helpful.
>
>I'm going to send a few emails today to address the open issues to which my
>name is attached, mailing each one separately, for better archiving
>purposes.
>
>Issue #10, part 1:
>
><quote>
>23 April 2001 - Paul Bohman proposed disability conformance ratings and in a
>draft of the intro he published on 10 May 2001...
></quote>
>
>My original idea can be found at
<http://www.webaim.org/>http://www.webaim.org/wcag/logo. I would
>recommend that those that are interested in the idea of modularization of
>the guidelines take a quick look at the graphic that I created. I no longer
>think that it is the best idea to break down conformance by disability type,
>but I still think that a modularized conformance model is the best overall.
>** So I would like to DROP the open issue as it was before and PROPOSE a
>modification of my original intent: Develop a conformance scheme that is NOT
>gauged along a single continuum (e.g. I don't want the page to either be
>"pass" or "fail", nor do I want single-A, double-A or triple-A along a
>single continuum). Instead, I propose that we continue with the discussion
>about modularization, and once we have decided how many modules to include
>(current discussions suggest either 3 or 4), then create a conformance
>scheme that mirrors this modularization. This means that we could have a
>page that passes one of the modularized criteria perfectly, but not the
>others, and the page's author would be able to declare it as such.
>
>
>Issue #10, part 2:
>
><quote>
>he includes Technology specificity and Disability type specificity axes of
>conformance.
></quote>
>
>Although I originally included these ideas in the introduction, I am not of
>the opinion that they should be included there anymore. The idea of
>"technology type specificity" will be addressed in the techniques documents.
>The idea of "disability type specificity" can be included in the server-side
>techniques document, or referenced from it. My original idea was to have an
>in-depth techniques document that outlined the needs of as many disability
>types as possible, so that developers who wanted to create multiple output
>formats (optimized for certain populations) could do so with the expert
>advice of W3C members. I still like the idea, but, like I said, it should be
>separate from the introduction. ** So I'd like to DROP the original ideas
>that I proposed, and I PROPOSE that we include discussion of disability-type
>specificity in the server side techniques document. The discussion within
>the server-side techniques document should be of a general nature, and I
>PROPOSE that we create a separate, more detailed Disability-Type Specificity
>techniques document with more detailed information.
>
>
>Paul Bohman
>Technology Coordinator
>WebAIM (Web Accessibility in Mind)
><http://www.webaim.org/>www.webaim.org
>Utah State University
><http://www.usu.edu/>www.usu.edu
>

Received on Wednesday, 22 August 2001 15:52:46 UTC