Re: Proposed editorial changes based on Aaron Leventhal review

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)

Received on Thursday, 8 March 2001 11:17:08 UTC