CC/PP, Usability for PWDs, the Edapta model, and You

At 02:45 AM 11/8/2001 , Jim Ley wrote:
>If the system is used by servers, then you have to provide information
>otherwise you won't get accessible content - if you do get accessible
>content despite not sending any CC/PP information - then the CC/PP
>information is almost useless to everyone concerned, other than people
>who like getting stats to justify only supporting a minority - as is the
>current situation where lots of people justify creating IE only sites due
>to its overwhelming dominance.

I'm a bit lost here as to what your main point is, mainly because
you're stringing together a number of sentences.

The general idea is this:  If the server knows what to give you,
then it can tailor that for you.  If the server doesn't know what
to give you, then it offers up a "best guess/most accessible"
version that generally follows the model of WCAG documents.

I don't see how that's "useless" at all nor does it justify creating
IE-only sites.  If anything, it has the opposite approach -- making
it clearer that the interface needs to be not tied to just one
type of access method.

>Content negotiation based on browsers or platforms or systems have shown
>not to work, people already attempt it based on UA strings - there's
>numerous examples of this technique failing - nowhere in the CC/PP drafts
>that I can see have anything to address this problem.

On the contrary, content negotiation works fine all the time;
I have no idea why you would make the claim that it does not.
For example, I believe the W3C's CSS server does browser
detection.

However, CC/PP specifically _does_ address this problem, because
it is not based on user agent strings, which are known to have
certain weaknesses -- chief of which is the necessity to maintain
a table of capabilities.  The CC/PP approach, instead, is to make
browsers self-identifying as to _what they can do_, instead of
_what they are_.

Which means that if someone uses straight IE, that program will
say, "hi, i am a graphically oriented mouse driven color blah blah
blah", and not say "hi, I am IE 5.0.0.1.3".  This is useful for
when a completely new browser is created, say, KynnBrowser 1.0,
which nobody has ever heard of -- except it expresses its abilities
in CC/PP which means it says, "hi, i am a linear non-graphical
keyboard access non-color blah blah blah."

>We also need a
>huge amount of user input into the system to actually specify what they
>want  - users aren't used to this, and I can't see them getting motivated
>to it, most aren't even motivated/informed enough to configure their
>current browsers to their liking - I always get I wish I could ... - and
>the answer is in their current browser.

No, that's not required at all.  In an appropriate CC/PP system,
it would be no harder than using the "accessibility options" in
Internet Explorer, and likely even easier.  JAWS or other AT 
programs (or drivers for AT hardware) could simply write into a
CC/PP profile directory or file upon installation.  Configuration
options could be grouped together, for example, to provide a
basic set of options for users with specific disabilities, and
then allow configuration beyond that, _if the user desired_.

At no time should the user have to enter their own CC/PP 
profiles for their hardware or software, and user preferences/
choices should be made simple as described above.

> > Such information should be covered by a P3P privacy policy,
>Which is meaningless really - I can put whatever I want in a P3P privacy
>policy doesn't mean I am reputable - and what about all the
>caches/systems in between.

Is there some sort of paranoia bug going around that I'm not
aware of?  It seems to be catching.

If you're that frightened of CC/PP profiles that you don't trust
P3P policies, well, most people give out user agent information
(containing screen dimensions, color depth, operating system
name and version, etc.) rather freely anyway without knowing
it.  In the system I'm describing, you'd have a choice -- send
a CC/PP profile, or don't send it, it's simply a case of
configuring your browser correctly.  If you don't want to send
a profile -- you don't.  You'll just get back the "un-optimized
page".

