Re: Proposed editorial changes based on Aaron Leventhal review

I have argued that it is not editorial, that it is in fact introducing a new
requirement, and in the process, making it impossible to conform to the
guidelines by using a technique that is better than the most basic in terms
of results for the users. Ian has since withdrawn the proposal. Are you
taking it up again?

Charles

On Fri, 9 Mar 2001, Jon Gunderson wrote:

  I think Ian's proposal for the refresh checkpoint seems very clear and
  makes the wording more consistent with other checkpoints in UAAG.  It seems
  to be very editorial.

  Jon


  At 11:54 AM 3/8/2001 -0500, Charles McCathieNevile wrote:
  >My proposal is for _A_ technique for doing this in a really cool and helpful
  >way (i.e. goes way beyond the P1 requirement of the checkpoint). That's why I
  >proposed it as a technique.
  >
  >I explicitly suggested not changing the checkpoint. I still don't see how the
  >checkpoint fails in any way to cover your requirements a and b as written,
  >and that the proposed change would preclude the technique that I have
  >suggested.
  >
  >Therefore I object to changing the checkpoint in the manner foreshadowed.
  >
  >Charles
  >
  >On Thu, 8 Mar 2001, Ian Jacobs wrote:
  >
  >   Summarizing:
  >
  >    - The proposal was "don't do the refresh"
  >    - Charles says that's too restrictive, since the UA might
  >      do the refresh and provide the user with a useful diff
  >      on demand.
  >
  >   I still support the proposed change for the following reason:
  >
  >    a) The user need is stability.
  >    b) The minimal requirement is "don't make the change unless
  >       the user says it's ok"
  >    c) Charles' proposal goes beyond the minimal requirement that
  >       I believe the checkpoint was meant to accomplish.
  >
  >   (It would seem that the proposed change is not editorial.)
  >
  >   I propose therefore that the minimal requirement is
  >   "don't do the change unless the user says ok" and that the
  >   checkpoint be changed to reflect that.
  >
  >   The user agent can do more (e.g., provide useful diffs on demand),
  >   but I don't believe that's ever been the intention of the
  >   checkpoint.
  >
  >    - Ian
  >
  >   Charles McCathieNevile wrote:
  >   >
  >   > OK...
  >   >
  >   > My assumptions:
  >   > The point of the checkpoint is to keep the page stable if the user
  >   > desires. What the user agent does behind the scenes has more or less no
  >   > impact for accessibility.
  >   >
  >   > Where there are in fact changes being made to the page, it would be
  > helpful
  >   > for a suer to know what they are to some level of detail lower than
  > "the page
  >   > changed (somewhere, perhaps)".
  >   >
  >   > My conclusions (I figure we all have the same information to work on :):
  >   > The existing wording meets the accessibility requirement.
  >   >
  >   > Aaron's potential interpetation of it is a valid interpretation.
  >   >
  >   > Aaron's approach gives rise to the following technique for doing
  > something
  >   > even better than just  not doing the refresh, viz:
  >   >
  >   >   Get the new version and find out what, if anything, has changed in it
  >   >   (simple markup-aware diff). Store that information, sequentially (a
  > la a
  >   >   markup-aware version of CVSWeb, and Aaron probably has access to such).
  >   >   Allow the user to view that information at any time, as a seperate
  > function
  >   >   to doing the update.
  >   >   This allows the user to work out what is going on in the original
  > page, and
  >   >   then just find out what changes. (It is probably helpful to know if
  > nothing
  >   >   changes, too). A couple of iterations of this should be helpful in
  > deciding
  >   >   whether to turn off auto-configuration, and read changes from this
  > function
  >   >   as desired, or turn it back on.
  >   >
  >   > A working example of sorts:
  >   >
  >   > Cricinfo - http://www.cricinfo.org - provides real-time (more or
  > less) score
  >   > and commentary of cricket matches from around the world. If I use a
  > standard
  >   > scoreboard, it auto-refreshes frequently, but it only changes a few
  > parts of
  >   > the page - the current batsmen/bowlers, the current score, and the most
  >   > recent commentary in full and abbreviated form. The scoreboard for
  > batsmen
  >   > who are already out, and for previous innings, remains unchanged.
  >   >
  >   > With a system like I have described, I could look at the scoreboard,
  > and look
  >   > at the changes. This would enable me to find out which bits are being
  >   > changed, so I know which bits to look at again when the page is
  > updated, and
  >   > which bits to ignore. Or I could decide to stop the autorefresh, and
  > do it
  >   > manually when I want. (I often do this, and there is an option on the
  > site to
  >   > get a version which does it too). Or I could start from a known page, and
  >   > read the changes made in subsequent (unseen) versions - updated
  > commentary,
  >   > or scores...
  >   >
  >   > Cheers
  >   >
  >   > Charles
  >   >
  >   > On Thu, 8 Mar 2001, Ian Jacobs wrote:
  >   >
  >   >   Charles McCathieNevile wrote:
  >   >   >
  >   >   > Yes, I object. I am proposing to do something different with the same
  >   >   > information, for the reasons given.
  >   >   >
  >   >   > Also becuase I think it places operational constraints on the
  > User agent that
  >   >   > may be in line with normal implementation methods but are not
  > actually
  >   >   > enhancing the accessibility of the user agent, and may detract
  > from it.
  >   >
  >   >   I'm sorry, I simply don't understand your point I guess.
  >   >   I thought the checkpoint has tried to say "Don't do automatic
  >   >   refreshes". Aaron said that wasn't clear. The proposed rewrite is
  >   >   supposed to be clearer.
  >   >
  >   >   I don't understand what the operational constraints you are talking
  >   >   about are.
  >   >
  >   >   I also didn't understand your technique.
  >   >
  >   >   Could you expound further on the source of your objection?
  >   >   My goal here, mind you, is only editorial clarification, not
  >   >   alignment with existing implementations, etc.
  >   >
  >   >    - Ian
  >   >
  >   >   > cheers
  >   >   >
  >   >   > Charles
  >   >   >
  >   >   > On Thu, 8 Mar 2001, Ian Jacobs wrote:
  >   >   >
  >   >   >   Charles McCathieNevile wrote:
  >   >   >   >
  >   >   >   > I don't see that there is a problem using the method Aaron
  > suggested. It
  >   >   >   > would enable a user agent to seperately queue the changes to
  > a document that
  >   >   >   > gets updated on the fly, which seems like a good thing since
  > they could be
  >   >   >   > offered to the user who had asked for a page to stay still,
  > as a seperate
  >   >   >   > item. It might be helpful to have this available, and
  > I  can't see that it
  >   >   >   > breaks anything we need.
  >   >   >   >
  >   >   >   > So I would propose to instead add this as a technique.
  >   >   >
  >   >   >   Would you object to the editorial change?
  >   >   >
  >   >   >    _ Ian
  >   >   >
  >   >   >   >   Reference document 24 Feb 2001 draft [1].
  >   >   >   >
  >   >   >   >   1) Checkpoints 3.5/3.5
  >   >   >   >
  >   >   >   >      3.5 Allow configuration so that client-side content
  > refreshes
  >   >   >   >      (i.e., those initiated by the user agent, not the server)
  >   >   >   >      do not change content except on explicit user request.
  >   >   >   >
  >   >   >   >   Aaron suggested that this might be interpreted as meaning
  >   >   >   >   "compare and see if the refresh changed the content or not".
  >   >   >   >
  >   >   >   >   Proposed change:
  >   >   >   >
  >   >   >   >      Allow configuration so that the user agent does not
  >   >   >   >      perform client-side content refreshes (i.e., those
  >   >   >   >      initiated by the user agent, not the server)
  >   >   >   >      except on explicit user request.
  >   >   >   >
  >   >   >   >   I propose the same type of change to checkpoint 3.6:
  >   >   >   >
  >   >   >   > [snip]
  >   >   >
  >   >   > --
  >   >   > Charles
  > McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
  >   >   > W3C Web Accessibility
  > Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
  >   >   > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >   >   > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis
  > Cedex, France)
  >   >
  >   > --
  >   > Charles McCathieNevile    http://www.w3.org/People/Charles  phone:
  > +61 409 134 136
  >   > W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1
  > 617 258 5999
  >   > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >   > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis
  > Cedex, France)
  >
  >
  >
  >--
  >Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409
  >134 136
  >W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617
  >258 5999
  >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
  >France)

  Jon Gunderson, Ph.D., ATP
  Coordinator of Assistive Communication and Information Technology
  Division of Rehabilitation - Education Services
  MC-574
  College of Applied Life Studies
  University of Illinois at Urbana/Champaign
  1207 S. Oak Street, Champaign, IL  61820

  Voice: (217) 244-5870
  Fax: (217) 333-0248

  E-mail: jongund@uiuc.edu

  WWW: http://www.staff.uiuc.edu/~jongund
  WWW: http://www.w3.org/wai/ua



-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Saturday, 10 March 2001 11:14:31 UTC