Re: Part II: Issues about UA Guidelines raised during MAC IE evaluation

Snipped anything where I would have said "me too", and scattered comments
into the rest.

original in IJ
Jon's  Responses in JRG
and my additions in CMN
  
  >Issue 3) Define set of explicit submit controls for HTML
  >   Checkpoint 11.2 reads: Allow configuration so the user is
  >   prompted to confirm any form submission not caused by explicit
  >   activation of a form submit control.
  >
  >   Proposal: Add to the Note following the checkpoint that in HTML 4,
  >   the only explicit controls are INPUT type="submit" and type="image",
  >   and BUTTON type="submit".
  
  JRG: Yes I think this would help clarify the HTML 4 case.  In the case of 
  scripting though the user agent will also know that the script is 
  requesting a new document using the "location" property (NN) or method with 
  3 types of methods (IE) of the windows object.  In this case the user agent 
  does not know if this  function was called as part of an explicit user 
  request or if the script is generating the page change without explicit 
  user notification.  The script writer currrently would need to design there 
  code for only explicit user activiation.
  
CMN There are two issues here - submitting information that hasn't been
completed, which was the original motivation for this checkpoint, and being
shifted without knowing why, which is covered by requirements such as turning
off auto-refresh, although the various possible javascript techniques for
doing it cvould be incorporated into the techniques document, along the lines
of Jon's suggestion.

IJ

  >Issue 5) Definition of "stalled". Checkpoint 9.4 reads:
  >
  >    9.4 When transferring content (e.g., a document, image, audio, video,
  >        etc.) indicate what percentage of the content has been
  >transferred
  >        and whether the transfer has stalled.
  >
  >    Issue: What is the definition of "stalled"? What is the length of
  >time
  >    before the transfer should be considered stalled.
  >

CMN no clues on this one.
  
IJ

  >Issue 6) Does relative position of the viewport include horizontal
  >position?
  >
  >    Proposal: Yes. In fact, the dimensions depend on the viewport. An
  >audio
  >    viewport would not (I believe) have this issue since the output is
  >one
  >    dimensional.
  
  JRG: I I think horizontal is very important for people with visual 
  impairements.  Many times they increase font size and information formatted 
  in table columns disappears off the right hand side of the screen.  Many 
  users don't know the information is there and the horizontal scroll bars 
  are important to give people information.
  
CMN definitely agree. For text a better option is often to be able to wrap,
but people do nasty layout tricks that can work out messy with that, and you
can't wrap an image anyway, as a rule.

IJ

  >Issue 7) General advice about implementation of optional features of a
  >    specification.
  >
  >    Proposed: Add the following statement to the spec (as a Note to
  >    either to checkpoint 6.1 or 6.2):
  >
  >       "Developers should not implement an optional feature of
  >        a specification if that feature may pose accessibility
  >        problems and if the user cannot turn off the feature
  >        in the user agent."
  
  JRG: It seems reasonable to me, but what test do we give developers to know 
  if it will affect accessibility?  Is there an example of an optional feature?
  
CMN A feature which determines whether it is possible to do, or to
"view" something which is required or suggested by WCAG. (This is another
case where relative priorities would be helpful, if you can bear the extra
complexity).

cheers

Charles

Received on Tuesday, 18 July 2000 12:01:18 UTC