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

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

Received on Sunday, 31 October 1999 09:02:38 UTC