[Discussion] Unfocus Android controls behavior vs accessibility

[lobbo232]

Hi! We understand that this was a behavior change from Xamarin.Forms, but it was an intentional one. We do not consider this to be a bug.

Please see this comment from Rachel on #11881.

Hi All,

In developing .NET MAUI, we learned that it is not possible on earlier versions of Android to unfocus an entry. Some control must always be focused. In Xamarin.Forms, this was approached by setting focus on the page layout; unfortunately, this approach created major accessibility issues. For these reasons, .NET MAUI no longer allows for this behavior by default.

If this antipattern can be avoided, we highly recommend using a different approach. If it cannot be avoided, we'd love to learn more about your scenario so that we can better understand your development needs! That being said, we do understand the needs from a migration compatibility standpoint, so for those scenarios, there is a new property that was introduced in .NET 8. Using HideSoftInputOnTapped should do the trick.

.NET MAUI aims to be as accessible as possible with little interaction from developers, so we will not revert this behavior. Thank you for understanding.

Originally posted by @samhouts in #21053

@samhouts I don't think we are understanding. Issues are being created constantly related to this.

Why would preventing an un-focussing action from triggering the unfocussed event increase accessibility? Can you help us understand the thought process here and perhaps give a reason as to why we can't have this behaviour in our own apps? This seems to reduce accessibility in most scenarios.

The HideSoftInputOnTapped alternative closes the input but doesn't trigger the Unfocussed events. Is this also intentional? Seems broken to me.

The TextChanged event is a terrible option due to the inefficiency of firing the event on every single key press.

It seems that the whole community wants this.

[albyrock87]

I was asking myself the same question, so I've just opened a few famous apps on my Android device simply to realize that tapping on the screen does not remove the focus and sometimes it doesn't even hide the keyboard.

There are some exceptions which I found:

• search bars
• web page inside web view

Therefore, despite I don't like it, I can confirm that this appears to be the default logic of Android apps.

[jfversluis]

I'm not sure what other answer you're looking for. Everything that you need to know, imho, is in your own opening post.

For Xamarin.Forms we made a hack to make that all work and that's what you're now used to and learned to work with, but is not the way it is intended. To make it even worse, it actually makes apps much less accessible, that is something that you should never want.

From reading through the test you added it seems like you don't see why it would make an app less accessible. If I take Rachels answer

In developing .NET MAUI, we learned that it is not possible on earlier versions of Android to unfocus an entry. Some control must always be focused. In Xamarin.Forms, this was approached by setting focus on the page layout; unfortunately, this approach created major accessibility issues. For these reasons, .NET MAUI no longer allows for this behavior by default.

That's exactly what I just said: we probably ran into this during the development of Xamarin.Forms and "fixed" it by setting the focus to a layout and with that painted ourselves into a corner that we couldn't get out of anymore. The longer such a hack is implemented, the more people start to rely on it and at some point that is just the truth, but it isn't necessarily the right thing to do. As such, as mentioned, we're not going to reintroduce any of that behavior.

What I do think is that we need to understand the problem better that you're trying to fix and/or the functionality that you're trying to implement and see what solutions are possible there without compromising accessibility but still achieve whatever it is you're trying to do. Maybe its already possible with what is available today, or maybe we need to implement something new or make something existing better.

With that in mind, I know there is already a whole discussion spanning multiple issues, but can you maybe summarize the most basic scenario of what you're trying to do and why that is not working? Ideally with a reproduction project on GitHub?

[lobbo232]

Thanks, your answer does help clarify some bits, I think @albyrock87 also provided some good information about how other apps behave, and that this isn't strictly a Xamarin/MAUI issue.

I'm still unsure what Accessibility issues there may be by not having an input unfocus when you tap other items. Do you have any examples?

The scenario I have is similar to a lot of other posts, in which the "unfocused" event is used to process the data entered. In our case we automatically run some validation and save the answer.

I tried a few ways to work around, things I expected to work, such as having a button next to the input that when clicked would unfocus the input, but it seems that button never got focussed so the unfocused event never triggered.

