boring-cyborg[bot]
commented
5 months ago Thanks so much for opening up your first issue here on the repository! 🎉 We would like to warmly welcome you to the community behind the app! ☺️ We'll check in soon and have a look at your issue. In the meantime, you can check your issue and make sure it aligns with our contribution guidelines! Here's the comprehensive list:
NOTE: Please do not share screen captures of buggy behavior on YouTube. If you have uploaded a video on YouTube and linked it already, don't worry! But, we would like to ask you to remove the video from YouTube and upload it directly to GitHub instead, by editing your comment. Read more here.
Enhancements
An enhancement takes a feature and improves or alters its behaviour. Please make sure to argue how your proposition will aid non-technical text workers, and why it can't be emulated easily with other features or apps!
Feature requests
Feature requests introduce whole new features into the app. This requires a lot of work, so these might be turned down if the implementation costs supersede the benefits we expect to see from implementing it. Please do not be disappointed if that happens. It likely has nothing to do with your great request but simply with us and our missing resources!
You can of course always ask someone to implement this feature, because a PR with a working new feature has much higher chances of being merged! :)
Bug reports
Please note that one of the main reasons for why bug reports cannot be addressed is that there's not enough information for us to find and fix the bug you describe, so make sure you try to pinpoint the bug as close as possible.
The ideal bug report for us has two qualities:
- The bug is always reproducible, at least within a certain context.
- We know exactly what specifically goes wrong, and there is consensus on what should happen instead.
Please note that if you encounter behaviour that does not align with your expectations of what would happen, this might as well be simply intended behaviour and we need to simply clarify why the behaviour is the way it is. This is not to be considered a bug and such issues may be closed! Suggest an enhancement instead!
But now, have a great day and thank you again!
Description
When opening a new file in Zettlr, and using a screen reader to try to review your input, it will rapdily become apparent that screen readers are unable to perceive this content. This almost certainly happens due to the specific editor component used, my guess would be CodeMirror on a version lower than 6, where this problem has (at least to a point) been resolved. Please consider bumping the CodeMirror version, allowing for an alternative editor (Monaco would be best), or figuring out some other solution for the fact that people using a screen reader are currently unable to edit any kind of text whatsoever within this app, something that I would consider one of its core functions :) Disclaimer: screen reader user with a developer background.
Reproducing
Zettlr Version
Stable (most recent version)
Specify version
This is more than likely a problem that has been there for the entirety of the app's existence
Installation Method
None
Your Platform
Architecture
Operating System Version
irrelevant, but Windows 11 23h2
Additional Information
For technical context, what's happening here is that screen readers can only focus one thing at a time, and that what they focus needs to entirely be part of the DOM. The textarea that CodeMirror (and perhaps very similar other editor components) use to work is really just there to catch input, not to hold output, therefore the contents of the editor actually isn't in the textarea, it's usually in some kind of canvas behind the textarea. The only time the entire contents of the editor is in the screenreader-accessible textarea element is when someone hits ctrl+a to select all, as the OS-level clipboard suffers from the same problem and wouldn't otherwise be able to copy the code/text out of the editor.