Accessibility issues in input boxes on mobile

[dogancankalinci]

Hello,
I am a game developer creating audio games for the blind.
I use SDL to handle touch events and input boxes. However, I’ve encountered a few accessibility-related issues.
When I call SDL_StartTextInput, the native on-screen keyboard appears correctly on both Android and iOS.
But users are unable to paste text into the input boxes. Normally, with a screen reader, they locate the edit box above the keyboard and long-press it to bring up options like Paste. In SDL, however, the screen reader can only detect the keyboard, not the input box.
Also, when users try to use third-party screen reader extensions (for example, text translators), these tools report “text box not found.”
Is there any solution for these problems?
Thanks in advance for your help.

[dogancankalinci]

I want to add some more context to explain why this is a critical barrier for accessibility-focused applications and why common workarounds used in visual games aren't applicable here.
My application is an audio game, designed specifically for blind and visually impaired players. The screen is completely black by design. All user interface navigation and feedback are provided through audio cues, using iOS's AVSpeechSynthesizer and Android's TextToSpeech engine. Users navigate menus by swiping, and my game's logic interprets these gestures to read out the current menu option.
This audio-centric model works well for custom UI, but it breaks down completely with SDL's current text input implementation. In a typical visual game, developers can create a custom "Paste" button as a sprite. This is not possible for my users, as there is nothing to see or tap on.
Blind users rely on screen readers like VoiceOver (iOS) and TalkBack (Android) to interact with their devices. The standard, learned behavior for pasting text is to navigate to the text input field, at which point the screen reader announces "Text field, editing...", perform a long-press to bring up the context menu, and select "Paste" from the available options.
Because SDL's text input is not visible to screen reader users, the screen reader cannot find the text box in step #1. This blocks the entire process and makes pasting impossible. Users are confined to only typing and backspacing from the end of the line.
In summary, the issue is that SDL's text input is inaccessible to the very services my users depend on for all interaction, only the keyboard is accessible.

[slouken]

The issue here is that when you're doing drawing using raw graphics APIs, like you are when you use SDL, you're not using a native OS textbox, which is what most accessibility frameworks use to detect textboxes. I don't know of any solution for this, but you're welcome to suggest one!

[dogancankalinci]

Thanks for the clarification.
Just to clarify — in my case, I’m not drawing anything with SDL.
As I mentioned in my second comment, I only use SDL to handle touch events and text input.
When I call SDL_StartTextInput, the native OS keyboard opens correctly, but there is no corresponding editable text field that screen readers can detect or long-press to bring up the “Paste” option.
That’s the core issue I’m facing.

[slouken]

Well, you didn't create an editable text field. :)

[dogancankalinci]

I understand, but as I mentioned, I’m not creating any custom text field manually.
SDL only opens the native keyboard, but does not expose a native editable text field for screen readers to detect.
That’s exactly the accessibility issue I’m reporting.

What I mean is that SDL should automatically create a native text field for accessibility.
When a user long-presses and clicks Paste, SDL should generate a new SDL_TEXTINPUT event with the pasted text.