Re: Mouse Wheel event for SVG 1.1

DaveP wrote:
> And what of non mouse users?
> Is this functionality to be denied them?
> Rather too device specific for my liking.
> What's the more abstract functionality you are proposing?
>  Then perhaps we could look for alternatives that might
>  be mapped to other devices without scrolling mice.

Unless you were intentionally trying to limit the audience to your site or
application to only those people who have a mouse with a wheel, you would
not use a mouse wheel action as the only way to perform a manipulation.

For example, if I was using mouse wheel movement to rotate an object, I
could also provide an equivalent keystroke, mouse gesture, a button and an
accessibility hint.

However, each content or application developer should be free to assign a
different action to the mouse wheel.  In one application, it might be
zoomin, another rotation, another changing animation speed, another changing
volume.

I think we discussed a couple of months ago on the www-dom mailing list in
regards to enumerating event listeners in DOM 3 events.  My personal thought
was that content should be able to describe manipulations in a manner that
could be used by accessibility tools, instead of depending on the
accessibility tools trying to infer abstract actions by code examination.

In the very reasonable example of providing multiple ways to rotate an
object, it would have to be a incredibly smart piece of coding that could
examine the attached listeners (which could have been coded in any number of
scripting or compiled languages) and determine that moving the mouse wheel
forward, hitting the L key, clicking on <text>Rotate Left</text> and
clicking on a icon for left rotation, all do the same thing in this
particular application and could be presented by the accessibility tool as a
one abstract action.

It seems much more reasonable to enable application and content providers
mechanisms to declare the abstract actions possible in a graphic or web page
in addition to allowing them to listen to device specific events.

For example, on the rotation manipulation, you could have an <action> or
equivalent tag embedded in the content.

<svg xmlns="http://www.w3.org/2000/svg">
   <script type="text/ecmascript">
        var somerect = document.getElementById("somerect");
       somerect.addEventListener("keydown", rotateByKey, false);
       somerect.addEventListener("mousewheel", rotateByWheel, false);
       var somerectaction = document.getElementById("rotaterect");
       somerectaction.addEventListener("activate", rotateByAction,  false);
   </script>
   <rect x="100" y="100" width="100" height="100" id="somerect">
        <!--  a description of a action available,
               an accessibility tool could examine the DOM for enabled
               actions, present it to the user in an appropriate manner and
               then fire an appropriate event to the action    -->
        <wai:action id="somerectaction" enabled="true"
xmlns:wai="http://www.w3.org/2002/wai-actions">
             <wai:description lang="en">Rotate Left</description>
             <wai:description lang="fr">Tournez À gauche</description>
        </wai:action>
    </rect>
</svg>

Since SVG (and XHTML?), already allows elements from other namespaces to
appear as metadata within content.  It would require no modification of the
SVG spec to allow accessible SVG content.  What is necessary is a consistent
manner to describe actions that may be performed.

Received on Thursday, 18 April 2002 11:03:54 UTC