How accessibility handles events

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How accessibility handles events

Aaron Leventhal-3
Alexander Surkov wrote:

>  If 3d party software wants to get a accessibility for focused element and focus is on xul:textbox then for what element will be accessibility object returned? If accessibility object will be for xul:textbox then where in the code is it defined? I have my doubts regarding what element an accessibility object will be returned because xul:textbox is based on html:input[type="text"] and html:input[type="text"] will have focus if xul:textbox is focused.

XUL textboxes do act funny with respect to focus events. However, the
screen readers don't listen to DOM events directly. They listen to
Windows MSAA focus events.

We generate the MSAA events after creating an nsAccessible that
corresponds to the DOM node for the event. In this case we need to
create an nsXULTextboxAccessible, or reuse one that's already been
created for that DOM node (we cache the accessibles we create lazily).

However, as you said when we get a focus event for a XUL textbox we
actually get a focus event for its hidden HTML input child where all the
real work is done. This is an ugly implementation detail.

The DOM events come into the accessibility module at
nsRootAccessible::HandleEvent(), which uses
nsRootAccessible::GetTargetNode() to get the DOM node that the
accessible should be created for.

The code after the following lines is what makes sure we get the XUL
textbox node instead of using the HTML node.
       // Use binding parent when the event occurs in
       // anonymous HTML content.
Basically, if we see we're in HTML but we have a "binding parent" we
decide that the binding parent is more important.

void nsRootAccessible::GetTargetNode(nsIDOMEvent *aEvent, nsIDOMNode
**aTargetNode)
{
   *aTargetNode = nsnull;

   nsCOMPtr<nsIDOMNSEvent> nsevent(do_QueryInterface(aEvent));

   if (nsevent) {
     nsCOMPtr<nsIDOMEventTarget> domEventTarget;
     nsevent->GetOriginalTarget(getter_AddRefs(domEventTarget));
     nsCOMPtr<nsIContent> content(do_QueryInterface(domEventTarget));
     nsIContent *bindingParent;
     if (content && content->IsContentOfType(nsIContent::eHTML) &&
       (bindingParent = content->GetBindingParent()) != nsnull) {
       // Use binding parent when the event occurs in
       // anonymous HTML content.
       // This gets the following important cases correct:
       // 1. Inserted <dialog> buttons like OK, Cancel, Help.
       // 2. XUL menulists and comboboxes.
       // 3. The focused radio button in a group.
       CallQueryInterface(bindingParent, aTargetNode);
       NS_ASSERTION(*aTargetNode, "No target node for binding parent of
anonymous event target");
       return;
     }
     if (domEventTarget) {
       CallQueryInterface(domEventTarget, aTargetNode);
     }
   }
}

The terms "binding", "binding parent" and "anonymous content" all relate
to content which does not show up in the DOM tree unless you
specifically look for it. Widgets defined in XBL (Extensible Binding
Language) can define a <content> section which is kind of used like an
#include or global replace every time that widget is used. A simple
example might be a definition of a <3dbutton> which could define itself
using 9 anonymous content images. A XUL textbox uses an HTML input as an
anonymous content child, which is a bit unfortunate but was apparently
the easiest way to do it. The "binding parent" for the anonymous child
is the DOM node which spawned it.


- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: How accessibility handles events

Alexander Surkov
Why don't you use just a explicitOriginalTarget? Do you want to be sure
that found binding is not top most?

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: How accessibility handles events

Aaron Leventhal-3
It's not clear from the IDL what the difference is between that and
originalTarget:
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/events/nsIDOMNSEvent.idl

What do you mean by "Do you want to be sure that found binding is not
top most?"

At the moment we're not having any problems with that piece of code. I
know that I experimented with explicitOriginalTarget but I don't
remember exactly why it didn't keep using it. Can you explain what it does?

- Aaron

[hidden email] wrote:
> Why don't you use just a explicitOriginalTarget? Do you want to be sure
> that found binding is not top most?
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility