server-side diversity is OK, <big IF/>

At 04:45 AM 2002-03-03 , goliver@accease.com wrote:
>
>I don't like the idea of different versions for
>different groups for the following reasons
>

Graham, all the evidence, that you bring out is sound.  These are important factors that have to be considered.  But it's half the story.

The fact that alternate forms of web content -- pre-cooked and offered that way on the server -- can be successful is demonstrated by the Tesco site

 http://www.tesco.com/access/default.asp

Not that we will ever reach 100% of the people, but we will reach _some_ people with polymorphism that _would be left out_ by our best attempts at a universal form.  

The conspicuous examples have to do with various learning and cognitive disabilities, and language communities based on sign language.  In the case of sign language we can't wave off natural language differences as not our problem because there is such a strong link between an absence of hearing function and an orientation to sign language as a primary means of communication.

So we should not disallow server side diversity.  We do need to continue to work on a clearer statement of the functional requirements and tactical approaches that let this diversity add more than it subtracts.

>1. Resource Discovery
>How do we ensure that the 'right group' gets to the
>'right version'?

We don't.  All we can ensure is that they can recover from a wrong choice and know about and potentially try all others.

>If there are links from the default rendering what are
>they going to say?
>
>'Link to Text Only Version?'
>Well, how do I know if I am 'supposed' to use the text
>only version?
>
>'Link for Blind and Visually Impaired People?'
>This doesn't do it for me, it sounds discriminatory.
>Also see 5.

We are not going to dictate what they will say.  This is like link text in general.  We will tell the authors that the links to alternate forms should evoke the difference(s) between the forms.   In language the content provider thinks people will understand.

The success criterion is that the user always has a feasible path to get to any of the alternatives, and that the labeling is not the major source of false starts or failure to change between streams.  There is a certain amount of trial and error that is unavoidable because people themselves cannot describe what works best for them.

 some WAI comments on Device Independence
 http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html

See also

 HCI Fundamentals and PWD Failure Modes
 http://trace.wisc.edu/docs/ud4grid/#_Toc495220368

on why the browser back button as an 'undo' for link traversal is a critical feature of the web.

>
>What's to stop people landing (on a search from Google
>for example) on the 'wrong' version. What do they do
>then? How do they know they are on the 'wrong' version?

>

They know that they are on _a_ wrong version if they find rough sledding.  It is up to the content provider to let them know that at that point that they have a choice.  _Under these conditions of duress!!!_  It has to be <expletive/> clear.  How widespread this message has to be on the site is a matter for exploration.  At least according to Nielsen Norman Group, the best plan is to plan on deep linking and provide basic orientation to the site on every page.


http://www.useit.com/alertbox/20020303.html

Just as Exit signs will in some cases only point to the next Exit sign, this can be accomplished by putting a disability assistance rider (additional annotation) on the link to the home page if that is the path you have to follow to exploit server side diversity with full information about what is available.

Let me do my little war dance again (this is a Rap thing):

 Listen, listen, listen; to Tim Berners-Lee
 He _The Man_ who made the Web; "It's a _Web_ not a tree."

The point is not that there have to be full parallel copies of a site, but that you never leave the _web_ in which each page is a workable start page; and the paths from everywhere to everywhere are discoverable, comprehensible, and followable.  The "where's" in this requirement have to expand to include the divergently-presented alternatives.  That's a tall order, but when done well, it's better.

>2. The skills aren't there
>In my experience so far, there simply is not the
>awareness of what the needs are of different 'groups of
>disabled people', to create an accessible site for a

>specific group.

Sites will create generated-content view diversity for different devices.

Portals -- the demise of HalfThePlanet notwithstanding -- will know the needs of groups with special needs.

The portals will have the transforming capability and the sites that are multimode already will have enough control of the content to feed it to the portals in a comprehensible and re-purposable way.

That is the primary mode in which disability-adaptive views will first reach the public in volume -- through site partnerships between a look and feel site dedicated to a group that strongly benefits from a particular and atypical look and feel; and content services that deliver content to multiple sites each with its own version of look and feel.  This tier system is emerging in the mainstream web independent of disability issues.  We need to understand its upside and channel it in that direction or we will realize too late that it has happened and we are left with only the downside.

Sites with look and feel diversity capability may provide a certain amount of adjustment under their own brand, but it works against the guideline to use a consistent look and feel, and there is a lot of marketing pressure to shore up your branding with your externally distinctive and internally consistent look and feel.  So major sites may well wish to outsource their adaptation to affinity group portals.

>The process of producing two or more version will be
>expensive enough without all the potential rework to
>fix up stuff.
>