The "HideSoftInputOnTapped" workaround that was implemented and suggested as the answer before Issues promptly being closed I feel introduced a lot of confusion too as, while closing the input, does not restore the "Unfocussed" functionality that we are used to.

I have worked around this issue in my app by using the OnChanged event. Out of the box, that event is pretty useless for the functionality we wanted to retain as it would trigger the validation and save event on every single keyboard press. Instead I'm using a timer to check the user has actually stopped typing for a second before attempting to trigger the validate and save methods.

My suggestion, and perhaps it could be an improvement for MAUI, is that inputs that require the user to type (entry and editor) have a new event called FinishedTyping, with an additional parameter called FinishedTypingDelay. This event could be triggered like my workaround above using a timer to make sure no input has been made for the duration of the FinishedTypingDelay, and then trigger the FinishedTyping event. It seems a lot of people want this kind of unfocussed input auto saving functionality.

Again, thanks for your time providing some more information on this.

[bzd3y]

@lobbo232 I had been struggling with this for a while. It's pretty amazing that there are probably a dozen issues/discussions about it, but the response is generally crickets or "Eh, what can you do?"

After working on this, I do understand the rationale in why it works the way it does. But I also think that that shouldn't mean that nothing is done to improve the framework.
 
It should also be noted that iOS does not do this, creating some inconsistent behavior between the two platforms that could be made consistent by MAUI, which seems pretty reasonable and is kind of in-line with its entire purpose for existing.

Why would preventing an un-focussing action from triggering the unfocussed event increase accessibility?
I'm still unsure what Accessibility issues there may be by not having an input unfocus when you tap other items. Do you have any examples?

Personally I disagree/don't entirely agree with this answer, but a possible answer is that when a user clicks a Button it doesn't remove focus from the view they were previously interacting with and possibly force them to manually move focus back to it again to continue interacting with it.

Imagine something like an Entry/Editor with a "Save" button somewhere on the page. Every time the user clicks "Save" they will then have to return focus back to the previous view to continue working, which also means they will probably have to make sure the caret goes back to where it was when they clicked "Save". So something like saving often would be a hassle, especially for people with accessibility needs.

Another similar example would be a sign in process. They enter their username and password and then have to click "Sign in". But if their password is wrong then they now have to click back into the password Entry to try again. That makes it that much harder for somebody with accessibility issues.

I'm not 100% sold on that rationale (why can't it just be configurable?), but I do understand the reasoning used.

It's somewhat pointless other than to maybe add context, but what might make it even more annoying is that it is kind of configurable in that you can set FocusableInTouchMode to true and that lets something like a Button get focus and take it away from the previous view like you'd expect a normal UI to do, but it doesn't register the click that moved the focus so now to click a Button you have to click it twice (though I see valid reasons to want this behavior in some situations). IMO this is just poor design on Android's part (the idea of "TouchMode" itself seems bad or at least unintuitive). A better design would be FocusableInTouchMode being an enum with values like RejectFocus (equivalent to false), AcceptFocus (equivalent to true) and InterruptFocus. The last is what it currently doesn't do: take the focus from the previous view so the application can be made aware that the user left the view they were in and then return focus to that view. But, I digress.

Here is the workaround I am currently using. It may or may not work for you, but I'm sure it could be modified to and then you could avoid having to rely on a timer, plus it is more generalized than "the user is done typing", although I am using it for essentially that same purpose.

	ViewHandler.ViewMapper.AppendToMapping("UnfocusFix", (h, v) =>
	{
		if (v is not ScrollView && h.PlatformView is Android.Views.View view && view.Focusable && (view.FocusableInTouchMode == false))
		{
			view.Touch += (s, e) =>
			{
				if (e.Event?.Action == MotionEventActions.Down)
				{
					view.Context?.GetActivity()?.CurrentFocus?.ClearFocus();
				}

				e.Handled = false;
			};
		}
	});

From the following issue: #23901 (comment) There is another workaround I provided in this issue that relies on changing FocusableInTouchMode to true for Buttons, which might work better for some people/needs.

Finally, as I touched on above, this is a design principle in Android, meaning that it isn't really a conscious design decision on MAUI's part other than by honoring/adhering to Android's behavior.

With that being said, I think there are two approaches that could do that while also providing developers with a rational, intuitive UI system.

