Re: Accessible States for Buttons

["Padraig O'Briain" <Padraig Obriain sun com>]

GTK does have a state which, to my mind, corresponds to ARMED, i.e. 
GTK_STATE_ACTIVE. A GailButton will be in this state while the left mouse button 
is pressed and the mouse is over the button. If the mouse is moved away from the 
button the GailButton will no longer be in the state ARMED.

Currently, a GailButton is never in the state PRESSED. Is there a perceived need 
for a GailButton to pass through the state PRESSED when the left mouse button is 
released when the mouse is over a button?

Padraig

> X-Accept-Language: en
> MIME-Version: 1.0
> To: "Padraig O'Briain" <Padraig Obriain sun com>
> CC: gnome-accessibility-list gnome org
> Subject: Re: Accessible States for Buttons
> Content-Transfer-Encoding: 7bit
> 
> Hi Padraig,
> 
> > I am trying to make sense of the states which we have defined in ATK 
> > which relate to buttons. Most of these states correspond to Java 
> > AccessibleState values.
> > 
> > I summarize here my understanding of what the Java states mean; I would
> > appreciate it if you could correct any misunderstandings on my part or 
> > point me at some documentation which covers this.
> > 
> > ARMED
> > =====
> > The left mouse button has been pressed while the mouse is inside the
> > button.
> 
> Yes, this is correct.  The button hasn't yet been pressed.  To really see 
this,
> move your mouse over a Swing button, depress the left mouse button, then, with
> the button still depressed, move the mouse off of the button and then release
> the mouse button.  The button will not have been "PRESSED", as the mouse 
wasn't
> released (after being pressed) on the button.  This allows a user to get 
visual
> feedback of the button depress, realize it's not the button they wanted to
> click, move off, and then not finish the operation - effectively aborting it
> partway through.
> 
> I think most assistive technologies will not see this state, as in most cases 
a
> user with a disability will not have the computer be in this intermediate
> state.  If GNOME doesn't define such a state, then it may not need to be in 
ATK
> (though it should be in the AT SPI).
> 
> > CHECKED
> > =======
> > This is used to indicate that a radio button or check box has been
> > selected.
> 
> "Has been", or better still, simply "is".  Some check boxes appear on the
> screen already checked, with no action done by the user.
> 
> > ENABLED
> > =======
> > This state means that the button can be selected by the mouse.
> > The converse of enabled seems to be similar to the Gtk concept of a 
> > toggle button being inconsistent.
> 
> Hmmm... I'm not sure about this similarity.  Enabled means that the button is
> manipulable (a "disabled" button - horrible term - is typically "greyed-out" 
on
> the screen, and a user cannot manipulate it).  If I'm guessing at your meaning
> of "inconsistent" above, I'd think it applies to those "tri-state" buttons - 
as
> in where you have a toggle button for "bold" and a run of text selected that
> contains both bold and not-bold text.
> 
> > PRESSED
> > =======
> > The left mouse button has been released while the mouse is inside the
> > hutton.
> 
> Yes.  This means that the button has been activated.  Of course, once pressed,
> it is immediately unpressed (since the releasing of a mouse button is an
> immediate and irreversable action, vs. the clicking/"ARMING" above), and so 
the
> state won't remain Pressed for long...
> 
> > I know that the documentation uses the phrase "Indicates this object is
> > currently pressed." but based on the documentation for DefaultButtonModel
> > it looks like this state means that the button has been pressed rather
> > than that it is pressed.
> > 
> > Is this state a transient state?
> 
> Yes.
> 
> 
> Peter Korn
> Sun Accessibility team