The base cost to support polymorphism won't come from disability accommodation, it will come from channel diversity that the service offeror can't avoid because their competitors are reaching their customers with multichannel strategies.  And the service offerors need to tell the same story regardless of the channel that the user selects to access the service.

>3. More than one verion means less testing and lower
>quality.

This is not true.   There is more testing of the view-extraction transforms and more quality control over the data in an enterprise solution.  Maintaining at the HTML level is error prone and harder to test.

>This has been my experience so far. Site quality is
>lower, resouces get stretched, stuff gets missed.

You must have been producing the parallels with inadequate tools and methods.

>4. No site will ever be fully accessible.
>There seems to be inherent in this argument somewhere
>that we can make a site 100% accessible.

Don't know where you get the idea that people think polymorphism will bring 100% coverage.  But there are some people you can bring in under the 'big tent' this way that would be left out by any single version.  So it is more inclusive to allow multimode serving than to insist on one 'universal' form.  So long as the diversity is not taken as an excuse to make all the forms narrow and inflexible.

>I think that it is helpful to look at the bricks and
>mortar world in this regard. In NZ anyway an accessible
>door (in the regulations) has a handle on it which can
>be opened by 'most' disabled people.

>A 100% accessible door would be one of these Star Trek
>things that simply opened automatically (optional swish
>swish sound) but they are not specified in the
>regulations (they are too expensive).
>These regulation were pioneered by disabled people. A
>pragmatic ('non 100%') response to a real world problem.

And in the bricks and mortar world there is a mix of bus modifications and wheelchair van alternatives to busses applied to get the job done.  Some adaptation of the omnibus services, and some targeted assistive services to cover where that doesn't go.  The van only serves qualifying individuals.  Should we drop the van service?

Just because websites should be accessible in their default form doesn't mean that the web should not contain WebBraille service.

The bible verse on this one is:

"Is thine eye evil, because I am good?" -- Matthew:20:15

>5. Disabled People want the same solution as everyone
>else.
>OK, so I only have a small sample size, but that's the
>message I get.

Oh they do!  This is true.  They think they want just what everybody else gets.  This is because they don't know what the alternative is.  Those who have experienced the options appreciate the value of having options.  There is just no comparison between how easy it is to learn to use a voice portal as compared to how easy it is to browse the web with a screen reader.  If the websites will just put up their voice portal version in a way so the screen reader user can opt into that mode, and know what they are getting, a lot of confusion and wasted time groping through visually composed web pages will be avoided.

>In short I believe that accessible design is universal
>design.

It's perfectly fine for you to take this approach.  But the enhanced usability of divergent representations of a service is not something that you should be allowed to deny to our clients.  Imposing this on everyone is just forcing disability access into a technological backwater, just like Baudot in TTY and plain text for screen reader compatibility.


The key to effective client-side restyling is semantic analysis and marking of the content.  Most of the sites that we can do that level of analysis and documentation of what they are processing are those that embrace a single-source multi-channel strategy.  If we don't work with this trend, it will only work against us.

Tomorrow the W3C Workshop on Delivery Contexts commences in Nice.  Wish them well.

Al

-- more

The offering of parallel versions is going to be driven more by trying to reach diverse devices than diverse people.  But it's going to happen.  W3C specifications are served in interactive paged form, in printer ready form, and in encapsulated bundles for download and offline reading.

See also

 Middleware and the eSCaped Web
 http://trace.wisc.edu/handouts/sc2000/middleware_and_eSCaped_web/

.. for more on this.

Banks want to let you check your balance (and do other things that generate fees) by your choice of a web browser a telephone or an ATM.  There it is quite important that the balance you get told is the same regardless of your mode of access.

Roger Gimson, the editor of the Device Independence Principles document, made the interesting observation that "While designers may not warm up to single-source, multiple-rendition authoring, those with an Enterprise perspective will naturally assume this is best."  [That is a paraphrase, even 'though I used quotes.]

>Regards
>Graham
>
>
>
>
>
>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:Success Criteria
>    1) that version provides accessible forms of all
>the content that is
>provided in the default presentation 
>    2) that version can be obtained from visiting the
>same URI 
>    3) that version is always up to date (same content)
>as default
>    4) that version can be easily selected by users
>using technologies
>that area accessible under these guidelines  (e.g. you
>don't have to
>operate an inaccessible technology in order to request
>the accessible
>form of the content)
>NOTE: The reason that one version must be used to meet
>all the
>guidelines instead of using different versions to meet
>different
>guidelines is to allow access by people having multiple
>disabilities --
>and because authors may not understand which

>combinations of guidelines
>must be used together to provide access. Gregg
>
>AccEase Ltd : Making on-line information accessible
>Phone : +64 9 846 6995
>Email : goliver@accease.com
>

Received on Sunday, 3 March 2002 11:18:55 UTC