RE: onmouseover, onfocus, onclick

The point is that the popup menu constitutes an incremental and localized
expansion of the business at hand in the dynamic page.  By embedding action in
expanding and collapsing components, more context can be stably preserved for
all the action.  This is a virtue.

The problem is the same one that I posed to Jimmy about scripts in general: 
Have we captured a sufficiently stable concept of the overall lay of the land
within which these local variations take place?  The eyes-free user is
probably
better off with more interactive transactions.  That is to say
opening/entering
the submenu is less automatic, more volitional and requiring a discrete
request
in the sound+keyboard user environment.  But the structure of the content is
the same, and is usable in either way.  There is a tree or fiber space
structure where there are minimized and expanded states of the submenu, the
minimized form explains the general nature of the business handled in the
expanded form.  The surrounding fabric relates the business of this
fragment to
the larger frame of business represented by the page and site and Web in the
large.   All this is amenable to schematization and comprehensible
structure-walking through any business the user wishes to conduct on the
page. 
Including touring it all or drilling rapidly to a key bit and just doing it.

It does require that the content of all transient states be integrated into a
common virtual graph, and not hidden in opaque imperative language.  But it's
all doable in a univerally accessible fashion without giving up the functional
gains of the dynamic-page medium.

But the factorization of content into static content in HTML and dynamic
content lost in script is a serious barrier to making it work.   [$.02]

Al

At 09:52 AM 2001-02-16 +0000, Jon Hanna wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>> > Ideally I would trigger menu appearance or disappearance from
>> > onclick. Since onclick events occur when a focused item is
>> > selected
>>
>> No.  Ideally, if popup menus are essential to successful web
>> navigation, rather than a way of showing off, you should campaign
>> for a popup menu style, that could be applied to lists, in the next
>> version of CSS.
>
>Yes, <menu> and <dir> are now deprecated, but could with some better
>rendering have been very useful in these cases. I was talking from
>the point of view of how people designing web pages should deal with
>the task of producing popup menus, and from that point of view a new
>popup menu style would probably make things get worse before they get
>better, but in the long term be great from the point of view of both
>being able to make accessible pages, and code popup menus more
>easily.
>
>Something like the following would be great:
>
><menu style="menu-style: shown;">
> <li id="cat1">Category 1
>  <menu style="menu-style: popup;" parent="cat1">
>   <li>Subcategory 1</li>
>   <li>Subcategory 2</li>
>  </menu>
> </li>
></menu>
>
>As to whether popup menus are necessary or not, I don't think they
>are ever completely necessary, but when used well they can increase
>usability and therefore accessibility in it's widest sense - that is
>it makes a site more usable to a group of users. However while there
>are problems with them being accessed by some other groups -
>including those groups which are the main focus of this list, and
>since I don't think any group would find the alternatives impossible
>to use I would avoid them.
>
>Unfortunately for those of us who earn a living my writing web
>pages/sites/applications pop up menus are impressive to clients, and
>also likely to increase the ease-of-use for those clients (hence to
>their mind you have made the site better in practical as well as
>aesthetic terms). There are quite a few of us who work to make our
>sites accessible as an additional requirement that we personally add
>to the spec we get from our clients. For those of us in this position
>finding a way to make popup menus today, with current technology,
>accessible is our only option.
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 6.5.1 Int. for non-commercial use
><<http://www.pgpinternational.com%3E%3E%3Eiqa/>http://www.pgpinternational.
com>
>
>iQA/AwUBOoz4XdlYbmO7kSNQEQLl6ACguM89fJHl7r39KFlq829URCqV0wkAoJjF
>K8ISDamN9c1xIMdE2dWK7kxB
>=YKv3
>-----END PGP SIGNATURE-----
>

Received on Friday, 16 February 2001 11:15:36 UTC