1. It could be as simple as invoking the MAUI Unfocused event/EventHandlers attached to the Unfocused anyway. If I recall correctly from developing the above workaround, you can't just simply call Unfocus() in the code above, for example. It essentially relies on the underlying Android mechanisms where "unfocusing" fails so the events are never fired. Actually, the problem is that we don't have the virtual view that has focus, only the native view. But that doesn't mean that MAUI couldn't still call its own events. The issue with this might be in figuring out when to let Android invoke the events and when MAUI needs to do it manually. Focusable/FocusableInTouchMode might indicate that, but that would take some testing.
2. Add a "Blurred" event to views (or maybe certain views) and then invoke it using code similar to my workaround above (but in the default handlers, not a custom handler). In other frameworks/APIs/platforms "Blurred" is used as a synonym for "unfocused". In this case, there would be some different semantics. Unfocused would mean the view actually lost focus while Blurred would mean that the user simply did something outside of the view, whether it ended up losing focus or not. The EventArgs passed to the event could also possibly indicate whether it lost focus or not. Of course, a name other than "Blurred" could be used if desired, but that's the first one that comes to mind.

[bzd3y]

With that in mind, I know there is already a whole discussion spanning multiple issues, but can you maybe summarize the most basic scenario of what you're trying to do and why that is not working? Ideally with a reproduction project on GitHub?

@jfversluis Not to sound flippant, but I think it is just as simple as wanting to know when the user "leaves" something like an Entry to click something like a Button. There's nothing wild or exotic going on here. It is just a simple, intuitive UI design of detecting when a user does something outside of a view (whether it still has/will have focus or not).

But I think there are two things going on that are causing some confusion, due to how Android behaves (or behaved in the past).

The first is a combination of the fact that Android requires one view to have focus and possibly that even beyond that it just didn't fire any "unfocused" events for the native views underlying something like Entry and Editor. As far as I can tell the former is still true, but if the latter was ever true, it isn't now and Android does fire an event when an EditText loses focus. It just has to actually lose focus, which brings us to the second issue.

The second is what I described in my previous comment, which is that Android buttons don't take focus by default (and when they do, they don't register the initial click) and so when the user clicks one it doesn't remove focus from whatever view has focus. This is probably also for accessibility/usability reasons.

But that ignores (i.e. Android ignores and MAUI goes along with it) the difference between a view losing focus and the user "leaving" the view or doing something outside of it. Android might not have a concept of that, but I'm not sure why MAUI couldn't and do something like I described in my previous comment.

Ultimately, I think it is reasonable to expect a sane UI framework to allow the developer to know when a user does something outside of the UI element with focus even if it doesn't lose focus as a result. At the very least, it makes it difficult to manage workflows where the user is going back and forth between text entry elements if there are any buttons involved.

For example, the code to do something like do some validation on "Username" and "Password" fields (or maybe two "Password" fields, like for password strength and to make sure they match) is a lot more complicated when you can't rely on the framework to tell you when they left one of those fields and clicked the login button. You might need to validate when both Entrys get focus and also when the user clicks "Log in" and possibly in the Focused/Clicked event of everything else on the page. It's not impossible, but it's a lot more complicated than if you could just do the validation you need when the user leaves a given Entry.

[bzd3y]

I've come up with another work around here: #23901 (comment) that might work better or be preferrable for some people's needs. It works by requesting focus for the touched view instead of clearing focus from the previously focused view. So something like a Button behaves normally as far as appearance and clicking is concerned but it can actually get the focus, which might allow this to work in situations where Android is enforcing its requirement of one view having focus.

I tried to come up with a way to only fire the "unfocused" events of the previously focused view, but if that is possible with the available API, it isn't straight forward. I thought that I could use the OnFocusChangedListener to just "tell" the view it lost focus, which does work, but doing that causes the virtual view to think it no longer has focus (IsFocused == false) even though it seems to as far as Android is concerned.

The easiest way to accomplish similar behavior is, with either of these solutions, to manually move the focus back to the view that just lost it, which would trigger any "focus" events for that view. That may or may not be desirable. Although it does represent what is truly happening.