W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Re: Proposed editorial changes based on Aaron Leventhal review

From: Ian Jacobs <ij@w3.org>
Date: Thu, 08 Mar 2001 12:07:25 -0500
Message-ID: <3AA7BC4D.E7A421FD@w3.org>
To: Charles McCathieNevile <charles@w3.org>
CC: w3c-wai-ua@w3.org
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.

Yes, I understand that and can add it to the techs doc.
 
> 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.

Ok, I withdraw my proposal.

 - Ian

> 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)

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 8 March 2001 12:07:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:29 UTC