Minefield and menus

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

Minefield and menus

sbq
Greetings,
 
Is this the right place to ask questions about Minefield accessibility?
 
My goal is to set up AT-SPI event handlers so a user can click on menus
and the event handlers can figure out what menu item was clicked.  I
have tried everything I can think of and had no luck.
 
Currently I listen for the event "Gtk:GtkWidget:button-press-event"
which has let me accomplish this goal for all apps I've tried, including
Firefox.  For Minefield the source field of the AccessibleEvent object
passed into the handler is not useful.  It has no parent.  It's roleName
is "redundant object".
 
As my test case I click on Minefield's "Help" which brings up the Help
menu.  Then I click on "About Minefield".  It is this click that my
handler receives, but is unable to figure out that "About Minefield" was
clicked.  I have code using AccessibleComponent_getAccessibleAtPoint()
to find the GUI item at the mouse, but it doesn't see the menu item,
only the web page underneath the menu.  I should mention that the
initial click on "Help" in the main menu also results in my handler
getting called.  In this case AccessibleComponent_getAccessibleAtPoint()
takes me right the the "Help" Menu.  So the problem seems limited to
popup menus.
 
Any help is welcome.
 
-Sam
 
PS: I understand that Minefield is "not a final ore pre-release
version".
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Minefield and menus

David Bolter
Hi Sam,

This is a great place to ask these questions and thanks for bringing
this to our attention.  Is this the same issue captured by your bmo bug
480313?

Maybe you can help us find the regression range for this. What version
of FF worked for you? Do you recall approximately when it stopped
working in Minefield?

cheers,
David


Quiring, Sam wrote:

> Greetings,
>  
> Is this the right place to ask questions about Minefield accessibility?
>  
> My goal is to set up AT-SPI event handlers so a user can click on menus
> and the event handlers can figure out what menu item was clicked.  I
> have tried everything I can think of and had no luck.
>  
> Currently I listen for the event "Gtk:GtkWidget:button-press-event"
> which has let me accomplish this goal for all apps I've tried, including
> Firefox.  For Minefield the source field of the AccessibleEvent object
> passed into the handler is not useful.  It has no parent.  It's roleName
> is "redundant object".
>  
> As my test case I click on Minefield's "Help" which brings up the Help
> menu.  Then I click on "About Minefield".  It is this click that my
> handler receives, but is unable to figure out that "About Minefield" was
> clicked.  I have code using AccessibleComponent_getAccessibleAtPoint()
> to find the GUI item at the mouse, but it doesn't see the menu item,
> only the web page underneath the menu.  I should mention that the
> initial click on "Help" in the main menu also results in my handler
> getting called.  In this case AccessibleComponent_getAccessibleAtPoint()
> takes me right the the "Help" Menu.  So the problem seems limited to
> popup menus.
>  
> Any help is welcome.
>  
> -Sam
>  
> PS: I understand that Minefield is "not a final ore pre-release
> version".
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>  

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

RE: Minefield and menus

sbq
Hi David,

No, it is not the same as 480313.  It is the same as 480347, although I
think I worded it more clearly here.

I just started working with Minefield 2 or 3 days ago, so it has never
worked for me.

In order to answer your question about FF, I just downloaded 3.0.6.  Now
comes the embarrassing part for me.  It doesn't work in FF 3.0.6.  So I
tried it "again" on FF 3.0.1, the version I've been using for a few
months on Linux.  It doesn't work there either.  So when I said below it
worked in Firefox, I was wrong (I put quoted "again" because it is
likely I never really tried it before).

Fearing that my accessible application had developed some bugs, I tried
clicking on menus on some other apps - Terminal, Galculator, Thunar, the
desktop itself, and my own gtk_helloWorld app.  It was able to correctly
detect the menu items there.

I posted bug 480347 because I believe Minefield's (and FF's)
implementation of AccessibleComponent_getAccessibleAtPoint() is not
correct if a Menu pop-up is being displayed.  I believe that Minefield
and FF have their own implementation of AT-SPI (not dependent on Gtk+),
so I posted here in hopes that someone would say "You are trying to do
it the wrong way, here is how we handle menu item mouse-click events in
Firefox..."

