Accessibility Compliance for a Single-App Kiosk Mode on iPad

[hflexgrig]

We're building a single-app-mode kiosk application using .NET MAUI, and we've recently been facing quite a few challenges related to accessibility requirements.

We need a keypad device to remain connected at all times so that users with cognitive disabilities can navigate the application using the physical keypad. Additionally, every focused UI element needs to be announced using TTS.

Whenever this device is plugged in, iOS treats it as a hardware keyboard. Some of the built-in navigation works, although we encounter issues and focus traps with certain UI elements.

The biggest challenge, however, is text input. When a user focuses on a text field, we need them to be able to navigate through the on-screen keyboard using the physical keypad, with each key being announced by TTS — for example, “Capital A, Apple,” etc.

To achieve this, we had to create a custom keyboard by overriding the native on-screen keyboard. However, this approach creates concerns about potentially violating Apple's guidelines and getting the app rejected during App Review.

So, is there any existing solution or recommended approach for this use case?

We also tried using the native VoiceOver functionality, but when the keypad device is connected, the software keyboard still doesn't appear, and there doesn't seem to be a way to navigate to or interact with the on-screen keyboard.

Any advice or pointers would be greatly appreciated.

[rokmeglicbit]

@hflexgrig

However, this approach creates concerns about potentially violating Apple's guidelines and getting the app rejected during App Review.
Did you try this or you think this could be a problem? Why?

[hflexgrig]

@rokmeglicbit

https://developer.apple.com/app-store/review/guidelines/

2.3.1
(a) Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review. Similarly, marketing your app in a misleading way, such as by promoting content or services that it does not actually offer (e.g. iOS-based virus and malware scanners) or promoting a false price, whether within or outside of the App Store, is grounds for removal of your app from the App Store or a block from installing via alternative distribution and termination of your developer account.

[rokmeglicbit]

You said:

To achieve this, we had to create a custom keyboard by overriding the native on-screen keyboard.

Apple said:

All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review

What is the problem with including all the details in the “Notes for Review” section?
How to make the functionality accessible for review without any special hardware?

[hflexgrig]

You said:

To achieve this, we had to create a custom keyboard by overriding the native on-screen keyboard.

Apple said:

All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review

What is the problem with including all the details in the “Notes for Review” section? How to make the functionality accessible for review without any special hardware?

Actual question is custom keyboard implementation is the only option? I mean there's no way to have native virtual keyboard open, while hardware keyboard plugged in without using undocumented hacking ways?

We tried also Accessiblity -> Switch Control to turn it on with speach and attaching specific keys to actions, but it is not even close to VoiceOver, no way to change language of speach (system language only), and it is not reading semantic properties.

We tried also private API to forcefully show virtual keyboard, but it was showing first time only, barely you could navigate into keyboard keys, and after a while you're trapped in input field, so nothing works.

Custom keyboard is the only way? there's no official way to use virtual keyboard with VoiceOver?

[rokmeglicbit]

What about this or this document?

Interesting 'ChatGpt' question:

The important experiment
I'd actually test these three things separately:

private async Task TestKeyboard(Entry entry)
{
#if IOS
    // 1. Make the MAUI Entry first responder.
    await entry.FocusAsync();

    // 2. Ask MAUI for the software keyboard.
    await entry.ShowSoftInputAsync(CancellationToken.None);

    // 3. Ask UIKit directly.
    var native = entry.Handler?.PlatformView as UIKit.UITextField;
    native?.BecomeFirstResponder();
#endif
}

Then test:

No hardware keyboard → keyboard appears.
Hardware keyboard connected → keyboard doesn't appear.
VoiceOver ON/OFF → compare behavior.
Manually use iPadOS Show Keyboard → native keyboard appears and VoiceOver works.

If #4 works but #1–#3 cannot reproduce it, that is very strong evidence that the missing capability is an API boundary in iPadOS, not a MAUI bug.

... can you give us some feedback on that?

[rokmeglicbit]

@hflexgrig check for this alternative - https://docs.avaloniaui.net/docs/app-development/accessibility?av_source=marketing&av_medium=docs_link&av_content=platforms-accessibility