W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 1999

Re: HPR Evaluation

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 01 Sep 1999 05:53:59 -0400
Message-Id: <4.1.19990830112832.009c3e30@pop3.concentric.net>
Message-Id: <4.1.19990830112832.009c3e30@pop3.concentric.net>
To: Charles McCathieNevile <charles@w3.org>
Cc: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
aloha, charles!

you, indeed, cut to the heart of the matter vis a vis the "third stream" of
browsers, when you wrote:

>This cuts to a philosophical argument which is fairly central to this
>process. If it is OK for a User Agent to be applicable only to a certain
>market segment (blind users, people with 21" monitors, whatever) should they
>be able to conform to the User Agent Guidelines? It seems that the division
>we currently have for conformance breaks down here - Jim argues cogently that
>HPR is not universally accessible and was never intended to be. On the other
>hand it is an assistive technology for people with functional restrictions
>which mean that substituting audio output for visual output provides
>accessibility. Yet as I understand it HPR (bundled with Netscape) is an
>independent browsing solution, and HPR on its own is half a piece of software
>that does nothing at all.

which is precisely the question that i, dave, and a host of others have been
asking for quite some time now -- as much as i like HPR as a product, and as
much as i respect IBM SNS, and have benefited from its products, i fail to
understand how HPR can be considered a "stand-alone" product when, as charles
points out, HPR on its own does nothing... 

which leads me to repeat a series of questions which i originally posed on-list
in july, but which have gone unanswered:

1) can HPR operate independently of Netscape?  (the obvious answer--at least at
the present time--is no)
2) could HPR be adapted for use with MSIE and Opera?

if not, then HPR clearly falls into a grey area, in which it cannot be
classified as a browser (qua browser, due to its dependence on Netscape) and
not as a plug-in, inasmuch as it is HPR, and not Netscape, which is parsing the
document source in order to render it as audio and text...

what i don't understand, especially in light of last week's teleconference, is
how one can excuse HPR (or any similar niche-market targeted browsing
interface, which also makes available a "graphical view") from UI-related
checkpoints simply because (in the case of HPR) the "Netscape view" isn't
controlled by HPR, but is passed on by it untouched..  if HPR is allowing users
to view output as rendered by Netscape, and Netscape isn't in full compliance
with the UI-related checkpoints, then HPR, is bound to respect the UI-related
checkpoints, which Jim Thatcher, in a conformance review of HPR, submitted to
this list, marked as "not applicable"...

either HPR has to pick up the slack for Netscape when presenting the "graphical
view", or Netscape has to address the UI-related checkpoints fully and
thoroughly...  neither should be allowed to shrug responsibility off upon the
other and claim compliance -- not even under the current class system...

He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
Received on Wednesday, 1 September 1999 05:50:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:22 UTC