-Sam

-----Original Message-----
From: david bolter [mailto:[hidden email]] On Behalf Of David
Bolter
Sent: Thursday, February 26, 2009 12:45 PM
To: Quiring, Sam
Cc: [hidden email]
Subject: Re: Minefield and menus

Hi Sam,

This is a great place to ask these questions and thanks for bringing
this to our attention.  Is this the same issue captured by your bmo bug
480313?

Maybe you can help us find the regression range for this. What version
of FF worked for you? Do you recall approximately when it stopped
working in Minefield?

cheers,
David


Quiring, Sam wrote:
> Greetings,
>  
> Is this the right place to ask questions about Minefield
accessibility?

>  
> My goal is to set up AT-SPI event handlers so a user can click on
> menus and the event handlers can figure out what menu item was
> clicked.  I have tried everything I can think of and had no luck.
>  
> Currently I listen for the event "Gtk:GtkWidget:button-press-event"
> which has let me accomplish this goal for all apps I've tried,
> including Firefox.  For Minefield the source field of the
> AccessibleEvent object passed into the handler is not useful.  It has
> no parent.  It's roleName is "redundant object".
>  
> As my test case I click on Minefield's "Help" which brings up the Help

> menu.  Then I click on "About Minefield".  It is this click that my
> handler receives, but is unable to figure out that "About Minefield"
> was clicked.  I have code using
> AccessibleComponent_getAccessibleAtPoint()
> to find the GUI item at the mouse, but it doesn't see the menu item,
> only the web page underneath the menu.  I should mention that the
> initial click on "Help" in the main menu also results in my handler
> getting called.  In this case
> AccessibleComponent_getAccessibleAtPoint()
> takes me right the the "Help" Menu.  So the problem seems limited to
> popup menus.
>  
> Any help is welcome.
>  
> -Sam
>  
> PS: I understand that Minefield is "not a final ore pre-release
> version".
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>  

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

Re: Minefield and menus

David Bolter
Hi Sam,

I'm glad you are finding bugs, well, you know what I mean. Let's
continue the conversation in the related bug reports. Thanks for finding
and filing them.

cheers,
David

Quiring, Sam wrote:

> Hi David,
>
> No, it is not the same as 480313.  It is the same as 480347, although I
> think I worded it more clearly here.
>
> I just started working with Minefield 2 or 3 days ago, so it has never
> worked for me.
>
> In order to answer your question about FF, I just downloaded 3.0.6.  Now
> comes the embarrassing part for me.  It doesn't work in FF 3.0.6.  So I
> tried it "again" on FF 3.0.1, the version I've been using for a few
> months on Linux.  It doesn't work there either.  So when I said below it
> worked in Firefox, I was wrong (I put quoted "again" because it is
> likely I never really tried it before).
>
> Fearing that my accessible application had developed some bugs, I tried
> clicking on menus on some other apps - Terminal, Galculator, Thunar, the
> desktop itself, and my own gtk_helloWorld app.  It was able to correctly
> detect the menu items there.
>
> I posted bug 480347 because I believe Minefield's (and FF's)
> implementation of AccessibleComponent_getAccessibleAtPoint() is not
> correct if a Menu pop-up is being displayed.  I believe that Minefield
> and FF have their own implementation of AT-SPI (not dependent on Gtk+),
> so I posted here in hopes that someone would say "You are trying to do
> it the wrong way, here is how we handle menu item mouse-click events in
> Firefox..."
>
> -Sam
>
> -----Original Message-----
> From: david bolter [mailto:[hidden email]] On Behalf Of David
> Bolter
> Sent: Thursday, February 26, 2009 12:45 PM
> To: Quiring, Sam
> Cc: [hidden email]
> Subject: Re: Minefield and menus
>
> Hi Sam,
>
> This is a great place to ask these questions and thanks for bringing
> this to our attention.  Is this the same issue captured by your bmo bug
> 480313?
>
> Maybe you can help us find the regression range for this. What version
> of FF worked for you? Do you recall approximately when it stopped
> working in Minefield?
>
> cheers,
> David
>
>
> Quiring, Sam wrote:
>  
>> Greetings,
>>  
>> Is this the right place to ask questions about Minefield
>>    
> accessibility?
>  
>>  
>> My goal is to set up AT-SPI event handlers so a user can click on
>> menus and the event handlers can figure out what menu item was
>> clicked.  I have tried everything I can think of and had no luck.
>>  
>> Currently I listen for the event "Gtk:GtkWidget:button-press-event"
>> which has let me accomplish this goal for all apps I've tried,
>> including Firefox.  For Minefield the source field of the
>> AccessibleEvent object passed into the handler is not useful.  It has
>> no parent.  It's roleName is "redundant object".
>>  
>> As my test case I click on Minefield's "Help" which brings up the Help
>>    
>
>  
>> menu.  Then I click on "About Minefield".  It is this click that my
>> handler receives, but is unable to figure out that "About Minefield"
>> was clicked.  I have code using
>> AccessibleComponent_getAccessibleAtPoint()
>> to find the GUI item at the mouse, but it doesn't see the menu item,
>> only the web page underneath the menu.  I should mention that the
>> initial click on "Help" in the main menu also results in my handler
>> getting called.  In this case
>> AccessibleComponent_getAccessibleAtPoint()
>> takes me right the the "Help" Menu.  So the problem seems limited to
>> popup menus.
>>  
>> Any help is welcome.
>>  
>> -Sam
>>  
>> PS: I understand that Minefield is "not a final ore pre-release
>> version".
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>>  
>>    
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>  

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

