jturpin

Pressing the space bar while a button is focused fires the "click" event on a button - however the "enter" key does not - thats a bummer. This seems to go against most accesibility practices. Is there a quick/easy way to adding this behavior other than subclassing the Button control and handling (rerouting) key events

I also found an interesting issue (I am considering it a bug - but I am sure msft has a reason for the behavior)...

Whenever a "click" event fires for a button- say by pressing the space bar while a button is focused - which I had to do because "enter" doesn't work Wink - also seems to trigger a MouseEnterEvent (even though the mouse never moved) - and in my case I have routed MouseEnterEvents to Focus() the element which fired the MouseEnterEvent - which jumps the focus to whatever element is under the mouse - even though the user didn't intend to move the focus.

Any way to prevent the Click event from re-firing MouseEnterEvents and what is the reason for Click events retriggering MouseEnterEvents in the first place

thanks,

-j



Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

jturpin

Ok - this is turning into a bigger issue than I previously thought - as I seem unable to programmatically trigger the Click event.

Seems like this should work, right I am I missing something simple

Code Snippet

class ButtonControl : Button
{
public ButtonControl()
{
this.PreviewKeyDown += new KeyEventHandler(ButtonControl_KeyDown);
}

void ButtonControl_KeyDown(object sender, KeyEventArgs e)
{
if (e.Key == Key.Enter)
{

// this should work but doesn't...
/*
ButtonAutomationPeer peer = (ButtonAutomationPeer)UIElementAutomationPeer.CreatePeerForElement(this);
IInvokeProvider invokeProv = peer.GetPattern(PatternInterface.Invoke) as IInvokeProvider;
invokeProv.Invoke();
e.Handled = true;
*/

// this should also work but doesn't - note that this is not the suggested method

RaiseEvent(new RoutedEventArgs(ButtonControl.ClickEvent));
}
}
}

Edit: Actually this does fire a "Click" event - but does not set the IsPressed property - which is what I am using in the style template to show the "pressed" state of the button.

Well since that doesn't do what I want to do maybe I will have to reroute "enter" key events to "space" key events. That seems really hacky though... Any better ideas





Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

Josh Smith

jturpin wrote:

Pressing the space bar while a button is focused fires the "click" event on a button - however the "enter" key does not - thats a bummer. This seems to go against most accesibility practices. Is there a quick/easy way to adding this behavior other than subclassing the Button control and handling (rerouting) key events

A Button should only click upon Enter being pressed if it is the "default" button. The "default" button has its IsDefault property set to true.






Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

jturpin

Josh Smith wrote:

A Button should only click upon Enter being pressed if it is the "default" button. The "default" button has its IsDefault property set to true.

Not if that Button has KeyboardFocus. If a button has KeyboardFocus then it accepts enter.

So I think I found the answer as to why its not working - but I don't have the answer as to why it is implemented this way:

from the SDK:

Code Snippet
IsPressed is the state of a button that indicates the left mouse button or space key is pressed over the button. When IsPressed is true, the control captures the mouse. As a result, the control will raise mouse events such as MouseEnter and IsMouseDirectlyOverChanged. Note that using the AccessText or Enter does not change IsPressed or capture the mouse, but is does raise the Click event.

The reason I originally thought it wasn't working was because in my test app, I have a style template that was triggering off of the IsPressed property - to show a button press visual - which is obviously not happening when the user presses the enter key.

I think it is a problem of semantics. I was assuming the "IsPressed" property was representing the "pressed" state of the button - and not the "pressed" state of the input source. It appears the IsPressed is intended to represent the latter - which I think makes less sense than the former.

So the solution it would seem is to base all "pressed" - or button down visuals on the Click event and not on the IsPressed property. But I am not totally happy with that solution - as it doesn't truely represent the visual state of the button - because if hitting the enter key causes a click event then it most certainly pressed the button as well





Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

Yi-Lun Luo - MSFT

Hello, you don¡¯t need UI automation. Simply try this:

private void Button1_PreviewKeyDown(object sender, KeyEventArgs e)

{

if (button1.IsFocused && e.Key == Key.Enter)

{

button1.RaiseEvent(new RoutedEventArgs(Button.ClickEvent));

e.Handled = true;

}

}






Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

jturpin

Actually, this is not needed - as the Enter key already raises the Click Event - what it doesn't do is generate an "IsPressed" state change. This is the part that was confusing me.

Basically, my argument boils down to this - it is common to use the IsPressed DP of a Button to represent the "visual" state of the button - i.e. if it is pressed (or in the down) state, then you use a visual style that shows this.

And one would assume that in order to "click" a button you have to press it However using the "enter" button on the keyboard activates the Click event without ever changing the IsPressed DP. So if a user "clicks" on a button by focusing the button and pressing enter, and you are using the IsPressed to relay visual information to the user - they will not know that button was pressed, even though it was.

In my situation, the user is always going to "click" on a button using the enter key - as all user input is coming from a remote - so the only choices are up/down/left/right/enter - and I absolutely must give visual feedback that the button was pressed.

It seems my choices are to either trigger a button press animation from the Click event - or to subclass the Button control and create a new IsEnterPressed DP which is a union of IsPressed and the Enter key down event.





Re: Windows Presentation Foundation (WPF) WPF Accessibility Issues

Ben Carter - MSFT

A button uses the IsPressed state as an indication that the user is about to cause the button to click but that the operation can be cancelled (by moving the mouse off the button or by hitting ESC). The ENTER key has historically always immediately caused the button to click (on key down instead of up). Thus, there is no opportunity to cancel the operation. That is why a pressed state does not occur with ENTER.

If you want to give an indication that a button did indeed click, your idea of triggering an animation from the Click event is a valid one.

Ben