Re: ACTION: PP to Proposal on ways User Agents could use live regions.

The author of firevox might be able to help.

----- Original Message ----- 
From: "Jim Allan" <jimallan@tsbvi.edu>
To: <wai-xtech@w3.org>
Cc: <pparent@us.ibm.com>
Sent: Thursday, July 26, 2007 4:30 PM
Subject: FW: ACTION: PP to Proposal on ways User Agents could use live 
regions.


Hi,
Live regions were discussed during several  User Agent Working Group
meetings. There is a proposal for rewriting a checkpoint.  A reality check
is needed on the assumptions and what the expected UA (UA+AT) behavior
should be for live region markup. See the message below.

Any thoughts appreciated.

Jim Allan
  -----Original Message-----
  From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Peter Parente
  Sent: Thursday, July 26, 2007 9:24 AM
  To: Jan Richards
  Cc: WAU-ua; w3c-wai-ua-request@w3.org
  Subject: ACTION: PP to Proposal on ways User Agents could use live
regions.


  This action item concerns checkpoint 3.5: Toggle automatic content
retrieval and its application to dynamic regions within a page (e.g. AJAX).
I indicated on the wiki that user agents may be able to respect this
guideline for partial page refreshes if the page contains appropriate live
region markup.  (wiki checkpoint 3.5
http://www.w3.org/WAI/UA/wiki/ConfigToNotRender)

  We must answer two questions before we can decide how to rewrite this
guideline. I discuss them in detail below. At the end of the email, I take a
crack at reformulating checkpoint 3.5 under a few assumptions.

  1) What "part" of the UA should we hold responsible for this guideline?

  So far, it has been implied that the AT is responsible for deciding how
live regions are presented. For instance, if a screen reader is busy reading
the content of a page and an event occurs outside the point of regard in a
"rude" live region, whether that change is announced or not is determined by
the screen reader settings (e.g. "Rude regions interrupt? [yes/no]").
However, use of live region information is not limited to ATs. For instance,
the browser could conceivably have an inherent setting that controls whether
or not changes to the DOM are allowed. Essentially, this toggle would allow
the user to make parts of the DOM "read-only" on demand. In both cases, the
granularity can range from a single live region, to live regions with
certain properties, to all live regions on a page.

  We need the following information from browser developers before we know
if this technique is feasible or not.

  a) Is it possible to implement a "read-only DOM" setting without breaking
existing Web apps?
  b) Is the base browser the right place to implement such a setting?
  c) Is it possible to implement in a browser extension?

  2) Is "retrieval" what we should really be toggling?

  This question is about the intention of the guideline as compared with the
language used. Relying on live region markup to block changes to the DOM is
a technique applied after content has been retrieved. In fact, it can only
be applied after content has been fetched. Beforehand, the browser has no
concept of the purpose of the fetch. For instance, some Javascript code
might send a message to the server and receive a response that is never
rendered for the user. On the other hand, the Javascript code may intend to
write the response into the DOM for the user. But until that code actually
touches the DOM API, the UA has no way of determining where in the page it
will appear (i.e. in what live region, not in a live region, not in a
visible element).

  I think the true intention of this checkpoint is to "toggle automatic
content changes." In some cases, such as a full page refresh, blocking
content retrieval may be the proper technique. In the case of AJAX, however,
it is not, nor should it be implied.

  If we assume that implementing read-only DOM is possible and retrieval is
more of a technique than a requirement, we might rewrite the guideline as
follows:

  3.5 Toggle automatic content updates

  1. Allow configuration so that the user agent only replaces existing page
content on explicit user request.

  Normative inclusions and exclusions

  1. When the user chooses not to update content, the user agent may ignore
that content; buffering is not required for later rendering.
  2. When automatic content updates are disabled, a user agent may choose to
avoid retrieving content that it will ultimately not render. The browser
should take care not to block fetches that will not render in the UI.
  3. This checkpoint only applies when the user agent, not the server,
automatically initiates a content update.

  (I suggest we remove the second part of 3.5 about redirects. Why don't
these count?)

  Notes

  (Can stay the same.)

  Techniques

  (This is where notes about blocking page refreshes, blocking redirects,
and making live regions read-only can go.)

  Peter Parente
  pparent@us.ibm.com
  Tie: 526-2346
  IBM: 919-486-2346
  Jan Richards <jan.richards@utoronto.ca>


                Jan Richards <jan.richards@utoronto.ca>
                Sent by: w3c-wai-ua-request@w3.org
                07/12/2007 03:44 PM


              To
              WAU-ua <w3c-wai-ua@w3.org>


              cc



              Subject
              Re: User Agent Teleconference for July 12 2007




  Notes from the call:

  http://www.w3.org/2007/07/12-ua-minutes.html


  Action items:

  ACTION: JR to Expand on idea of blocking functional areas: animation,
  low contrast, etc.

  ACTION: PP to Proposal to combine 3.2 and 3.3

  ACTION: JR to Proposal to limit "background image" to body of document

  ACTION: JA to Get thoughts together about 3.4 "All executable content",
  managing configuration

  ACTION: JR to Proposal to have config uration not to have stripped down
  user agent windoews

  ACTION: PP to Proposal on ways User Agents could use live regions.

  ACTION: JA to Proposal that if a live region has focus, it shouldn't
  update.]


  Cheers,
  Jan


  Jim Allan wrote:
  > W3C User Agent Teleconference for July 12 2007
  > -------------------------------------------------------------
  > Chair: Jim Allan
  > Date: Thursday, July 122007
  > Time: 2:00-3:00 pm Boston Local Time, USA (19:00-20:00 UTC/GMT)
  > Call-in: Zakim bridge at: +1-617-761-6200, code 8294#
  > for UK use 44-117.270-6152
  > IRC: sever: irc.w3.org, port: 6665, channel: #ua.
  > -------------------------------------------------------------
  >
  > Regrets, agenda requests, or comments to the list
  >
  > Agenda:
  >
  > 1. Changing Meeting time (move meeting time ahead 1 hour)
  >
  > 2. Ideas for topics for Tech Plenary day
  >
  > 3. Wiki - review edits
  >    http://www.w3.org/WAI/UA/wiki/UaagDocument
  >
  > Jim Allan, Webmaster & Statewide Technical Support Specialist
  > Texas School for the Blind and Visually Impaired
  > 1100 W. 45th St., Austin, Texas 78756
  > voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
  > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
  >

  --
  Jan Richards, M.Sc.
  User Interface Design Specialist
  Adaptive Technology Resource Centre (ATRC)
  Faculty of Information Studies
  University of Toronto

    Email: jan.richards@utoronto.ca
    Web:   http://jan.atrc.utoronto.ca
    Phone: 416-946-7060
    Fax:   416-971-2896

Received on Thursday, 26 July 2007 22:39:54 UTC