Re: Minefield and menus

Steve Lee-3
In reply to this post by sbq
2009/2/26 Quiring, Sam <[hidden email]>:
> Fearing that my accessible application had developed some bugs, I tried
> clicking on menus on some other apps - Terminal, Galculator, Thunar, the
> desktop itself, and my own gtk_helloWorld app.  It was able to correctly
> detect the menu items there.

I've not tried in 3.0.1 but certainly Jambu Mozilla menu code broke
around 3.0.1 and I never resolved it completely. Gail and Mozilla
needed different handling and the next version of Jambu is intended to
handle Toolkit and Application specifics (probably using polymorphism
and observers). I think Eitan worked on adding something similar to
Orca. Eitan suggested using GAIL as the reference but even that is 'as
it' and not specified any place I could find.

Menus and window popups is an area I spent a painful age on and is
certainly a great place to work on improving. It's partly gaps in the
AT-SPI spec and partly the Moz code has not been exercised much in
specific ways as current ATS are largely focus tracking and not
responding to actions. The dynamic behaviour including events and
updates to the hierarchy are not defined and I found not deterministic
(or I didn't work out all the variables).

It will be a great service to Mozilla accessibility if you feel
inspired to find bugs and report them and work with the crew, as you
are doing.

> I believe that Minefield
> and FF have their own implementation of AT-SPI (not dependent on Gtk+),

Correct, it's all in core (Gecko), largely as Mozilla don't use GTK,
but looks similar.
GTK has GAIL that provides accessibility for stock GTK widgets. Custom
or derived widgets must be completed by the widget developers.

Cheers

Steve Lee
Open Source Assistive Technology Software and Accessibility
fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
sbq
Reply | Threaded
Open this post in threaded view
|

RE: Minefield and menus

sbq
 
= Menus and window popups is an area I spent a painful age on
= and is certainly a great place to work on improving. It's
= partly gaps in the AT-SPI spec and partly the Moz code has
= not been exercised much in specific ways as current ATS are
= largely focus tracking and not responding to actions. The
= dynamic behaviour including events and updates to the
= hierarchy are not defined and I found not deterministic (or
= I didn't work out all the variables).

When you refer to "the AT-SPI spec" what exactly do you mean?  Can you point to a document?

I have been trying for months to build a system that reliably tracks the user's GUI actions.  Figuring out what item the user clicks has proven quite difficult.  There's no AT-SPI document that says "when you get the event x:y:z the source object is what the user just clicked."

Back in December I found an email exchange from an archive of this list, where someone else was having my exact problem, http://archive.netbsd.se/?ml=mozilla-dev-accessibility&a=2008-05&t=7363495(mozilla-dev-accessibility).  One of the responses was from Nagappan where he said:

= As per my experience with at-cspi, only this "Gtk:GtkWidget:button-press-event" gives appropriate event.

This was a revelation to me.  [My first question was "where should I have looked to discover that this event exists?"].  The event occurs very quickly after the button press and delivers the GUI object on which the mouse was clicked.  It is way more reliable than any other event or event sequence I had tried up to that point.  It has two drawbacks.  the first is that the event happens many times - you have to ignore it all but the first time.  You can see this filtering in LDTP.  I believe I saw a bug report that Nagappan filed against AT-SPI asking why this event is delivered so many times?

The second drawback is if the user presses the mouse key on an object, then moves the mouse off, then releases the mouse key, the GUI does not consider the object to be selected (i.e., it is not clicked).  However, the "Gtk:GtkWidget:button-press-event" is delivered.

I do not understand why AT-SPI did not define the event: "gui-item-clicked: delivered when the user clicks(i.e., press-release) on a gui item".  The GUI knows when a user has clicked an item -- it has to deliver an event.  It could, at the same time, deliver an event to AT-SPI.  Then accessibility programs could accurately track user actions with one event handler.

The lack of an AT-SPI spec saying explicitly "when the user clicks a GUI item the x:y:z event must be delivered with source set to the GUI item just clicked" means that each implementation of the AT-SPI interface can be different.  The consequence is that accessibility applications must implement a different event tracking model for each implementation of the AT-SPI.  I'm aware of 3 AT-SPI implementations: Gtk+, Mozilla Firefox and Minefield, and Java.  I've dealt with the first two and accurately tracking the user clicking on GUI items appears to be a place where my code will have to say "do this unless the application is Firefox then do that."

-Sam


-----Original Message-----
From: Steve Lee [mailto:[hidden email]]
Sent: Friday, February 27, 2009 2:26 AM
To: Quiring, Sam
Cc: David Bolter; [hidden email]
Subject: Re: Minefield and menus

2009/2/26 Quiring, Sam <[hidden email]>:
> Fearing that my accessible application had developed some bugs, I
> tried clicking on menus on some other apps - Terminal, Galculator,
> Thunar, the desktop itself, and my own gtk_helloWorld app.  It was
> able to correctly detect the menu items there.

I've not tried in 3.0.1 but certainly Jambu Mozilla menu code broke around 3.0.1 and I never resolved it completely. Gail and Mozilla needed different handling and the next version of Jambu is intended to handle Toolkit and Application specifics (probably using polymorphism and observers). I think Eitan worked on adding something similar to Orca. Eitan suggested using GAIL as the reference but even that is 'as it' and not specified any place I could find.

Menus and window popups is an area I spent a painful age on and is certainly a great place to work on improving. It's partly gaps in the AT-SPI spec and partly the Moz code has not been exercised much in specific ways as current ATS are largely focus tracking and not responding to actions. The dynamic behaviour including events and updates to the hierarchy are not defined and I found not deterministic (or I didn't work out all the variables).

It will be a great service to Mozilla accessibility if you feel inspired to find bugs and report them and work with the crew, as you are doing.

> I believe that Minefield
> and FF have their own implementation of AT-SPI (not dependent on
>Gtk+),

Correct, it's all in core (Gecko), largely as Mozilla don't use GTK, but looks similar.
GTK has GAIL that provides accessibility for stock GTK widgets. Custom or derived widgets must be completed by the widget developers.

Cheers

Steve Lee
Open Source Assistive Technology Software and Accessibility fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Minefield and menus

Steve Lee-3
2009/2/27 Quiring, Sam <[hidden email]>:

> When you refer to "the AT-SPI spec" what exactly do you mean?  Can you point to a document?

nope, just Bill's docgen web pages which document the structure only,
not dynamic behaviour as you also found. Some basic UML would work
wonders. Even the isolated events are poorly defined, let alone
sequences.

Please if anyone knows otherwise let us know.

> This was a revelation to me.  [My first question was "where should I have looked to discover that this event exists?"].

You have to use accerciser and monitor the events - i.e suck it and
see. That's hard with so many and working out when they started in
relation to your action. So I patched it to time stamp the event log
(submitted to accerciser) as that gives some clues.

I also created various little programs using pyatspi to monitor
specific situations and log. There's a version here
http://www.oatsoft.org/trac/jambu/browser/trunk/src/atspi.py
However looking at it it now it doesn't seem to be async so printing
may cause problems. Compare with main() in
http://www.oatsoft.org/trac/jambu/browser/trunk/src/lib/jambu/InAppSelection.py

> The lack of an AT-SPI spec saying explicitly "when the user clicks a GUI item the x:y:z event must be delivered with source set to the GUI item just clicked" means that each implementation of the AT-SPI interface can be different.  The consequence is that accessibility applications must implement a different event tracking model for each implementation of the AT-SPI.  I'm aware of 3 AT-SPI implementations: Gtk+, Mozilla Firefox and Minefield, and Java.  I've dealt with the first two and accurately tracking the user clicking on GUI items appears to be a place where my code will have to say "do this unless the application is Firefox then do that."

Quite as I found in Jambu and lack of a reference is something that I
think has been discussed before (David?)
It seems you are in a good position to define what the behaviour
should be and raise bugs in an attempt to sort this out. I'm sure
others would help you as this is important work

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

Re: Minefield and menus

David Bolter
In reply to this post by sbq
Sorry for massive deletion... just a quick drive-by comment:
> The second drawback is if the user presses the mouse key on an object, then moves the mouse off, then releases the mouse key, the GUI does not consider the object to be selected (i.e., it is not clicked).  However, the "Gtk:GtkWidget:button-press-event" is delivered.

I think you also tried button-release-event, correct -- but same problem
IIRC. I agree a clicked event is a good idea, did that suggestion go
anywhere?

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

Re: Minefield and menus

Willie Walker
In reply to this post by Steve Lee-3
Steve Lee wrote:

> 2009/2/27 Quiring, Sam <[hidden email]>:
>
>> When you refer to "the AT-SPI spec" what exactly do you mean?  Can you point to a document?
>
> nope, just Bill's docgen web pages which document the structure only,
> not dynamic behaviour as you also found. Some basic UML would work
> wonders. Even the isolated events are poorly defined, let alone
> sequences.
>
> Please if anyone knows otherwise let us know.

The types of events and event ordering has always unfortunately been a
very poorly spec'd thing in any a11y API I've seen.  :-(  As Steve
mentions, it's a "suck it and see" situation.

>> This was a revelation to me.  [My first question was "where should I have looked to discover that this event exists?"].
>
> You have to use accerciser and monitor the events - i.e suck it and
> see. That's hard with so many and working out when they started in
> relation to your action. So I patched it to time stamp the event log
> (submitted to accerciser) as that gives some clues.

Yep - accerciser is one of the better ways to do this.  Writing your own
simple pyatspi-based solution is easy to do as well.

>> The lack of an AT-SPI spec saying explicitly "when the user clicks a GUI item the x:y:z event must be delivered with source set to the GUI item just clicked" means that each implementation of the AT-SPI interface can be different.  The consequence is that accessibility applications must implement a different event tracking model for each implementation of the AT-SPI.  I'm aware of 3 AT-SPI implementations: Gtk+, Mozilla Firefox and Minefield, and Java.  I've dealt with the first two and accurately tracking the user clicking on GUI items appears to be a place where my code will have to say "do this unless the application is Firefox then do that."

Yep.  It blows.  No arguing with that.  If you want a brief reason for
why this is the case, the problem stems from the fact that GUI toolkits
themselves choose to do things differently, such as event ordering and
a11y hierarchy relationships (e.g., tabs and their tab panes).  As such,
it's hard/impossible to normalize their behavior to a single API.

In the majority of cases, however, things are done the same across
toolkits.  You do, however, tend to need to look at each toolkit as a
whole new learning experience in how one might interpret a spec.

Will

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

RE: Minefield and menus

sbq
>> The lack of an AT-SPI spec saying explicitly "when the user clicks a
GUI item the x:y:z event must be delivered with source set to the GUI
item just clicked" means that each implementation of the AT-SPI
interface can be different.

=Yep.  It blows.  No arguing with that.  If you want a brief reason for
why this is the case, the problem stems from the fact that GUI toolkits
themselves choose to do things differently, such as event ordering and
a11y hierarchy relationships (e.g., tabs and their tab panes).  As such,
it's hard/impossible to normalize their behavior to a single API.

I don't buy this for the specific case of "the user clicked on this GUI
Item."  The GUI determines when the criteria "the user clicked on this
item" are met and when it will deliver click events to handlers.  If the
AT-SPI API had a required event "user has clicked a GUI item", then the
GUI could be [re-]structured to deliver that event and the associated
item to the AT-SPI interface at the same time it is delivered to the GUI
handler.

I do not believe it is the right tradeoff to make each accessible
application (that needs to track events) figure out all the special
cases of event orderings for each AT-SPI implementation, when it could
have been handled correctly, once and for all, in the implementation of
the API itself.

-Sam


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, February 27, 2009 11:31 AM
To: Steve Lee
Cc: Quiring, Sam; [hidden email]; David Bolter
Subject: Re: Minefield and menus

Steve Lee wrote:
> 2009/2/27 Quiring, Sam <[hidden email]>:
>
>> When you refer to "the AT-SPI spec" what exactly do you mean?  Can
you point to a document?
>
> nope, just Bill's docgen web pages which document the structure only,
> not dynamic behaviour as you also found. Some basic UML would work
> wonders. Even the isolated events are poorly defined, let alone
> sequences.
>
> Please if anyone knows otherwise let us know.

The types of events and event ordering has always unfortunately been a
very poorly spec'd thing in any a11y API I've seen.  :-(  As Steve
mentions, it's a "suck it and see" situation.

>> This was a revelation to me.  [My first question was "where should I
have looked to discover that this event exists?"].
>
> You have to use accerciser and monitor the events - i.e suck it and
> see. That's hard with so many and working out when they started in
> relation to your action. So I patched it to time stamp the event log
> (submitted to accerciser) as that gives some clues.

Yep - accerciser is one of the better ways to do this.  Writing your own
simple pyatspi-based solution is easy to do as well.

>> The lack of an AT-SPI spec saying explicitly "when the user clicks a
GUI item the x:y:z event must be delivered with source set to the GUI
item just clicked" means that each implementation of the AT-SPI
interface can be different.  The consequence is that accessibility
applications must implement a different event tracking model for each
implementation of the AT-SPI.  I'm aware of 3 AT-SPI implementations:
Gtk+, Mozilla Firefox and Minefield, and Java.  I've dealt with the
first two and accurately tracking the user clicking on GUI items appears
to be a place where my code will have to say "do this unless the
application is Firefox then do that."

Yep.  It blows.  No arguing with that.  If you want a brief reason for
why this is the case, the problem stems from the fact that GUI toolkits
themselves choose to do things differently, such as event ordering and
a11y hierarchy relationships (e.g., tabs and their tab panes).  As such,
it's hard/impossible to normalize their behavior to a single API.

In the majority of cases, however, things are done the same across
toolkits.  You do, however, tend to need to look at each toolkit as a
whole new learning experience in how one might interpret a spec.

Will

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

RE: Minefield and menus

sbq
In reply to this post by David Bolter
= I think you also tried button-release-event, correct -- but same
problem IIRC.
= I agree a clicked event is a good idea, did that suggestion go
anywhere?

Correct.  I just made the suggestion yesterday (Bug 573474).  We'll see.

-Sam

-----Original Message-----
From: david bolter [mailto:[hidden email]] On Behalf Of David
Bolter
Sent: Friday, February 27, 2009 10:52 AM
To: Quiring, Sam
Cc: Steve Lee; [hidden email]
Subject: Re: Minefield and menus

Sorry for massive deletion... just a quick drive-by comment:
> The second drawback is if the user presses the mouse key on an object,
then moves the mouse off, then releases the mouse key, the GUI does not
consider the object to be selected (i.e., it is not clicked).  However,
the "Gtk:GtkWidget:button-press-event" is delivered.

I think you also tried button-release-event, correct -- but same problem
IIRC. I agree a clicked event is a good idea, did that suggestion go
anywhere?

cheers,
David
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility