RE: refresh

At 06:34 AM 2003-07-17, Little, James wrote:

>I don't see any need for META refresh or any such tags - if the page needs 
>to be refreshed it should be left for the user to do so (Accessibility 
>aside, it annoys me when pages are refreshed and change while I am in the 
>middle of reading the page).
>
>Just my 2p

One needs to separate two issues:

1. redirection.  Do it with the 'right tool' in HTTP; don't fake it with a
refresh.

2. bona-fide refresh to serve as a subscription to an event stream.

In either case, there are facilities in HTTP to do the job and so far as I
know that's the better way to do it.  META HTTP-equiv is a hack to work
around problems in the author-server handoff.  The problem is that the
people who put the META tags in the pages don't control what the server does.

http://lists.w3.org/Archives/Public/www-tag/2002May/0210.html

Getting that fixed takes more than a pronouncement from us.  The User Agent
group took a good approach in stating the access requirements in terms of
the experience offered to the user, and leaving the HTTP header vs. html:meta
protocol-repair hack to the web architecture folks.

Orthodoxy is good for accessibility, but we should not go off on our own to
frame "adhere to standards" techniques.  This is an area where we need to
work with the QA group, the Technical Architecture Group (TAG) and the
working groups behind the specifications in campaigning for adherence to the
published specification and their best use.

In terms of bona-fide refresh, this is a mixed blessing for accessibility,
not a uniformly bad thing.  Affording the user supervisory command of the
event-handling policies is a cross-disability position.  Disallowing or
discouraging refresh is not.

There are users with motor disabilities and users with cognitive disabilities
where the values are all the other way.  Here animating the web application by
allowing events to be pushed from the server and alter the state of the client-
side process are access enablers, not breakers.

This is why the User Agent WG elected for configurability, not prohibition,
in this area.  Please review the W3C Recommendation in this area

  http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-content-retrieval

Events that push from the system to the user interface are as close as your
alarm clock.  The INCITS-V2 committee working on a remote console standard
is working on the premise that the system has to support pushing events from
the system to the user and not be limited to a pure-pull protocol.  Would
you want to have to manually poll your doorbell?    There are things going
on like tornado alarms that can be known to the computer network and are
worth interrupting a user for.

http://www.incits.org/tc_home/v2.htm

Please give the architecture sketch of the Multi-modal Interaction group
a looking over.  This lays out their idea of the general dialog fabric that
will replace "pure pull of documents."  Stock tickers we should be able to
get recast as Timed Text media objects so it is clear to the assistive
technology that the content change on the push event is limited to the
latest bit of stock quote and not the whole page.

  http://www.w3.org/TR/mmi-framework/

  http://www.w3.org/AudioVideo/TT/

Popular uptake of the Web has been powered no more by "access to all the
World's information" than it has been powered by access to up-to-the-minute
information.

Event streams bearing information that simply wasn't available before *now*
is a class of web content that is of value to people with disabilities as
much as it is of value to the general public.

Al

>James

Received on Thursday, 17 July 2003 17:52:53 UTC