Re: HPR Evaluation

My comments marked CMN, Jim's marked JT

Some checkpoints have been snipped.

On Thu, 26 Aug 1999 thatch@us.ibm.com wrote:

  5.5     Allow the user to turn on and off rendering of captions.
  n/a
  HPR does not render closed captions. Clarification: Use "closed captions" since
  "CAPTION" is an element.

CMN I agree - this has been confusing in the reviews I have done with Amaya
(which, as an editor, requires the caption element for all tables) and Opera.

JT
          User Interface (Priority 1)
  5.6     Allow the user to turn on and off animated or blinking text.
  n/a
  HPR Does no render animated text.
  5.7     Allow the user to turn on and off animations and blinking images.
  n/a
  similar
  5.9     Allow the user to turn on and off support for user style sheets.
  n/a
  similar

CMN Actually audio styling is as relevant as visual styling. Support for
style control and suport for CSS are not necessarily the same thing, and that
should be clarified. But I think this and the next checkpoint are certainly
applicable.
JT
  5.10    Allow the user to turn on and off support for author style sheets.
  n/a
  similar
  5.11    Allow the user to turn on and off support for spawned windows.
  n/a
  similar
  6.1     Allow the user to control font family.
  no
  This is for the text view. Since HPR's designated audience is blind users,
  6.1-6.6 should not apply.
CMN 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.
JT
  6.2     Allow the user to control font size
  no
  ditto
  6.3     Allow the user to control foreground color.
  no
  ditto
  6.4     Allow the user to control background color.
  no
  ditto
  6.5     Allow the user to control selection highlighting (e.g., foreground and
  background color).
  no
  ditto
  6.6     Allow the user to control focus highlighting (e.g., foreground and
  background color).
  no
  I assume this is what we see in Windows standard list boxes.
  6.14    Allow the user to control speech playback rate.
  yes
  I am taking speech playback to mean synthesized speech! But my interpretation
  has to be wrong because these are not guidelines for us.
CMN I think your interpretation of the checkpoint is correct. I am not sure
why these guidelines are not for HPR
JT
  2.3     Provide information to the user about the current keyboard
  configuration.
  yes     Clairification sought. If keyboard is not configurable, is this met? Is
  this just an expansion of provide documentation?
CMN That is how I have interpreted it.
JT
          Device Independence (Priority 1)
  1.1     Ensure that all functionalities offered through the user interface may
  be operated through standard input device APIs supported by the operating
  system.
  no
  There are features not available with the mouse. This should *not* be
  non-compliance on an accessibility checklist. In fact they are not available
  without speech output. (The settings menu.) But that was intended for the target
  audience.
CMN This raises the same question about being able to design for a single
intended audience that I discussed above.

JT
  1.2     Ensure that the user can interact with all active elements of a document
  in a device independent manner.
  no
  JavaScript elements.

CMN I have a fervent hope that the Javascript Event model of HTML 4.0 is
changed to a less device-dependent one, as the HTML 4.00 specification itself
promises.
JT
  1.6     Ensure that all messages to the user (e.g., warnings, errors, etc.) are
  available through standard output device APIs supported by the operating system.
  yes
  Note, some error messages come as standard dialogs from Netscape, but HPR
  messages meet 1.6.
CMN Since HPR requires Netscape, I would suggest that HPR should be assesssed
on the basis of the mesages from Netscape as well as those it generates
itself.  
JT
  12.1    Use and provide accessible interfaces to other technologies.
  n/a
  We are an assistive technology; we don't want to provide API's. We shouldn't.
CMN Which restricts the functionality to people who meet all the functional
requirements of the particular assistive technology, rather than being able
to use assistive technology on top of this.

  9.3     For dependent user agents. Allow the user to view a document outline
  constructed from its structural elements (e.g., from header and list elements).
  yes
  The wording is not good. Don't we already have a 'navigate' by structural
  elements. Is this a technique for 8.6?
CMN I agree.
JT
  2.5     Allow the user to turn on and off author-specified keyboard
  configurations.
  no
  Could this possibly be saying, after arguing for AccessKey, now allow it to be
  turned off! AccessKey is a bad idea.
CMN I am not sure if it is a bad idea, but I certainly think that it should
have been thought through a lot more carefully.
JT
          For Links (Priority 2)
  9.5     Make available whether following a link will involve a fee.
  no
  Can this be determined?
CMN Good Question. There doesn't seem to be any method at the moment.
JT
          For Frames (Priority 2)
  5.12    Allow the user to turn on and off rendering of frames.
  yes
  Yes because of frame expand, but I think this is an unrealistic checkpoint. What
  does it mean to have rendering of frames truned off. Is this a request that
  provide access to NOFRAMES content. If not, probably should be.
  
          For Standards and Conventions (Priority 2)
  11.2    Support appropriate W3C Recommendations.
  yes
  But only the appropriate ones! Does this mean if we do not support ABBR and
  ACRONYM (P1) we are not P2 compliant or not P1 compliant?

  4.2     Allow the user to configure the visual arrangement of user interface
  controls.
  no
  This is an unreasonable accessibility checkpoint.
CMN For universal accessibility as a P3 I think it is not unreasonable. For
an interface that only has audio and keyboard components it is not
applicable.
JT
  5.14    Allow the user to turn on and off automatic page refresh.
  no
  Is this something in control of browser?
CMN Sure. Lynx doesn't ever turn them on, although they are passed to the
reader to activate the refresh whenever they want (as a static link).

Charles McCN

Received on Monday, 30 August 1999 09:58:10 UTC