Spirited Advocacy of CC/PP (was: Automatic Detection of Screen Readers and Other AssistiveTechnology)

On Thursday, June 12, 2003, at 04:32 AM, David Poehlman wrote:
> This is further complicated by the fact that
> it is often the case that screen readers are used on shared systems and
> often, the screen reader is running for the benefit of one of the 
> people
> sharing the system.  We have already seen problems with screen readers 
> on
> shared systems using internet explorer and  jaws for instance where a 
> person
> using a screen reader wants to present something on the web to a non 
> screen
> reading audience or to seek assistance from one who does not use a 
> screen
> reader or to assist someone who does not use a screen reader because 
> of the
> way the pages are redrawn by this combination.

This is why simplistic approaches to content adaptation -- such as a 
single
"yes, they have a screenreader" as suggested so far in this thread -- 
aren't
a solution.

> The aim of the "web content
> accessability guidelines v1.0" is to facilitate the use of web sites 
> by the
> broadest audience possible without the need for special server tweeks 
> or
> text only pages or specially designed pages.

Except we know from experience that there's the possibility to use 
special
server tweaks to improve the accessibility of a site.  Yes, it's true.

It's not always the best approach for all sites, but in some cases it is
much simpler, overall, to make specific changes on a site which can 
solve
specific problems, rather than hope that everyone will convert to new
software which lacks certain bugs.

> Also, if you start down the
> road of special delivery based on the fact that there is a screen 
> reader
> present, you will then need to find out which screen reaer is 
> available and
> on what platform because each is unique and what works for one screen 
> reader
> may/will not work for another.

Exactly.  Or rather, you'll need to know the capabilities of each 
screenreader,
as identified by the CC/PP profile sent by the user agent.

There's two ways to deal with this issue:

1.  User agent identifies the screenreader (and other factors affecting
     the capabilities and preferences of the user environment). The 
server
     maintains a list of all possible screenreaders and looks it up on 
the
     list.

2.  User agent identifies the specific capabilities and preferences via
     self-identification in CC/PP.  This means that no list is necessary;
     instead, each screenreader simply needs to point out what it can and
     can't do.

> Screen readers also vary from browser to
> browser due to enherent differences in the way they interact with the
> browser.  You might detect the presense of msaa on windows for 
> instance and
> while you are at it, what version of msaa and ie are being used, but 
> this is
> a slippery slope due to the fact that the curve gets pretty steep as 
> to what
> screen reader is ultimately being used and what version of the screen 
> reader
> because again, we have differences in the way they interact in the
> environment.

Thus the need for a robust CC/PP vocabulary. :)

> Any move toward providing "screen reader facilitation" only furthers 
> the
> accessability devide at a time when it should be narrowing due to 
> dwindling
> resolves and resources.

I disagree, but only if you're talking about CC/PP-style adaptation 
based on
a spectrum of capabilities.  If you're talking about single-bit "is 
there a
screenreader turned on?" autodetection then I certainly do agree!

> One last point here is that technology is a moving
> target and there are platforms now and in the future that will be 
> accessing
> the web and they will constantly change.  The screen reader of 
> tomorrow if
> forced to take what is handed to it automatically due to the fact that 
> the
> presence of a screen reader has been detected may not render what has 
> been
> sent in an acceptable way.

This is why you need self-identifying user environments via CC/PP that 
identify
various factors such as screenreader and browser capabilities, and not 
just
rely on a simplistic approach.  Such an approach is definitely 
"future-proof"
because it doesn't concern itself with any specific set of capabilities 
or
preferences that exist in today's screenreaders.

> Also, There are many people who need content the
> way it is delivered to everyone else for a myriad of reasons, they 
> might
> want to print the page, they might want to audit the page for standards
> compliance etc.  If you do anything along these lines, the best 
> solution all
> things having been considered is to offer the user a choice.

Exactly.  And ultimately that's what CC/PP presents -- a standardized 
way for
presenting user choices rather than having each site derive its own 
methods
for doing so.

In a well-done CC/PP-aware user agent, you'll be able to maintain 
multiple
profiles and merge them if needed, by the way.

> This gets at
> the issue of bandwidth and many others.  When offering the choice 
> though, it
> is important that the resultant interactability be as equal as 
> possible to
> the other available choices making it almost moot to provide choices 
> in the
> first place.

> Lastly, When I explain to developpers that some users who are offered a
> choice of a high bandwidth site versus a text only site can have 
> issues with
> either and that a low frills or lite site might be a better choice, 
> they
> often opt for developping a site that needs no alternate.

Yeah, but if it could be done automatically...  What we need is better
Web server software that actively supports accessibility.  (Something 
like
Nick Kew's mod_accessibility on steroids -- or, dare I say it, 
something like
Edapta.)

--Kynn

PS:  By the way, there are already thousands of sites which are 
providing
      alternate versions of content.  These are any sites making content
      available via RSS.  Nearly all RSS feeds are automatically 
generated
      by software on the Web server -- so developers are not necessarily 
as
      adverse to the idea as you'd think.

> --
Kynn Bartlett <kynn@idyllmtn.com>                     http://kynn.com
Chief Technologist, Idyll Mountain                http://idyllmtn.com
Author, CSS in 24 Hours                       http://cssin24hours.com
Inland Anti-Empire Blog                      http://blog.kynn.com/iae
Shock & Awe Blog                           http://blog.kynn.com/shock

Received on Thursday, 12 June 2003 10:45:56 UTC