W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

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

From: Jon Gunderson <jongund@uiuc.edu>
Date: Mon, 01 Nov 1999 09:33:42 -0800
Message-Id: <4.2.0.58.19991101092311.00ae4100@staff.uiuc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT