That?s great! Arrows will be fixed in the next version. If you have any other accessibility issues, feel free to reach out privately. On Mon, Mar 1, 2021 at 15:41 Devin Prater <r.d.t.prater at gmail.com> wrote: > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210301/3f7d 9a01/attachment.htm>
---
Previous in thread (50 of 51): 🗣️ Devin Prater (r.d.t.prater (a) gmail.com)