💾 Archived View for rawtext.club › ~sloum › geminilist › 005639.gmi captured on 2024-02-05 at 11:08:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Devin Prater r.d.t.prater at gmail.com
Thu Feb 25 21:20:54 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Feb 25, 2021, at 2:38 PM, Solène Rapenne <solene at perso.pw> wrote:
Is the reader reading line by line? So depending on the alternative text the user could decide
to explore the content or skip it?The screen readers read line by line, basically. But browsers would have to put the code blocks in a container that can be skipped, like a frame so that screen readers can know that this is something that can be skipped. That’s for browsers that use some kind of web engine to show the content. For text browsers, this can’t really be controlled, some screen readers can’t easily skip it. That’s why I think these browsers should “fold” in Emacs terminology, or hide the blocks on request. Okay, I’ll give more concrete examples.
On iOS, the VoiceOver screen reader shows everything in its own element. The Elaho browser, then, could get away with simply putting the preformatted blocks without Alt-text, or Alt-text that isn’t a language ID, in its own element so that can be skipped by moving to the next element (item) with VoiceOver. This is the same with Android with the TalkBack screen reader, and on the Mac, using VoiceOver.=
https://developer.apple.com/documentation/uikit/accessibility_for_ios_and_tvos/supporting_voiceover_in_your_app <https://developer.apple.com/documentation/uikit/accessibility_for_ios_and_tvos/supporting_voiceover_in_your_app> VoiceOver (Apple developer)=
https://developer.android.com/guide/topics/ui/accessibility <https://developer.android.com/guide/topics/ui/accessibility> TalkBack (Android developer)
Windows and Linux graphical screen readers, however, read web pages like a document. So, there isn’t an easy way to skip past plain text, like Ascii art and such. Even if the blocks are marked up in the GemText, it is up to clients to show them. So, if a client just dumps the GemText into paragraphs, and puts the Ascii art in with it, then it is hard to skip. One can quickly arrow line by line until understandable words are spoken, but this is slow and frustrating. Windows and Linux GUI screen readers do have commands to “skip to end of container,” which are used to skip block quotes, frames, things like that. But the browser has to display them to the screen reader as such, the screen reader doesn’t just guess this.=
https://github.com/nvaccess/nvda <https://github.com/nvaccess/nvda> NVDA screen reader for Windows (Github)=
https://gitlab.gnome.org/GNOME/orca <https://gitlab.gnome.org/GNOME/orca> Orca screen reader (Gitlab)
Console screen readers are the most dumb of them all. They read directly from top left of the screen to bottom right, whereas GUI screen readers start at keyboard focus, or at top left of a document or web page that doesn’t put keyboard focus anywhere else. Console screen readers do have keys to read by line, word or character, but not much else. It all is dependent on the program being read.=
http://www.linux-speakup.org <http://www.linux-speakup.org/> Speak screen reader=
https://github.com/chrys87/fenrir <https://github.com/chrys87/fenrir> Fenrir screen reader=
https://brltty.app <https://brltty.app/> BRLTTY braille display driver
Hope that helps a little more.-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/adc45c81/attachment.htm>