[Bug] Keyboard Bugs and Xamarin.Forms migration concerns

[PureWeen]

Description

This issue is an organization of current issues/PRs/specs related to keyboard management. The keyboard management inside Xamarin.Forms was very patch work and for the most part completely broke accessibility. A lot of the keyboard "features" were not brought over to .NET MAUI until we could assess the validity of the approach and ensure valid accessible platform experiences.

Hitting Enter or Next on keyboard does not always move to next entry field when you have the ReturnType set to Next

• Android
  • This behavior is built into Android and will be fixed on an upcoming release.
• iOS
  • This behavior is not built into iOS so we are still looking at the best way to provide this behavior.

Software Keyboard covers the entry and should scroll the selected entry into view

• Android
  • This behavior is built into Android and will be fixed on an upcoming release.
  • Maui Keyboard Bugs both with AdjustPan/AdjustResize #12406
• iOS
  • This behavior is not built into iOS. We are still looking at the best way to provide this behavior.

Software Keyboard does not open when Entry View's Focus is set to True Programmatically

• Android
  • We should change the behavior so that Focus opens the keyboard on Android. The one difference here from XF is that we should key it off of TextView.ShowSoftInputOnFocus. If a user sets ShowSoftInputOnFocus to false on the Android TextView we won't pop open the keyboard.
  • Google deprecated the method you could use to force open the soft keyboard and recommends always using the keyboard method that takes a view as input so that it has context for why you are opening a keyboard
  • Show keyboard on Android entry/editor/searchbar focus #12890
• iOS - This behavior "works" on iOS

Soft Keyboard does not Close when Entry View's Focus is set to False Programmatically

• For Android we currently won't fix this in the same way that it works on XF. In order for this to work focus has to go somewhere. In XF the root page was set to focusable. This would cause the PageRenderer to gain the focus. Making a non-interactive element focusable is hostile to keyboard users and anyone using TalkBack. If you want to unfocus an entry then you need to give focus to some other logically interactive element.
  • Use https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/extensions/keyboard-extensions to close keyboard instead of focus
• iOS seems to handle the concept of "unfocusing" any elements in such a way that's still accessible. When an entry becomes "unfocused" iOS appears to remember where the user left off. Once the keyboard/Voice Over user proceeds, then iOS continues where they left off.
  • One thing to note is that with iOS you open/close the keyboard by setting the current responder (foocusing and unfocusing). So, there isn't just a general open/close keyboard. It all has to be done within the context of a specific field.

Tapping off of an Entry unfocuses the entry and closes the keyboard

• Android - In XF this was achieved by making the root elements focusable and clickable. This behavior is hostile to TalkBack users because it causes the Page to register as a clickable element. When a hard of seeing user would use TalkBack the entire page would become selected and tell the user to "double tap to activate".
  • Provide a sample of using an overlay to detect a touch that doesn't affect accessibility.
  • As part of the Keyboard Management APIs provide a feature that will close the keyboard if you click outside an element.
  • Add TextInput property so users can enable/disable if they want tapping outside on an input field to close the keyboard #12003
• iOS - We left this behavior for iOS because this behavior doesn't appear to break accessibility on iOS. Adding a UITapGestureRecognizer to the underlying page doesn't appear to affect VoiceOver
  • We did have to modify the implementation a bit because it does slightly break UISwitch UISwitch doesn't toggle the first time if you have VoiceOver enabled #11543. See how easily you can break accessibility in unexpected ways with things that seem harmless.

Workarounds

• Opening and closing keyboard programmatically

Specs

#12004

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[riccardominato]

Shouldn't #9458 be covered by this issue? It messes up Grid layouts when keyboard appears.

[pulmuone]

I am using Android Entry Keyboard bug fixed like this.
https://github.com/pulmuone/MauiAndroidKeyboard