Re: Proposed editorial changes based on Aaron Leventhal review

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

Received on Friday, 9 March 2001 16:05:41 UTC