- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Mon, 01 Nov 1999 09:33:42 -0800
- To: schwer@us.ibm.com, Al Gilman <asgilman@iamdigex.net>
- Cc: w3c-wai-ua@w3.org
I agree with Rich. I think a comprehensive set of guidelines on scripting accessibility is out of scope for the current user agent working group. The current guidelines address scripting in many ways. 1. Elements which can respond to scripting events can be considered active elements in a document 2. Device specific events should have an alternative means for activation (notably mouse events). 3. Changes in the resource should be exported to assistive technologies for processing There needs to be a working group that directly address the issues of scripting accessibility. Whether this an existing group like Web Content or a new group is something that the coordination group should discuss. Jon At 06:56 AM 10/31/99 -0600, schwer@us.ibm.com wrote: > >I believe we should distinguish between potentially active elements, which > >here has grown to include every HTML element in the parse tree, from a >more > >restrictive class of actually active elements. The latter class must >cover > >the elements that one needs to visit to browse all action opportunities. > > >For navigation purposes the "active elements" should be a smaller set, >e.g. > >only the elements where the onFoo script-binding events are populated in > >addition to the anchor, form field, etc. always-active element types. > >I am not sure what you ask is achievable today (definging paritally active >elements) without an entirely separate working group effort. There are >numerous problems related to scripting languages that have not been >addressed today. Here are a couple: > >- A focus event may result in the JavaScript manufacturing a submenu >looking structure just be tabbing to the element. The element being watched >may not have a link at all. > >- There is a total lack of semantic information related to DOM changes >resulting from script activation. For example, in the previous bullet there >is no indication to the user that the node being wathed is actually a menu >and that the elements in the menu created are actually menu items. > >I believe a working group is needed for creating and integrating scripts, >like JavaScript, into a web page. We can't expect the User Agent to >interpret the function added by a script. This will result in future new >guidelines for: > >- web page authors >- DOM working group >- user agent guidelines > >Rich > > >Rich Schwerdtfeger >Lead Architect, IBM Special Needs Systems >EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm > >"Two roads diverged in a wood, and I - >I took the one less traveled by, and that has made all the difference.", >Frost > > >Al Gilman <asgilman@iamdigex.net> on 10/29/99 03:01:04 PM > >To: w3c-wai-ua@w3.org >cc: >Subject: Re: an attempt to refine the "active element" definition which > was tied to "focus" > > > > >comments at AG:: >At 10:38 AM 10/29/99 -0500, mark novak wrote: > >comments at MN: > > > >At 11:56 AM 10/28/99, Jon Gunderson wrote: > >>Comments in JRG: > >>At 12:34 PM 10/27/99 -0500, mark novak wrote: > >>> > 18.MN: Propose a new definition of active element, based on >keyboard > >>> >navigation discussion at F2F meeting > >>> > >>> > >>>===== proposed======= > >>> > >>>Focus > >>> > >>>The user focus designates which element in a document is active. The > >>>element with focus is therefore referred to as the active element. >Which > >>>elements can take focus and thus be active depends on the document >language, > >>>and whether those features are supported by the user agent. In HTML4.0 > >>>documents, for example, elements which can take focus and are thus > >>>capable of being active elements include links, image maps, form > >>>controls, elements with a value for the "longdesc" attribute, and > >>>elements with associated scripts (event handlers) explicitly associated > >>>with them (e.g., through the various "on" attributes). In the > >>>near future, it is expected that any element defined in the HTML >document > >>>language, for example, will be able to accept the focus and thus could >be > >>>defined as an active element. > >AG:: > >I believe we should distinguish between potentially active elements, which >here has grown to include every HTML element in the parse tree, from a more >restrictive class of actually active elements. The latter class must cover >the elements that one needs to visit to browse all action opportunities. > >For navigation purposes the "active elements" should be a smaller set, e.g. >only the elements where the onFoo script-binding events are populated in >addition to the anchor, form field, etc. always-active element types. > >Al > >> > >>JRG: I don't think we need the term "near future" since scripts can be > >>attached to any element. > > > >MN: Fine change by me. > > > > > >> > >> > >>>Once an element has the user focus, it may be activated through any >number of > >>>mechanisms, including the mouse, keyboard, an API, etc. The effect > >>>of activation again depends on the element and also whether the user >agent > >>>supports that element being active. For instance, when a link is > >>>activated, the user agent generally retrieves the linked resource. > >>>When a form control is activated, it may change state (e.g., check >boxes) > >>>or may take user input (e.g., a text field). Activating an element with >a > >>>script assigned for that particular activation mechanism (e.g., mouse > >>>down event, key press event, etc.) causes the script to be executed. > >>> > >>>A viewport has at most one focus. When several viewports co-exist, > >>>each may have a focus, but only one is active, called the current > >>>focus. The current focus is generally presented (e.g., highlighted) > >>>in a way that makes it stand out. > >>> > >>> > >>> > >>> > >>> > >>>==== original==== > >>> > >>>The user focus designates an active element in a document. Which > >>>elements are active depends on the document language and whether > >>>the features are supported by the user agent. In HTML documents, > >>>for example, active elements include links, image maps, form > >>>controls, elements with a value for the "longdesc" attribute, and > > >>>elements with associated scripts (event handlers) explicitly associated > >>>with them (e.g., through the various "on" attributes). An element > >>>with the focus may be activated through any number of mechanisms, > >>>including the mouse, keyboard, an API, etc. The effect of activation > >>>depends on the element. For instance, when a link is activated, the > >>>user agent generally retrieves the linked resource. When a form > >>>control is activated, it may change state (e.g., check boxes) or may > >>>take user input (e.g., a text field). Activating an element with a >script > >>>assigned for that particular activation mechanism (e.g., mouse down > >>>event, key press event, etc.) causes the script to be executed. A > >>>viewport has at most one focus. When several viewports co-exist, > >>>each may have a focus, but only one is active, called the current > >>>focus. The current focus is generally presented (e.g., highlighted) > >>>in a way that makes it stand out. > >> > >>Jon Gunderson, Ph.D., ATP > >>Coordinator of Assistive Communication and Information Technology > >>Chair, W3C WAI User Agent Working Group > >>Division of Rehabilitation - Education Services > >>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 > > > > Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Chair, W3C WAI User Agent Working Group Division of Rehabilitation - Education Services 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 Monday, 1 November 1999 10:29:26 UTC