💾 Archived View for rawtext.club › ~sloum › geminilist › 005635.gmi captured on 2023-11-14 at 09:57:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Solène Rapenne solene at perso.pw
Thu Feb 25 20:38:14 GMT 2021
- - - - - - - - - - - - - - - - - - -
25 février 2021 21:29 "Devin Prater" <r.d.t.prater at gmail.com> a écrit:
Is that because "slash" has one syllable and "asterisk" has three?
Just guessing here, but please
tell us what works/doesn't work for you, or point to a suitable
"accessibility 101" site.
Nah, slash is just easier to press than Shift + 8. I meant ergonomic as
in easy to type. Although,
“slash" is spoken more quickly than “asterisk", but most TTS engines
say “star” anyway. It’s not
significant, and is definitely up to the writer’s choice of style.
So, this is where client creators come in. Gemini clients should have
a way to hide preformatted
blocks, or fold them, or if they are a GUI client, like GemiNaut,
which shows the Gemini text in n
HTML-like area, map the blocks to a frame, so that screen readers can
skip them.
I think that most preformatted blocks are meant to be readable. How
about an option to hide
preformatted blocks if and only if they have alt text? That, plus
social pressure to actually
*provide* alt text, even if it's just "ascii art" or "ascii art
kittens", should do it.
The problem is that screen readers *cannot* read Ascii art in any
meaningful way, so having the
option to hide those blocks by default would really help. If clients
really wanted to be smart,
grab a list of language short codes from Github or something and show
blocks with those language
ID’s, like:
``` Python
…
```
Would be shown, but:
``` Best widdle kitten ever
…
```
wouldn’t. But that’s just something I’ve thought of when thinking about
how to work around
preformatted blocks that would be meaningful to a screen reader user,
like code, and those which
wouldn’t be, like Ascii art.
Is the reader reading line by line? So depending on the alternative text the user could decideto explore the content or skip it?
Thank you very much for your email! There is definitely a need to improve the accessibility andit better to do it know than trying to change things once the protocol and formats are carvedin stone.
I wonder if the alternative texts (better renamed "description"?) should be mandatoryfor such pre-formated blocks?