Re: Clarification of checkpoint 7.4

Kynn Bartlett wrote:
> 
> At 03:40 PM 8/18/2000 , Wendy A Chisholm wrote:
> ><proposal>
> >8. Clarification of checkpoint 7.4
> >Added: xx August 2000
> >Type: Clarification
> >Refers to: Checkpoint 7.4 of 5 May 1999 version
> >Description (and correction): Checkpoint 7.4 says,
> ><blockquote>
> >Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages. [Priority 2] For example, in HTML, don't cause pages to auto-refresh with "HTTP-EQUIV=refresh" until user agents allow users to turn off the feature.
> ></blockquote>
> >
> >This checkpoint is trying to address two issues:
> >
> >1. Disorientation due to unexpected changes in content. Users should expect  changes in content when they follow a link or submit a form. However, the author may cause unexpected changes to content by using scripts or other markup. The author should inform the user of changes that will occur without explicit user interaction.
> >For example, if pressing a submit button will cause an intermediate page to appear before the final results are displayed, inform the user in advance. In short, warn the user of what will happen without their explicit interaction.
> >
> >2. Response time not long enough to interact or comprehend the content before it changes.  To ensure that users can interact with and understand content in a time frame suitable to their needs, do not cause automatic content changes at regular intervals (such as a page of stock quotes that is updated every 3 minutes).
> >
> >There is an "until user agents" clause that is not yet satisfied for this checkpoint.  Note that the User Agent Accessibility Guidelines will require user agents to provide the ability for users to update pages manually.
> ></proposal>
> 
> Question:
> 
> Does this mean that I can _never_ provide a service that updates
> itself regularly?  For example, does this mean that self-updating
> stock pages are always off-limits?
> 
> What if I provide the same content through an accessible version
> as well?  

Yes, that is what you should do, according to checkpoint 11.4.

> A page that only refreshes when the user presses reload,
> AND a page that autorefreshes? 

For example.

> What if the autorefresh page has
> a large warning on the front?  What if the time between refreshes
> is user-configurable?  

That's a user agent capacity (that is not required by the UAAG 1.0,
by the way: we only say the UA has to allow the user to access
the new content manually).

> What if the page also includes prominent
> controls that say "halt autorefresh" and "resume autorefresh"?

Generalized:

 Until user agents do A, or unless you the author do A, etc.

However, if the author provides a mechanism that is not
interoperable, users are likely to lose.

> The problem is with this checkpoint itself.  It is too absolute,
> too negative, and too specific.  It provides only one alternative
> -- "rip it off the page" -- instead of telling how to do it correctly.
>
> "If you create auto-refreshing web pages, make sure the user has
> control over the refresh cycle."  And then the proposed comments
> plus the quote about HTTP headers plus suggestions from my
> comments go into the techniques (or in 2.0, into the technology-
> specific checkpoints and the techniques/examples).

My only fear is if the "making sure" part requires proprietary
technology, etc. 

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Friday, 18 August 2000 20:10:47 UTC