- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 26 Jul 2007 15:30:18 -0500
- To: wai-xtech@w3.org
- Cc: pparent@us.ibm.com
- Message-id: <HDEAKIPKOHBCMDILOOPNKEMBIIAB.jimallan@tsbvi.edu>
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 20:29:51 UTC