Ref. 4605
From أبو يوسف (@Ayoub_atwa) on Telegram:
https://t.me/CodeOnTheGoDiscussions/6639
"1. Code Editor Cursor Placement & Typing Sync (The Bug):
The Issue: The main code editing area is currently very difficult to use. When I double-tap on a specific word or line to place the cursor, the editor fails to sync the actual text cursor with my accessibility focus. The cursor either disappears, or characters are inserted in random locations (e.g., typing on line 8 instead of line 3).
Current Workaround: I am forced to use the screen reader's native text editing menu (opening an external edit box, modifying, and saving back). This is time-consuming and breaks the programming flow.
Suggestion: Ensure AccessibilityNodeProvider accurately syncs the accessibility focus coordinates with the internal text cursor, mimicking a standard EditText."
From the same user, this is the preface post to a series of issues (including this one) designed to increase accessibility for users with low vision or blindness:
https://t.me/CodeOnTheGoDiscussions/6630
"Dear Code on the Go Development Team,
Thank you for your proactive approach to accessibility. As an Android developer who relies on screen readers, I would like to share some insights to help improve the experience for low-vision and blind users.
To understand why certain UI elements fail, it is crucial to understand how screen reader users interact with the screen:
Sequential Swiping: We swipe left or right with one finger to move the accessibility focus sequentially from one UI element to the next (e.g., 1, 2, 3, 4).
Touch Exploration: To navigate faster without swiping dozens of times, we touch the screen directly where we expect a button to be. Once the screen reader announces the element under our finger, we double-tap anywhere on the screen to activate it.
Scrolling & Paging: Scrolling requires a two-finger swipe (up/down/left/right). UI elements that rely on complex internal scrolling or dragging often cause the screen reader focus to get lost or jump erratically.
Long-Press & Drag gestures: A long-press is performed via a "double-tap and hold" gesture (similar to bringing up message options in WhatsApp/Telegram). If we need to drag an element, we hold the second tap and slide our finger. The app must accurately register the accessibility focus during this gesture without misinterpreting the target.
With these mechanics in mind, here are 4 key areas where the app's accessibility can be significantly enhanced:"
Ref. 4605
From أبو يوسف (@Ayoub_atwa) on Telegram:
https://t.me/CodeOnTheGoDiscussions/6639
"1. Code Editor Cursor Placement & Typing Sync (The Bug):
The Issue: The main code editing area is currently very difficult to use. When I double-tap on a specific word or line to place the cursor, the editor fails to sync the actual text cursor with my accessibility focus. The cursor either disappears, or characters are inserted in random locations (e.g., typing on line 8 instead of line 3).
Current Workaround: I am forced to use the screen reader's native text editing menu (opening an external edit box, modifying, and saving back). This is time-consuming and breaks the programming flow.
Suggestion: Ensure AccessibilityNodeProvider accurately syncs the accessibility focus coordinates with the internal text cursor, mimicking a standard EditText."
From the same user, this is the preface post to a series of issues (including this one) designed to increase accessibility for users with low vision or blindness:
https://t.me/CodeOnTheGoDiscussions/6630
"Dear Code on the Go Development Team,
Thank you for your proactive approach to accessibility. As an Android developer who relies on screen readers, I would like to share some insights to help improve the experience for low-vision and blind users.
To understand why certain UI elements fail, it is crucial to understand how screen reader users interact with the screen:
Sequential Swiping: We swipe left or right with one finger to move the accessibility focus sequentially from one UI element to the next (e.g., 1, 2, 3, 4).
Touch Exploration: To navigate faster without swiping dozens of times, we touch the screen directly where we expect a button to be. Once the screen reader announces the element under our finger, we double-tap anywhere on the screen to activate it.
Scrolling & Paging: Scrolling requires a two-finger swipe (up/down/left/right). UI elements that rely on complex internal scrolling or dragging often cause the screen reader focus to get lost or jump erratically.
Long-Press & Drag gestures: A long-press is performed via a "double-tap and hold" gesture (similar to bringing up message options in WhatsApp/Telegram). If we need to drag an element, we hold the second tap and slide our finger. The app must accurately register the accessibility focus during this gesture without misinterpreting the target.
With these mechanics in mind, here are 4 key areas where the app's accessibility can be significantly enhanced:"