Some issues affecting visually impaired users
⚠️ This issue respects the following points: ⚠️
- [x] This is a bug. Not a question or feature request.
- [x] The topic is not already reported at Issues. (I've searched it).
- [x] Markor is up to date. See Releases for the latest version. Updates are available from F-Droid and GitHub.
- [x] The bug is still present in the latest development version (git master). (Please download and try the test version of Markor, named Marder. Don't worry; Markor and Marder appear as completely separate applications. You can install both side-by-side, and Markor settings are not touched. In case the issue is resolved there, you don't need to create a bug report. The change will be part of the next Markor update.)
Description
As a visually impaired user, I frequently use this application because it performs well in terms of accessibility. However, as a blind user, there are currently several serious issues that significantly impact usability.
File Preview
When previewing files while editing, such as markdown files, various problems often occur in the preview view:
- The preview page is completely unresponsive to touch.
- The page is touchable, but certain elements—such as lists and images—cannot be read.
- Repeatedly re-entering the preview page may resolve some issues, but new problems often arise.
Accessibility Labels for Buttons
Some buttons lack accessibility descriptions, such as those in the search dialog and the buttons next to the text editor.
Document Reading
When a document exceeds a certain length, the screen reader fails to continue reading the text. The text editor becomes completely inaccessible to touch, making editing impossible. This issue severely affects usability—once a document reaches a certain length, it becomes unusable.
These are the most pressing issues I have encountered. I hope they can be improved.
Steps to reproduce
I searched for relevant issues and discussions. Records were found that may affect the issue. thes
Information
Android version: 15 Device: Redmi K70 App Version: 2.14.1
Source
F-Droid
Format / File type
Something else (-> Additional info)
Additional info / Log
nothing-
When a document exceeds a certain length, the screen reader fails to continue reading the text. The text editor becomes completely inaccessible to touch, making editing impossible. This issue severely affects usability—once a document reaches a certain length, it becomes unusable.
Android sends the entire UI, including the whole text, to the screen reader every keystroke causing the whole system to become horribly unresponsive and crashy when a file is longer. To work around this we turn off some accessibility features when the document gets very long. One way around this is to have an option to force it on (will have to be opt in).
@harshad1
So, what is the current word limit? At present, it seems to me that the limit is a bit too small. If very large files affect the loading, is it possible to appropriately relax the limit or, as you said, add a function to force it to be turned on? If possible, I hope you can try to add this function, and I can also conduct tests in advance.
There could be some SDK API to detect if talkback/accessibility features are turned on
There could be some SDK API to detect if talkback/accessibility features are turned on
@gsantner I have checked the relevant information, and you can refer to the following information.here touch exploration worthy of attention.
It might be a bit OT, but I would also suggest to add a font for people with dsylexia like OpenDyslexic (https://github.com/antijingoist/opendyslexic).
See
https://github.com/gsantner/markor/blob/master/app/src/main/java/net/gsantner/markor/frontend/textview/HighlightingEditor.java#L368-L387
// Accessibility code is blocked during rapid update events
// such as highlighting and some actions.
// This prevents errors and potential crashes.
@Override
public void sendAccessibilityEventUnchecked(AccessibilityEvent event) {
if (_accessibilityEnabled && length() < 10000) {
super.sendAccessibilityEventUnchecked(event);
}
}
// Hleditor will report that it is not autofillable under certain circumstances
@RequiresApi(api = Build.VERSION_CODES.O)
@Override
public int getAutofillType() {
if (_accessibilityEnabled && length() < 10000) {
return super.getAutofillType();
} else {
return View.AUTOFILL_TYPE_NONE;
}
}
This is one place where we directly modify the accessibility functionality in order to improve the editor stability. Unfortunately this is needed to prevent crashes on even moderately long files with deeper accessibility features enabled in the OS.
@gsantner @harshad1 So can this problem be solved? I really use this software often.I really hope that this problem can be solved as soon as possible.