Describe the bug

The current XYFocus implementation, when choosing the next appropriate candidate, can choose a disabled button as the best candidate. This renders XYFocus completely unable to navigate in that direction, as the chosen candidate cannot actually be focused.

To Reproduce

Clone repo https://github.com/IanRawley/XYFocusDisabledButtons.git
Build and run
Focus will be on a button without a command. Try to navigate down to the 3rd button using arrow keys, and see that focus does not move.

Expected behavior

Focus skips the disabled button and goes to the next enabled button, as with Tab navigation.

Avalonia version

11.3.9

OS

No response

Additional context

The problem appears to be in the definition of IsValidCandidate

return candidate.Focusable && candidate.IsEnabled && candidate.IsVisible
               // Only allow candidate focus, if original key device type could focus it.
               && XYFocusHelpers.IsAllowedXYNavigationMode(candidate, inputKeyDeviceType);

InputElement has 5 relevant properties: Focusable, IsEnabled, IsVisible, IsEffectivelyEnabled and IsEffectivelyVisible. The first 3 can be set by the user, while the last 2 are calculated. The problem is that Buttons with bound commands, when the command cannot be executed (CanExecute = false), only change the value of IsEffectivelyEnabled in order to preserve user preferences. By checking IsEnabled and IsVisible instead of IsEffectivelyEnabled and IsEffectivelyVisible these changes which disable the Button behind the scenes are missed, making a disabled Button the best candidate and cutting off XYFocus navigation. It should be a simple fix, and I will prepare a Pull Request.