Re: Accessible States for Buttons



Hi Padraig,

> 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...


Peter Korn
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
> 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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]