Re: an attempt to refine the "active element" definition which was tied to "focus"

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:

I agree that more help making active stuff accessible is a critical
problem, and a big one.  It is not something that we can lay on the User
Agent today with a proposed  "readily achievable" method.

On the other hand, I am not asking above for anything exotic.  What I was
trying to ask is that, for the purposes of "navigating among active
elements," the element _instances_ be checked to see which have explicit
links to scripts, and that we not put elements on this list just because
their _type_ is one which _could_ have a script reference attached.  The
latter practice would load up the "active elements" list with too many
places you don't want to stop as you skim through.  The usefulness of the
very popular practice of tabbing through a page would be destroyed, I fear.

Al

>
>- 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
>>
>

Received on Sunday, 31 October 1999 09:40:30 UTC