- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Fri, 09 Mar 2001 15:08:14 -0600
- To: Charles McCathieNevile <charles@w3.org>, Ian Jacobs <ij@w3.org>
- Cc: <w3c-wai-ua@w3.org>
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