💾 Archived View for rawtext.club › ~sloum › geminilist › 005815.gmi captured on 2023-09-08 at 17:12:33. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Mon Mar 1 15:40:28 GMT 2021
- - - - - - - - - - - - - - - - - - -
That’s great! Arrows will be fixed in the next version. If you have anyother 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/3f7d9a01/attachment.htm>