Re: Accessible States for Buttons
- From: Peter Korn <peter korn sun com>
- To: gnome-accessibility-list gnome org
- Subject: Re: Accessible States for Buttons
- Date: Wed, 25 Jul 2001 16:40:34 -0700
> 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?
I could envision test tools, and products that give non-visual feedback, making
use of that information. I'm not aware of any critical need for any particular
disability use cases, but I could be missing something...
Sun Accessibiltiy team
> > 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
> > 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
> > released (after being pressed) on the button. This allows a user to get
> > 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
> > 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
> > (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"
> > 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 -
> > 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
> > 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
] [Thread Prev