Awesome, thanks so much for your work! I can definitely recommend it to other blind people now! I just tested it, and it definitely works great! I do wish the double-right pointing arrows wasn't there, as VoiceOver already tells me if something is a link, but that's a very minor thing. Thanks so much again! On 3/1/21 5:36 AM, Peter Vernigorov wrote: > Latest version of Elaho (1.3, in App Store now) handles preformatted > text better and wraps it with accessibility metadata, using the alt > text if present as title. I tested it with VoiceOver and it seems to > do the right thing. Sometimes it seems to also read the contents of > preformatted text if it looks like words, but not always. In any case, > please let me know if this works better. > > On Thu, Feb 25, 2021 at 10:21 PM Devin Prater <r.d.t.prater at gmail.com> wrote: >> 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 VoiceOver (Apple developer) >> => 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 NVDA screen reader for Windows (Github) >> => 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 Speak screen reader >> => https://github.com/chrys87/fenrir Fenrir screen reader >> => https://brltty.app BRLTTY braille display driver >> >> Hope that helps a little more.
---
Previous in thread (49 of 51): 🗣️ Katarina Eriksson (gmym (a) coopdot.com)
Next in thread (51 of 51): 🗣️ Peter Vernigorov (pitr.vern (a) gmail.com)