[WiP] TabIndex/TabStop/Keyboard Traversal APIs

[PureWeen]

Description

Provide a set of APIs to allow users the ability to influence if a control is reachable by a keyboard and the order the keyboard will navigate controls on the screen

Proposed API 1

Use the same APIs that we had in XF https://learn.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/accessibility/keyboard

These APIs heavily broke accessibility in Xamarin.Forms so they were removed from .NET MAUI

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[stewartsims]

I understand these were removed due to the rationale described in https://github.com/dotnet/maui/issues/1646. Using the SemanticOrderView is a good alternative, but this is geared around accessibility (obviously important), however it seems to ignore the use case scenario described here: https://github.com/dotnet/maui/issues/1646#issuecomment-879971893

Controlling the ordering of items tabbed between is a valid data entry use case for desktop versions of an app (or indeed any platform that allows keyboard input). In particular tabular data is a good example and in fact we have an app with input fields laid out in a table where we would want to control the tab direction.

While SemanticOrderView can be used to assist with this use case, IsTabStop seems to be deprecated with no alternative.

I'm surprised Xamarin has been dropped leaving app developers without access to some of the elements that make keyboard entry more user-friendly in .NET MAUI. These capabilities have been commonplace in desktop environments in particular for a very long time and can also be found in web apps too.

[stewartsims]

Just to clarify the kind of use cases I'm referencing. The spec issue contains the following statement:

For example, the use case in current Xamarin.Forms documentation is flawed. It suggests using TabIndex as a valid way to force the current design to be more accessible. However, the design itself was not the most accessible to begin with. In English, reading order is left-to-right, top-to-bottom so the names in the grid itself should've been rearranged themselves, improving the general content ordering and thereby fixing the accessible ordering more naturally and appropriately.

This is fine if you can modify the layout of the user interface. In the case of some apps you can't actually do this. To be specific an app I work on has digitised versions of paper forms. Many of the sections of the form can be re-designed for better accessibility and user experience, however the tables for example have a fixed layout. I cannot just swap the rows and columns around - they have to remain in a fixed layout because this app has to produce a printable PDF once the form is filled in. We can't change the regulations that mean this form has to have a certain layout. Sometimes you have to work with these kinds of constraints and in these cases, things like TabIndex and TabStop are very useful and not just some abstract relic from the 90s.