Ref. 4607
From أبو يوسف (@Ayoub_atwa) on Telegram:
https://t.me/CodeOnTheGoDiscussions/6641
"3. Proposal: A Screen-Reader Optimized Editor Mode
Since rendering raw code on a custom canvas is notoriously hostile to screen readers, I propose a dedicated "Screen Reader Mode" for the editor area that functions like a standard native list (e.g., a RecyclerView of buttons):
Native Dialog Editing: Instead of typing directly on the canvas, the code is presented as a vertical list of readable elements. Clicking on any line opens a standard, stable native Dialog containing an EditText for that specific code segment, along with "Save" and "Cancel" buttons.
Long-Press Context Menu: A long-press on any line should open a native context menu with standard actions (Delete, Start Selection, Copy, Cut).
View Toggles (Line vs. Block): Add toggle buttons below the editor to change how the code is grouped for the screen reader:
Line Mode: Each button represents a single line of code.
Block Mode: The code is grouped into logical blocks based on visual formatting (e.g., code separated by two consecutive empty lines becomes one block). This allows blind developers to skip through large files incredibly fast."
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. 4607
From أبو يوسف (@Ayoub_atwa) on Telegram:
https://t.me/CodeOnTheGoDiscussions/6641
"3. Proposal: A Screen-Reader Optimized Editor Mode
Since rendering raw code on a custom canvas is notoriously hostile to screen readers, I propose a dedicated "Screen Reader Mode" for the editor area that functions like a standard native list (e.g., a RecyclerView of buttons):
Native Dialog Editing: Instead of typing directly on the canvas, the code is presented as a vertical list of readable elements. Clicking on any line opens a standard, stable native Dialog containing an EditText for that specific code segment, along with "Save" and "Cancel" buttons.
Long-Press Context Menu: A long-press on any line should open a native context menu with standard actions (Delete, Start Selection, Copy, Cut).
View Toggles (Line vs. Block): Add toggle buttons below the editor to change how the code is grouped for the screen reader:
Line Mode: Each button represents a single line of code.
Block Mode: The code is grouped into logical blocks based on visual formatting (e.g., code separated by two consecutive empty lines becomes one block). This allows blind developers to skip through large files incredibly fast."
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:"