Which will probably be accessible, but may not be usable (see
Jakob Nielsen's latest study).

> > Nothing in this makes you any more or less likely to have your
> > system broken into,
>Certainly not, but equally little of it is particularly relevant to a web
>designer.

Wait, device characteristics and user preferences are of no
relevance to a web designer?  In which universe do you live,
and how are you transmitting your email messages to the real
world, my friend?

> > especially not compared with the CURRENT system
> > which is that for the most part, your browser already transmits
> > a great deal of information about your system.
>No it doesn't - it only lets out what I let it, those who have control
>over such things can easily modify all of the information that is sent -
>none of it should be essential to them getting accessible content - of
>course the fact that many people do use the UA string means that many
>browsers actually choose to send fake information aswell as letting their
>users choose it.

And CC/PP likewise will only send what someone chooses to send.

> > Let's not allow unfounded paranoid fears of computers getting cracked
> > to dismiss what could be a very useful advance in the usability and
> > accessibility of the web.
>Please justify how that works, we have systems in place that let the
>content work on any device - device independance getting silly settings
>that encourage developers to concentrate their efforts on the limited
>range of platforms/UA combinations that apear in their CC/PP settings
>will do nothing for those users outside this - and we'll very quickly,
>just as we have with UA strings get to the stage where lying is the only
>way to some content.

I'd gladly justify how it works if I thought you were listening.
You're not, though, because you're too stuck in your single
source model of web accessibility that tries to cram all
info into the HTML and hope the browser and AT can sort it out,
which basically means you create a visual interface and tell the
non-visual users, "here, suck on this a little and maybe you
can use it, haw haw."

Now, for the rest of you out there who actually _do_ want to
hear ideas which aren't your own, I'll explain a little bit
more about why I think this is important enough to have spent
the last few years trying to make this a reality.

Several bullet points:

* HTML is an exceedingly poor choice as a generic, device
   independent, transformable data and UI language.  There are
   huge limitations in HTML (or XHTML) that prevent it from
   being useful in this manner.

* Very few devices support the arbitrary transformation and
   extraction of content from HTML to produce a user interface
   the user can use effectively.  (C.f. usability studies.)

* However, HTML is what is currently deployed on a huge number
   of machines and there is every indication that this will
   continue to be the case.

* If you do it right, HTML actually makes a rather decent
   language for implementing _specific_ user interfaces for
   users with _specific_ needs.  Such as providing screenreader
   specific UIs, designed only for use in a screenreader --
   meaning that you can then _optimize_ that user experience.
   (For example:  Creating menus for navigation in the page,
   restructuring the order of content, etc.)

* You're also able to deal with usability problems that
   result from poor browser support or conflicting accessibility
   requirements -- such as [D] links.  In a UI designed only
   for visual users, [D] links are mostly unnecessary.  In a UI
   designed only for screenreaders, they can be labeled more
   descriptively as "Image Description" without impacting general
   usability or design aesthetics.  (In a general "default" UI,
   of course, you may have to rely on [D] links, especially as
   @longdesc is not widely supported.)

* Furthermore, you're also able to create UIs for specific
   audiences without worrying about the impact on other users
   with different needs.  For example, Edapta developed a prototype
   Javascript-based framed UI meant for people who have limited or
   restricted use of a mouse.  In no way would it make a good
   general UI, and it would be awful for, say, blind users --
   but by eliminating the inherent _conflict_ of "if we solve
   Joe's problem, then Mary may lose access" we open up a whole
   new set of accessibility solutions.

* CC/PP is important for this as one way for the browser to
   automatically communicate the preferences to the server; but
   the model isn't necessarily only based on automatically
   gathered information, nor does it need to be dependent on CC/PP.
   All that's required is simply for the server to use whatever
   information it has to best meet the needs of the user, instead
   of simply being a "dumb server" which spews content and doesn't
   care what's done with it.

In the objections I see plenty of handwaving of the sort "this
will never work because people will abuse it and won't use it."
I prefer to look at the problems and figure out ways to solve
them -- and I've been doing that now for two years -- rather than
just deciding it will never work because, well...because some
people say it won't work?  Because there's fears it might be
"abused" in some manner?  (Like that isn't already the case now
with existing web standards?  This reduces the potential for
abuse, doesn't increase it.)

So, while I welcome reasoned discussion on this, I also realize
that these ideas will be controversial and even threatening.  It
is a consistency of web developers that what we don't understand,
we feel threatened by.  I can't tell you how many web designers
find WCAG to be dreadfully frightening and resist it with all
their might -- or the concept of valid HTML, or the use of CSS.
They resist it, that is, until they're forced to confront what
it's really about, and then, lo and behold, those who complained
the loudest become the loudest advocates.

I've even seen this work on myself -- if you look at discussions
when Jonathan Chetwynd and Anne Pemberton first showed, I was
quite vociferously opposed to anything they had to say about
accessibility for people with cognitive disabilities.  Now I find
myself arguing strongly against those who (still) hold my original
viewpoint -- I've seen the light, to one degree or another.

In the same way, the idea that it's actually good to try to meet
the user's expressed needs instead of relying on the "user agent"
to do all the magic may seem frightening to some, and will produce
all manner of specious arguments and scenarios designed to frighten
you into immediate rejection of such ideas.  I find this
unfortunate, but there is little that can be done but to
persevere.

It's a shame that I can't show you a working example of this in
action -- that's not my doing, but rather that of the executive
management at Reef.  Were it up to me, I'd have a lot more to
show for the last year than what Reef's manage to (not)
produce.

Cheers, everyone.

--Kynn

--
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Accessibility - W3C - Integrator Network
________________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com

Received on Thursday, 8 November 2001 06:42:17 UTC