💾 Archived View for gemi.dev › gemini-mailing-list › 000755.gmi captured on 2024-05-12 at 16:14:34. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all. I hope this comes across okay; this is my first time posting on this list. I have only been using, and writing for, Gemini for a few weeks now, but I wanted to give my thoughts, more officially than my ramblings on Mastodon, about it. This mainly just concerns clients, as I don?t have a problem really with the spec, just the assumptions made about preformatted blocks, and how they?ve been handled in clients. I am a blind person who is interested in all kinds of different ways of working with text and writing. I?ve written in Markdown, Org-mode, tried LaTex but found it just about as verbose to write as HTML, and thought about Restructured Text but the advanced stuff in it looked a lot like HTML too. Anyways, I got into Gemini because of the simplicity. I loved the idea of basically a Markup language being the pure writing method of an entire site. No static site generator needed, just directories of linked plain text files. No CSS, no JavaScript, no Liquid or or shortcakes or anything. So, I started looking at the spec for GemText. Links one on each line, I could do that. No italics or bold, but people are used to seeing *this* anyways, or even /this/ for better ergonomics (for me anyways) and Org-mode fans. No tags to worry about, either! But then we get to preformatted blocks, and the dreaded Ascii graphics. This is what I?ve always disliked about all plain text mediums. MUD?s use Ascii maps and compass and all that. Gopher uses Ascii graphics. And now Gemini too. Sure, it?s wrapped up in a pretty block, but as I?ll discuss in a moment, that isn?t necessarily helpful. Screen readers are not smart. They speak whatever the operating system or application exposes to the accessibility API?s. Sure, the spoken, or brailled, output can be arranged or massaged slightly, but whatever is there is what will be spoken, from left to right, top to bottom. Some screen readers, like NVDA and JAWS, and Orca to some extent, do try to massage the data of websites to make them easier to use or to fix accessibility issues that the web developer won?t or can?t, but there?s a line they try not to cross between scripting things to work better and making up a whole new interface for something when the UI developers don?t consider accessibility. Even if the block is labeled, it?s still text, and the screen reader will do what it does, read all of it. 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. So far, neither Elpher, for Emacs, or Elaho, for iOS, even show Alt Text in preformatted blocks, even if that Alt Text is there. I know this is a new standard, and one that isn?t finalized yet, but I do hope that browsers focus on accessibility and start things off well, so that Gemini doesn?t turn out like the web with unlabeled images everywhere and controls on web apps that are hard to use and unlabeled. I hope that Gemini can show the world what a good group of people, a great standard, and programmers who care about making Gemini as easy and delightful to access can do to make things just that much better. Now, this isn?t to say that Gemini is bad for accessibility. I love being able to get right to the content of a page *quickly* because there are no sidebars, no top navigation links, no ads, no frames, no nonsense. It?s like having the whole web in reader view, with only useful or important links at the bottom or somewhere out of the way. I *love* that about Gemini, and it?s why I read it on not only my laptop with Emacs, but on my iPhone too. So thank you all for this great way to read and write on the Internet! For those interested, my Gemini site is at: => tilde.pink/~devinprater/ ---------------- Devin Prater r.d.t.prater at gmail.com
On Thu, Feb 25, 2021 at 2:42 PM Devin Prater <r.d.t.prater at gmail.com> wrote:
> I am a blind person who is interested in all kinds of different ways of
> working with text and writing.
Thank you very much for participating: accessibility is always best
discussed when a person who needs it is actually in the room. ("If you
want to know how much antisemitism there is in your country, don't ask
yourself: ask a Jew.")
My previous employer sold its software to a lot of government sites. Walei
Sabry, the New York City Digital Accessibility Coordinator, came into our
office for half a day and talked about how we should and shouldn't do
things. He also demonstrated his screen reader JAWS for us (none of us
could understand a single word it said). It was hugely useful and gave us
programmers accessibility tasks for the next month.
> So, I started looking at the spec for GemText. Links one on each line, I
> could do that. No italics or bold, but people are used to seeing *this*
> anyways, or even /this/ for better ergonomics (for me anyways)
>
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.
> 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.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me. I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/6a2e
d826/attachment-0001.htm>
Answers inline:
Devin Prater
r.d.t.prater at gmail.com
> On Feb 25, 2021, at 2:14 PM, John Cowan <cowan at ccil.org> wrote:
>
>
>
> On Thu, Feb 25, 2021 at 2:42 PM Devin Prater <r.d.t.prater at gmail.com
<mailto:r.d.t.prater at gmail.com>> wrote:
>
> I am a blind person who is interested in all kinds of different ways of
working with text and writing.
>
> Thank you very much for participating: accessibility is always best
discussed when a person who needs it is actually in the room. ("If you
want to know how much antisemitism there is in your country, don't ask
yourself: ask a Jew.")
>
> My previous employer sold its software to a lot of government sites.
Walei Sabry, the New York City Digital Accessibility Coordinator, came
into our office for half a day and talked about how we should and
shouldn't do things. He also demonstrated his screen reader JAWS for us
(none of us could understand a single word it said). It was hugely useful
and gave us programmers accessibility tasks for the next month.
Fortunately, text-to-speech engines have progressed a lot since 2001 or
so. Except JAWS /still/ uses a robotic voice (ETI Eloquence) because blind
people are used to it. :)
> So, I started looking at the spec for GemText. Links one on each line, I
could do that. No italics or bold, but people are used to seeing *this*
anyways, or even /this/ for better ergonomics (for me anyways)
>
> 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.
>
>
> John Cowan http://vrici.lojban.org/~cowan
<http://vrici.lojban.org/~cowan> cowan at ccil.org <mailto:cowan at ccil.org>
> I am he that buries his friends alive and drowns them and draws them
> alive again from the water. I came from the end of a bag, but no bag
> went over me. I am the friend of bears and the guest of eagles. I am
> Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/ca28
d6e4/attachment.htm>
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 decide to explore the content or skip it? Thank you very much for your email! There is definitely a need to improve the accessibility and it better to do it know than trying to change things once the protocol and formats are carved in stone. I wonder if the alternative texts (better renamed "description"?) should be mandatory for such pre-formated blocks?
Hello Devin Devin Prater writes: > So far, neither Elpher, for Emacs, or Elaho, for iOS, even show Alt Text in preformatted blocks, even if that Alt Text is there. At the very least you convinced me to add Alt Text to my few preformatted blocks. Thank you! Cheers, ~ew -- Keep it simple!
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_an d_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/adc4 5c81/attachment.htm>
On Thu, 25 Feb 2021, 21:21 Devin Prater, <r.d.t.prater at gmail.com> wrote: > 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. > I'm not sure how the world of screen-readers/similar works, but: Since Gemini is very simple (unlike the web), creation of a dedicated client is a possibility. For preformatted text, it could read out the alt-text and then query you if you want it's contents read out to you. I have no idea how creation of such a client would be, but I imagine it would be easier than makes it them for most other things. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/af1f 13d0/attachment.htm>
On 2/25/2021 11:42 AM, Devin Prater wrote: > > So, I started looking at the spec for GemText. Links one on each line, I could do that. No italics or bold, but people are used to seeing *this* anyways, or even /this/ for better ergonomics (for me anyways) and Org-mode fans. No tags to worry about, either! Hi Devin, There's /e/, which you can look up here: https://en.wikipedia.org/wiki//e/_(operating_system) It's basically a fork of LineageOS. And it is the most horrendous thing to try to type into a search bar that I think I have ever experienced. I guess I was half asleep though, when someone asked me how to pronounce it. Being a Ham Radio operator, and not very alert, I just transliterated it and told my friend, "Oh, it's pronounced Marky Mark." > > But then we get to preformatted blocks, and the dreaded Ascii graphics. This is what I?ve always disliked about all plain text mediums. MUD?s use Ascii maps and compass and all that. Gopher uses Ascii graphics. And now Gemini too. Sure, it?s wrapped up in a pretty block, but as I?ll discuss in a moment, that isn?t necessarily helpful. > The Author of Ariane, an Android Gemini app available from F-Droid, was himself lamenting ASCII art images in Gemini recently from his Fediverse account. I solicited a response from him but to date have heard absolutely nothing from him. But here's what I did in the meantime. ```ASCII-art blah blah blah content content content ``` Now, that's a stopgap, and at this time a kludge, but anyone who uses Vger on a regular basis will quickly come to realize that I put those strings there, and hopefully that can help? maybe there's a way to set the reader to ignore between those backticks when the so-called ALT tag says that the server is about to spam you with an unintelligible character barrage? Well, I had been meaning to bring it up to the list here, but wanted to hear back first from someone who, as a developer, expressed a real interest in proposing a convention, some sort of handler, perhaps, to accommodate the non-sighted readership. I guess the dev was just lamenting the irritation and so without his participation I suppose now is as good a time as any to bring that up. Basically, an identifier in the so-called ALT tag portion that any reader can key off of to skip the block in between? It seems like a very simple and elegant solution to me that some clients could incorporate by mere convention. ASCII-art might be too narrow of a definition too. Perhaps something like: ```skip-block: Any random description to follow blah blah content content ``` so that anything with a string such as 'skip-block:' would cause the reader to just ignore that like it was a comment? Okay, I keep saying I'm goin' down for a nap. Now I really am lolz. -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
Le 2021-02-25 22:34, Oliver Simmons a ?crit : > On Thu, 25 Feb 2021, 21:21 Devin Prater, <r.d.t.prater at gmail.com> > wrote: > >> 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. > > I'm not sure how the world of screen-readers/similar works, but: > Since Gemini is very simple (unlike the web), creation of a dedicated > client is a possibility. > > For preformatted text, it could read out the alt-text and then query > you if you want it's contents read out to you. > > I have no idea how creation of such a client would be, but I imagine it > would be easier than makes it them for most other things. as far as I know there is a command line programe line oriented that is commonly used in the accessibility area: => http://edbrowse.org/ the edbrowse command line editor browser adding gemini capability may be a good idea
On 25-Feb-2021 19:42, Devin Prater wrote: > 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. Hello - GemiNaut author here. I'd be interested to understand further how to make GemiNaut more accessible.? As you have seen it uses an HTML renderer for the GUI layer, so in theory I'd expect it would be possible to have good accessibility to allow skipping over the preformatted areas. How is this done for well behaved websites, where you want to specify an area that the user can skip over? Is there a standard way this is done? An initial search suggests to use |aria-hidden="true" as an element attribute to hide it from screen readers.| This is not my area of expertise, so I'm happy to follow up any pointers or take pull requests. Feel free to write to me off the list if you prefer. ?- Luke
On Thu, 2021-02-25 at 13:36 -0800, Bradley D. Thornton wrote: > Basically, an identifier in the so-called ALT tag portion that any > reader can key off of to skip the block in between? > so that anything with a string such as 'skip-block:' would cause the > reader to just ignore that like it was a comment? HTTP uses `aria-hidden="true"`. We obviously don't need to use the `="true"` part, but I think we should use 'aria-hidden' as the alt text instead of 'skip-block'. -- u9000 (Nine) They, Them, Theirs
Hello, I share my experience here as I'm legally blind and I use screen reader. ASCII Art can be tricky but there are two ways for blind people (and I use the both). The first one is text to speech and it's really confusing. The second is refreshable braille devices. But I need to interpret the character with its visual form to understand. And this device can display only one row, it's few. The best will be like HTML navigation, interpreting the structure of the document. With Orca on a web browser, I can use following keys : - p to go to the next paragraph ; - 1 to go to the next heading of level 1 ; - 2 (to 6) to go to the next heading of level 2 (to 6) ; - h to go to the next heading, with any level ; - l to go to the next link ; - ... All this behavior is defined using the accessibility bus (at-spi on Linux). Only Gemini clients can implement it. But, I don't think a dedicated client is a good idea. Dedicated software is rarely maintained correctly, and developers of other clients don't know all the problems of accessibility. This can create a gap about comprehension of needs. In other way, be visually impaired can be no vision or a little vision. So, see the ASCII Art can be a good thing even if a screen reader is needed (that's my case). I hope an alternative text for next version of specification. Have a good day ! Le 21.02.25, Oliver Simmons a ?crit : > On Thu, 25 Feb 2021, 21:21 Devin Prater, <[1]r.d.t.prater at gmail.com> > wrote: > > 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. > > I'm not sure how the world of screen-readers/similar works, but: > Since Gemini is very simple (unlike the web), creation of a dedicated > client is a possibility. > For preformatted text, it could read out the alt-text and then query you > if you want it's contents read out to you. > I have no idea how creation of such a client would be, but I imagine it > would be easier than makes it them for most other things. > > References > > Visible links > 1. mailto:r.d.t.prater at gmail.com -- Kujiu https://www.kujiu.org gemini://kujiu.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/4a9b 6f00/attachment.sig>
It was thus said that the Great Bradley D. Thornton once stated: > On 2/25/2021 11:42 AM, Devin Prater wrote: > > > But then we get to preformatted blocks, and the dreaded Ascii graphics. > > This is what I?ve always disliked about all plain text mediums. MUD?s > > use Ascii maps and compass and all that. Gopher uses Ascii graphics. And > > now Gemini too. Sure, it?s wrapped up in a pretty block, but as I?ll > > discuss in a moment, that isn?t necessarily helpful. > > The Author of Ariane, an Android Gemini app available from F-Droid, was > himself lamenting ASCII art images in Gemini recently from his Fediverse > account. > > I solicited a response from him but to date have heard absolutely > nothing from him. But here's what I did in the meantime. > > ```ASCII-art blah blah blah > > content > content > content > ``` I might suggest something like: preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line tag = '@art' / '@code' / '@data' / '@poem' Some examples: ``` @code x = 5 ``` ``` @art Obligatory Cat picture cat ``` ``` @data Price list widget 3.45 gadget 5.99 fob 1.99 ``` ``` @poem There once was a person from Nantucket ... ``` ``` Just some regular alt-text blah ``` ``` nothing special here ``` The '@tag' format marks out the tag, which I expressly limited to just four categories for simplicity---one to mark ASCII (or maybe UTF-8?) art, one for code samples, one for tabular data and one for poetry. It's not mandatory, but it could help a client decide how to handle the block. -spc
Hello Davin, welcome to Gemini and to this mailing list! Thank you for your insight from the perspective of a screen reader user. As a future developer of a Gemini client I'll take your word into account when dealing with preformatted blocks of text and as a content creator I'll now consider whether to use alt text at the beginning of preformatted banners or to stop using them altogether. I only use one at the top of my Gemini capsule and gopher hole, with a large version of the title of my sites. At least on Gemini maybe it makes more sense to use simply a first level header, which is already rendered as bigger text on graphical browsers anyway. I have a question for you. I don't use ASCII art on my banner, instead I use ANSI art. Basically I draw the title of my capsule with ANSI block characters, instead of alphanumeric characters. How do screen readers typically handle this? Is it less or more problematic than ASCII? I wonder if screen readers skip it or repeat something like "block" for every character, which would obviously be extremely annoying. In case you need a capsule to test this, my Gemini capsule starts with an ANSI banner: gemini://gluonspace.com/ I believe that most of us enjoy Gemini for a common reason, which is the fact that it serves content instead of format. At the end of the day, that's what really matters, no matter whether we use screen readers or not. -- Vasco Costa AKA gluon. Enthusiastic about computers, motorsports, science, technology, travelling and TV series. Yes I'm a bit of a geek. Gemini: gemini://gluonspace.com/ Gopher: gopher://gopher.geeksphere.tk/
On Thu, 25 Feb 2021 22:41:03 +0000 Vasco Costa <vasco.costa at gmx.com>: > Hello Davin, welcome to Gemini and to this mailing list! > > Thank you for your insight from the perspective of a screen reader user. > As a future developer of a Gemini client I'll take your word into > account when dealing with preformatted blocks of text and as a content > creator I'll now consider whether to use alt text at the beginning of > preformatted banners or to stop using them altogether. > > I only use one at the top of my Gemini capsule and gopher hole, with a > large version of the title of my sites. At least on Gemini maybe it > makes more sense to use simply a first level header, which is already > rendered as bigger text on graphical browsers anyway. > > I have a question for you. I don't use ASCII art on my banner, instead I > use ANSI art. Basically I draw the title of my capsule with ANSI block > characters, instead of alphanumeric characters. How do screen readers > typically handle this? Is it less or more problematic than ASCII? I > wonder if screen readers skip it or repeat something like "block" for > every character, which would obviously be extremely annoying. In case > you need a capsule to test this, my Gemini capsule starts with an ANSI > banner: > > gemini://gluonspace.com/ > > I believe that most of us enjoy Gemini for a common reason, which is the > fact that it serves content instead of format. At the end of the day, > that's what really matters, no matter whether we use screen readers or > not. > > -- > Vasco Costa > > AKA gluon. Enthusiastic about computers, motorsports, science, > technology, travelling and TV series. Yes I'm a bit of a geek. > > Gemini: gemini://gluonspace.com/ > Gopher: gopher://gopher.geeksphere.tk/ You can install espeak and pipe your gemtext file to espeak and hear the result. Espeak should be available on every major system.
On Thu, Feb 25, 2021 at 05:25:08PM -0500, Sean Conner wrote: > I might suggest something like: > > preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line > tag = '@art' / '@code' / '@data' / '@poem' > > Some examples: > >``` @code >x = 5 >``` > >``` @art Obligatory Cat picture >cat >``` > >``` @data Price list >widget 3.45 >gadget 5.99 >fob 1.99 >``` > >``` @poem >There once was a person from Nantucket ... >``` > >``` Just some regular alt-text >blah >``` > >``` >nothing special here >``` I think that a small but significant change to the spec is necessary here. My proposal: - Three backticks signify readable preformatted text (e.g. a code snippet or a poem); screen-readers should not skip this. - Four backticks signify something that isn't readable, like ascii-art. This is consistent with the spirit of gemtext: characters at the beginning of a line are the only way to describe semantics. Benefits of this proposal: - It doesn't break any existing sites; it just adds one feature. - It's very simple to implement: parsers scan for a single additional backtick - Authors can still provide any alt-text they wish without worrying about "reserved words" like the proposed tags - It provides *critical* semantic information: whether or not a block of preformatted text should be treated as readable text. I'm generally against gemtext spec changes, but I think this is necessary for screenreader-friendliness. -- /Seirdy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/608d c54c/attachment.sig>
On Thu, 25 Feb 2021 15:08:50 -0800 Rohan Kumar <seirdy at seirdy.one>: > On Thu, Feb 25, 2021 at 05:25:08PM -0500, Sean Conner wrote: > > I might suggest something like: > > > > preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line > > tag = '@art' / '@code' / '@data' / '@poem' > > > > Some examples: > > > >``` @code > >x = 5 > >``` > > > >``` @art Obligatory Cat picture > >cat > >``` > > > >``` @data Price list > >widget 3.45 > >gadget 5.99 > >fob 1.99 > >``` > > > >``` @poem > >There once was a person from Nantucket ... > >``` > > > >``` Just some regular alt-text > >blah > >``` > > > >``` > >nothing special here > >``` > > I think that a small but significant change to the spec is necessary > here. My proposal: > > - Three backticks signify readable preformatted text (e.g. a code > snippet or a poem); screen-readers should not skip this. > - Four backticks signify something that isn't readable, like ascii-art. > > This is consistent with the spirit of gemtext: characters at the > beginning of a line are the only way to describe semantics. > > Benefits of this proposal: > > - It doesn't break any existing sites; it just adds one feature. > - It's very simple to implement: parsers scan for a single additional > backtick > - Authors can still provide any alt-text they wish without worrying > about "reserved words" like the proposed tags > - It provides *critical* semantic information: whether or not a block of > preformatted text should be treated as readable text. > > I'm generally against gemtext spec changes, but I think this is > necessary for screenreader-friendliness. > I don't have a strong opinion about adding something like this, but if it has to be done, please use another character than ` It's hard to differenciate between ``` to ```` and this may confuse people, and people writing content may misuse them. I think keeping ``` like it is now is fine and adding a new syntax would need another character like @@@ or %%% to make more sense. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Signature digitale OpenPGP URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/b45e b2c5/attachment.sig>
Just to correct my typo about your name. Devin* -- Vasco Costa AKA gluon. Enthusiastic about computers, motorsports, science, technology, travelling and TV series. Yes I'm a bit of a geek. Gemini: gemini://gluonspace.com/ Gopher: gopher://gopher.geeksphere.tk/
On Thu, 2021-02-25 at 17:25 -0500, Sean Conner wrote: > It was thus said that the Great Bradley D. Thornton once stated: > > On 2/25/2021 11:42 AM, Devin Prater wrote: > > > But then we get to preformatted blocks, and the dreaded Ascii > > > graphics. This is what I?ve always disliked about all plain text > > > mediums. Sure, it?s wrapped up in a pretty block, but as I?ll > > > discuss in a moment, that isn?t necessarily helpful. > > > > I solicited a response from him but to date have heard absolutely > > nothing from him. But here's what I did in the meantime. > > > > ```ASCII-art blah blah blah > > > > content > > content > > content > > ``` > > ? I might suggest something like: > > ????????preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line > ????????tag?????? = '@art' / '@code' / '@data' / '@poem' Maybe 'poem' should be 'poetry'; it's the only tag there which is quantity-specific. What do you guys think about this/the name(s)? > ? The '@tag' format marks out the tag, which I expressly limited to > just four categories for simplicity---one to mark ASCII (or maybe UTF- > 8?) art, one for code samples, one for tabular data and one for > poetry.?It's not mandatory, but it could help a client decide how to > handle the block. I like the idea of further giving control over how content is displayed to clients instead of authors, however I think '@tag' might make a document look very marked up in clients that don't remove the '```'. Perhaps '#tag' would look more normal? ``` Obligatory Cat picture #art cat ```
On Thu, Feb 25, 2021 at 3:29 PM Devin Prater <r.d.t.prater at gmail.com> wrote: Except JAWS /still/ uses a robotic voice (ETI Eloquence) because blind > people are used to it. :) > It was not about how robotic it is, but about how fast it is. He demonstrated it at 3x speed for us, but when he was using it just for himself, it was 5x. > I meant ergonomic as in easy to type. > Ah. Of course that depends on the keyboard: on the French (not Canadian French) keyboard, / is shifted, but * requires right Alt. I don't understand what the benefit of the alt text "Python" is here. Presumably if you are reading a document with embedded Python, you are expected to, and want to, read the Python, just as if you have an (English) document with embedded Greek, you probably want to read the Greek. All of these are text that you read, as opposed to images that you look at, which it makes sense to suppress. For that matter, I might suppress them myself, as I am still non-visual even though I now see perfectly, since I grew up seeing everything as blurred: seeing is *not* believing for me, unlike most of the sighted. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/74cc efb3/attachment-0001.htm>
On Thu, Feb 25, 2021 at 5:25 PM Sean Conner <sean at conman.org> wrote: > tag = '@art' / '@code' / '@data' / '@poem' > We now know what the benefit of @art is. What are the advantages of the other three over no tag? > ``` @code > x = 5 > ``` > Shouldn't this be read as if it were "ex equals five"? ``` @art Obligatory Cat picture > cat > ``` > Right. > ``` @data Price list > widget 3.45 > gadget 5.99 > fob 1.99 > ``` > Shouldn't this be read as "widget one ninety-nine (pause) gadget five ninety-nine (pause) fob one ninety-nine"? How might a visual browser render it differently? > > ``` @poem > There once was a person from Nantucket ... > ``` How might a visual browser render this differently? The '@tag' format marks out the tag, which I expressly limited to just > four categories for simplicity---one to mark ASCII (or maybe UTF-8?) art, > UTF-8 for sure, although some characters aren't monowidth even in monowidth fonts. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org "But I am the real Strider, fortunately," he said, looking down at them with his face softened by a sudden smile. "I am Aragorn son of Arathorn, and if by life or death I can save you, I will." -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/fd83 0374/attachment.htm>
On Thu, Feb 25, 2021 at 6:24 PM Solene Rapenne <solene at perso.pw> wrote: > I don't have a strong opinion about adding something like this, > but if it has to be done, please use another character than ` > > It's hard to differenciate between ``` to ```` and this may confuse > people, and people writing content may misuse them. > Agreed. But if we make it ```x, where x is some character, then we don't have to introduce a new line type: it's just a convention about alt-text. I did a little Google search for ["alt-text" -image -images] and there is nothing except other senses of "alt text". I also note that in HTML5, the "alt" attribute is for the img, area, and input (graphical button) elements only. There is no notion of text with alt text. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The experiences of the past show that there has always been a discrepancy between plans and performance. --Emperor Hirohito, August 1945 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/ef0b a155/attachment.htm>
On Thu, Feb 25, 2021, at 5:40 PM, John Cowan wrote: > > I don't understand what the benefit of the alt text "Python" is here. Presumably if you are reading a document with embedded Python, you are expected to, and want to, read the Python, just as if you have an (English) document with embedded Greek, you probably want to read the Greek. > That kind of thing is for <https://pygments.org/> and similar code colorizers. >From The Spec (emphasis added): > Alt text may **also** be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting. I'm not _too_ pleased by how we're using one field for two different things (one is a description; the other is a thing for dumb parsers), but that's the spec we've got. Previously, on this list, we discussed having the alt text be on the first
that particular discussion other than some try-outs in a vacuum.
=> messages/005658.gmi Link to individual message. ## 24. John Cowan (cowan (a) ccil.org)
On Thu, Feb 25, 2021 at 9:27 PM Nathan Galt <mailinglists at ngalt.com> wrote:
From The Spec (emphasis added):
> Alt text may **also** be used for computer source code to identify the
programming language which advanced clients may use for syntax highlighting
Ah. Well, that certainly doesn't help blind people, nor does it help me (I
view text as black print on white paper, as God and Gutenberg intended!).
Still, I see why some people might want it. Then again, I see why some
people (definitely including me!) would want italics.
.Previously, on this list, we discussed having the alt text be on the
first ``` and parser hints be on the last ```, but I'm not sure anything
came of that particular discussion other than some try-outs in a vacuum.
Well, The Spec also says that alt-text in the closing preformat line MUST
be ignored by clients.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Dream projects long deferred usually bite the wax tadpole.
--James Lileks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210225/91e2
f737/attachment-0001.htm>
=> messages/005659.gmi Link to individual message. ## 25. Sean Conner (sean (a) conman.org)
It was thus said that the Great Rohan Kumar once stated:
On Thu, Feb 25, 2021 at 05:25:08PM -0500, Sean Conner wrote:
> I might suggest something like:
>
> preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
> tag = '@art' / '@code' / '@data' / '@poem'
>
I think that a small but significant change to the spec is necessary
here. My proposal:
The proposal above does not require a change in the specification for
text/gemini, and could be considered a convention used.
- Three backticks signify readable preformatted text (e.g. a code
snippet or a poem); screen-readers should not skip this.
- Four backticks signify something that isn't readable, like ascii-art.
I picked a format that should be easy to find, with a limited set of
options that, in my opinion, seem to cover the majority of cases with
preforamtted blocks. Again with some examples, only with alt-text and NOT
with my proposal:
``` Python
Python! There in the grass,
ready to slide right up my ...
```
``` Python
____ _ _
| _ \ _ _| |_| |__ ___ _ __
| |_) | | | | _| '_ \ / _ \| ._ \
| __/| |_| | |_| | | | (_) | | | |
|_| \_, |\__|_| |_|\___/|_| |_|
|___/
```
``` Python
@app.route('/')
def index[]:
try:
session['num']
except:
session['success'] = False
session['num'] = random.randrager(1,100)
return render_template('index.html')
```
``` Python
Genus #species common name
-------------------------------------------
Antaresia 4 Children's phythons
Apodora 1 Papaun olive python
Aspidites 2 Sheild pythons
Bothrochilus 1 Bismark ringed python
Liasis 3 water pythons
```
I think that '@poem', '@art', '@code' and '@data' would be very helpful to
a client program. Adding an additional backtick for "something that isn't
readble" just seems too little.
But anyone arguing for (or against) this, please feel free to use the
above Python examples when making arguments.
This is consistent with the spirit of gemtext: characters at the
beginning of a line are the only way to describe semantics.
Benefits of this proposal:
- It doesn't break any existing sites; it just adds one feature.
- It's very simple to implement: parsers scan for a single additional
backtick
- Authors can still provide any alt-text they wish without worrying
about "reserved words" like the proposed tags
Which of the above blocks should be read, and shouldn't be read?
- It provides *critical* semantic information: whether or not a block of
preformatted text should be treated as readable text.
Not enough in my opinion.
-spc
=> messages/005660.gmi Link to individual message. ## 26. Devin Prater (r.d.t.prater (a) gmail.com)
Thanks for your interest. Frames are the one thing I've seen that screen
readers most treat as a "container" that can be skipped. So, have the
blocks with a roll of frame, that is, the <iframe> roll if possible, or
just make them <iframe> if possible. I'm more of a user than a
developer, sorry. Other than that, GemiNaut, as far as I've used it,
works great. I'll stress test it more in the coming weeks and get back
to you if I find anything else.
On 2/25/21 3:52 PM, Luke Emmet wrote:
On 25-Feb-2021 19:42, Devin Prater wrote:
> 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.
Hello - GemiNaut author here. I'd be interested to understand further
how to make GemiNaut more accessible.? As you have seen it uses an
HTML renderer for the GUI layer, so in theory I'd expect it would be
possible to have good accessibility to allow skipping over the
preformatted areas.
How is this done for well behaved websites, where you want to specify
an area that the user can skip over? Is there a standard way this is
done?
An initial search suggests to use |aria-hidden="true" as an element
attribute to hide it from screen readers.|
This is not my area of expertise, so I'm happy to follow up any
pointers or take pull requests. Feel free to write to me off the list
if you prefer.
?- Luke
=> messages/005661.gmi Link to individual message. ## 27. Devin Prater (r.d.t.prater (a) gmail.com)
Okay, these are a bit more chatty, speaking:
"full block full block full block full block full block full block em
quad full block full block em quad ..."
You get the idea. Yes, headings are useful, and I'm so glad Gemini
provides just enough structure to be helpful and useful, but not enough
to be annoying.
On 2/25/21 4:41 PM, Vasco Costa wrote:
Hello Davin, welcome to Gemini and to this mailing list!
Thank you for your insight from the perspective of a screen reader user.
As a future developer of a Gemini client I'll take your word into
account when dealing with preformatted blocks of text and as a content
creator I'll now consider whether to use alt text at the beginning of
preformatted banners or to stop using them altogether.
I only use one at the top of my Gemini capsule and gopher hole, with a
large version of the title of my sites. At least on Gemini maybe it
makes more sense to use simply a first level header, which is already
rendered as bigger text on graphical browsers anyway.
I have a question for you. I don't use ASCII art on my banner, instead I
use ANSI art. Basically I draw the title of my capsule with ANSI block
characters, instead of alphanumeric characters. How do screen readers
typically handle this? Is it less or more problematic than ASCII? I
wonder if screen readers skip it or repeat something like "block" for
every character, which would obviously be extremely annoying. In case
you need a capsule to test this, my Gemini capsule starts with an ANSI
banner:
gemini://gluonspace.com/
I believe that most of us enjoy Gemini for a common reason, which is the
fact that it serves content instead of format. At the end of the day,
that's what really matters, no matter whether we use screen readers or
not.
--
Vasco Costa
AKA gluon. Enthusiastic about computers, motorsports, science,
technology, travelling and TV series. Yes I'm a bit of a geek.
Gemini: gemini://gluonspace.com/
Gopher: gopher://gopher.geeksphere.tk/
=> messages/005662.gmi Link to individual message. ## 28. Sean Conner (sean (a) conman.org)
It was thus said that the Great John Cowan once stated:
On Thu, Feb 25, 2021 at 5:25 PM Sean Conner <sean at conman.org> wrote:
> tag = '@art' / '@code' / '@data' / '@poem'
We now know what the benefit of @art is. What are the advantages of the
other three over no tag?
A client could style each type differently, even if just a subtle change
in background color. Or even different monospaced fonts depending upon
usage.
> ``` @code
> x = 5
> ```
Shouldn't this be read as if it were "ex equals five"?
I didn't want to get too wild with the examples, but yes, that sounds fine
to me.
``` @art Obligatory Cat picture
> cat
> ```
Right.
Didn't want to bother trying to draw an ASCII cat.
> ``` @data Price list
> widget 3.45
> gadget 5.99
> fob 1.99
> ```
Shouldn't this be read as "widget one ninety-nine (pause) gadget five
ninety-nine (pause) fob one ninety-nine"?
It could even be "Row one widget one ninety-nine (pause) row two gadget
five ninety-nine (pause) row three fob one ninety-nine" but I can see the
repeated "row x" could get tiresome.
How might a visual browser
render it differently?
How about alternating light and dark background for each row? I mean, it
doesn't have to be a jarring contrast like black background/white
background, but black background/dark grey background, just to help visually
separate the records.
> ``` @poem
> There once was a person from Nantucket ...
> ```
How might a visual browser render this differently?
No idea on this one, but a screen reader, in theory, could switch voices
for reading poetry.
I don't expect this to be standardized any time soon in the spec, as the
spec for text/gemini is line oriented and less with parsing the data in each
line. But I can certainly see this as something clients slowly converge on,
much like gopher clients supporting selector types not specified in
RFC-1436.
And the spec does say, "MAY be interpreted ... "
-spc
=> messages/005663.gmi Link to individual message. ## 29. Solene Rapenne (solene (a) perso.pw)
On Thu, 25 Feb 2021 19:16:45 -0500
"u9000 (Nine)" <u9000 at posteo.mx>:
On Thu, 2021-02-25 at 17:25 -0500, Sean Conner wrote:
> It was thus said that the Great Bradley D. Thornton once stated:
> > On 2/25/2021 11:42 AM, Devin Prater wrote:
> > > But then we get to preformatted blocks, and the dreaded Ascii
> > > graphics. This is what I?ve always disliked about all plain text
> > > mediums. Sure, it?s wrapped up in a pretty block, but as I?ll
> > > discuss in a moment, that isn?t necessarily helpful.
> >
> > I solicited a response from him but to date have heard absolutely
> > nothing from him. But here's what I did in the meantime.
> >
> > ```ASCII-art blah blah blah
> >
> > content
> > content
> > content
> > ```
>
> ? I might suggest something like:
>
> ????????preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
> ????????tag?????? = '@art' / '@code' / '@data' / '@poem'
Maybe 'poem' should be 'poetry'; it's the only tag there which is
quantity-specific. What do you guys think about this/the name(s)?
> ? The '@tag' format marks out the tag, which I expressly limited to
> just four categories for simplicity---one to mark ASCII (or maybe UTF-
> 8?) art, one for code samples, one for tabular data and one for
> poetry.?It's not mandatory, but it could help a client decide how to
> handle the block.
I like the idea of further giving control over how content is displayed
to clients instead of authors, however I think '@tag' might make a
document look very marked up in clients that don't remove the '```'.
Perhaps '#tag' would look more normal?
``` Obligatory Cat picture #art
cat
```
Asking people to write English words in their capsule is not
nice. I'm against the use of words like this to define a
content, convention or not.
While this may sound ridiculous to people from the mailing list
because we have to speak English here, that doesn't mean Gemini
writers will understand English. So far, gemtext only requires to
use some symbols. There are enough English everywhere, no need to
add some into gemtext.
=> messages/005664.gmi Link to individual message. ## 30. Vasco Costa (vasco.costa (a) gmx.com)
On Thu, Feb 25, 2021 at 09:03:49PM -0600, Devin Prater wrote:
Okay, these are a bit more chatty
Thanks for the input.
You get the idea. Yes, headings are useful, and I'm so glad Gemini
provides just enough structure to be helpful and useful, but not enough
to be annoying.
Exactly. Headings and lists are two examples of structure that don't
annoy anyone and help with content organisation, instead of simply
providing aesthetics.
=> messages/005665.gmi Link to individual message. ## 31. Sean Conner (sean (a) conman.org)
It was thus said that the Great Solene Rapenne once stated:
> On Thu, 2021-02-25 at 17:25 -0500, Sean Conner wrote:
> >
> > ? I might suggest something like:
> >
> > ????????preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
> > ????????tag?????? = '@art' / '@code' / '@data' / '@poem'
Asking people to write English words in their capsule is not
nice. I'm against the use of words like this to define a
content, convention or not.
While this may sound ridiculous to people from the mailing list
because we have to speak English here, that doesn't mean Gemini
writers will understand English. So far, gemtext only requires to
use some symbols. There are enough English everywhere, no need to
add some into gemtext.
Fair point. How about:
@sitelen
@ilo
@nanpa
@lipu
It's from a constructed language so there are (at least for now) no native
speakers of this language (hint: it's not Esperanto, nor Klingon).
-spc
=> messages/005666.gmi Link to individual message. ## 32. Philip Linde (linde.philip (a) gmail.com)
On Thu, 25 Feb 2021 17:25:08 -0500
Sean Conner <sean at conman.org> wrote:
I might suggest something like:
preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
tag = '@art' / '@code' / '@data' / '@poem'
What is the need for formalizing this? The alt text as currently
specified can easily be used to describe the content of the section in
plain words that read as-is by a screen reader would give the
non-sighted user an indication of what comes next and whether they
might want to skip it.
I can see from the follow-up discussion that you don't primarily intend
for these tags to aid in accessibility, but to allow minor adjustments
to visual presentation. I think that instead of shoehorning this
suggestion for a spec change into a discussion about accessibility in
clients you should post it with a new subject so as to avoid taking an
important discussion in an entirely unrelated direction.
I think you recognize the difference between "it would be cool if the
spec was changed so that a client could display a code block in a
different color shade than a poem" and "it would be cool if [Clients]
allowed non-sighted users to browse Gemini effectively".
--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/d86b
222f/attachment.sig>
=> messages/005685.gmi Link to individual message. ## 33. Stephane Bortzmeyer (stephane (a) sources.org)
On Fri, Feb 26, 2021 at 08:59:48AM +0100,
Solene Rapenne <solene at perso.pw> wrote
a message of 59 lines which said:
Asking people to write English words in their capsule is not nice.
I'm against the use of words like this to define a content,
convention or not.
OK, inspired by my past life as a Perl programmer, I suggest a fully
i18n solution:
```@ (ASCII art)
```$ (Code)
```% (poetry)
```| (data)
:-)
=> messages/005688.gmi Link to individual message. ## 34. Petite Abeille (petite.abeille (a) gmail.com)
On Feb 26, 2021, at 14:07, Philip Linde <linde.philip at gmail.com> wrote:
What is the need for formalizing this?
What is the need to formalize /any/ of Gemini?! What's the point of any of
the current discussions? TGIF entertainment?
No progress has been made whatsoever in even attempting to formally
specify the most basic aspect of Gemini. Nothing. Nada. Zero.
And Solderpunk is MIA for months.
And the kids are running amok.
Nicely done Gemini.
?0?
=> messages/005687.gmi Link to individual message. ## 35. Petite Abeille (petite.abeille (a) gmail.com)
On Feb 26, 2021, at 14:14, Stephane Bortzmeyer <stephane at sources.org> wrote:
```@ (ASCII art)
```$ (Code)
```% (poetry)
```| (data)
Fantastic :)
There are always the Egyptian Hieroglyphs (Unicode block) if you run out
of US-ASCII symbols:
https://en.wikipedia.org/wiki/Egyptian_Hieroglyphs_(Unicode_block)
?0?
=> messages/005690.gmi Link to individual message. ## 36. Philip Linde (linde.philip (a) gmail.com)
On Fri, 26 Feb 2021 14:17:34 +0100
Petite Abeille <petite.abeille at gmail.com> wrote:
> On Feb 26, 2021, at 14:07, Philip Linde <linde.philip at gmail.com> wrote:
>
> What is the need for formalizing this?
What is the need to formalize /any/ of Gemini?! What's the point of any
of the current discussions? TGIF entertainment?
The point of this discussion was to figure out how clients can make
pre-formatted sections more accessible to blind users. Under the
subject "[Clients] Gemini and accessibility regarding preformatted code
blocks" I think we should stick to that topic. As such, I've changed
the subject line to reflect the topic of this branch. That way people
can easily see that this discussion is completely irrelevant to the
original topic, and they can more promptly ignore it to make productive
use of their time.
--
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/60a9
2ceb/attachment.sig>
=> messages/005700.gmi Link to individual message. ## 37. Petite Abeille (petite.abeille (a) gmail.com)
On Feb 26, 2021, at 14:45, Philip Linde <linde.philip at gmail.com> wrote:
promptly ignore it to make productive use of their time.
mwahahaha... :)
Sir, I salute you, and thank you for your service. You are an example ?and
an inspiration? to us all.
Thank you.
?0?
=> messages/005701.gmi Link to individual message. ## 38. Devin Prater (r.d.t.prater (a) gmail.com)
Regarding changes to voices based on content type, screen readers don?t
switch voices for poetry or anything, unless something like SSML is used.
Even then, the screen reader must support sending the SSML directly to the
speech synthesizer, and the speech synthesizer must support SSML.
Otherwise, everything is plain text, with no variation on speech or
anything besides normal clause pauses and such.
https://www.w3.org/TR/speech-synthesis11/
<https://www.w3.org/TR/speech-synthesis11/> SSML
Devin Prater
r.d.t.prater at gmail.com
On Feb 25, 2021, at 11:31 PM, Sean Conner <sean at conman.org> wrote:
It was thus said that the Great John Cowan once stated:
> On Thu, Feb 25, 2021 at 5:25 PM Sean Conner <sean at conman.org> wrote:
>
>> tag = '@art' / '@code' / '@data' / '@poem'
>
> We now know what the benefit of @art is. What are the advantages of the
> other three over no tag?
A client could style each type differently, even if just a subtle change
in background color. Or even different monospaced fonts depending upon
usage.
>> ``` @code
>> x = 5
>> ```
>
> Shouldn't this be read as if it were "ex equals five"?
I didn't want to get too wild with the examples, but yes, that sounds fine
to me.
> ``` @art Obligatory Cat picture
>> cat
>> ```
>
> Right.
Didn't want to bother trying to draw an ASCII cat.
>> ``` @data Price list
>> widget 3.45
>> gadget 5.99
>> fob 1.99
>> ```
>
> Shouldn't this be read as "widget one ninety-nine (pause) gadget five
> ninety-nine (pause) fob one ninety-nine"?
It could even be "Row one widget one ninety-nine (pause) row two gadget
five ninety-nine (pause) row three fob one ninety-nine" but I can see the
repeated "row x" could get tiresome.
> How might a visual browser
> render it differently?
How about alternating light and dark background for each row? I mean, it
doesn't have to be a jarring contrast like black background/white
background, but black background/dark grey background, just to help visually
separate the records.
>> ``` @poem
>> There once was a person from Nantucket ...
>> ```
>
> How might a visual browser render this differently?
No idea on this one, but a screen reader, in theory, could switch voices
for reading poetry.
I don't expect this to be standardized any time soon in the spec, as the
spec for text/gemini is line oriented and less with parsing the data in each
line. But I can certainly see this as something clients slowly converge on,
much like gopher clients supporting selector types not specified in
RFC-1436.
And the spec does say, "MAY be interpreted ... "
-spc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/0bc5
644f/attachment-0001.htm>
=> messages/005703.gmi Link to individual message. ## 39. Bradley D. Thornton (Bradley (a) NorthTech.US)
On 2/25/2021 6:51 PM, Sean Conner wrote:
It was thus said that the Great Rohan Kumar once stated:
> On Thu, Feb 25, 2021 at 05:25:08PM -0500, Sean Conner wrote:
>> I might suggest something like:
>>
>> preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
>> tag = '@art' / '@code' / '@data' / '@poem'
>>
>
> I think that a small but significant change to the spec is necessary
> here. My proposal:
I also saw somewhere in this thread someone suggest something that would
enable the server to dictate the delivery of how the content is
presented. I'm definitely NOT in favor of something that requires
clients to format text a certain way based on what a server says, and
further, such is contrary to the design philosophies of Gemini going
back as far as discussions in June 2019 before the first line of code
was ever written by anyone.
The proposal above does not require a change in the specification for
text/gemini, and could be considered a convention used.
Indeed. And this is an elegant solution.
It is, however, from the perspective of a developer, and as I certainly
admire its utility and I have no real issues with something like this,
I'm also thinking about the majority of people writing gemlogs. It is
asking a bit (of optional syntax) that expects an author of a page as
well as the author of a client to incorporate.
Where this may be an ideal situation, my original intent wasn't to
suggest any particular handlers, but rather, a simple convention that
to facilitate "Accessibility" for non-sighted readers.
Perhaps there are more comprehensive aspects that are beyond what I was
attempting to address for avoiding the spamnation of non-sighted
readers... So I don't really have a real preference, other than to say
whatever it is, that it be simple for someone writing a page and easy
for authors of *some* clients to accommodate.
> - Three backticks signify readable preformatted text (e.g. a code
> snippet or a poem); screen-readers should not skip this.
> - Four backticks signify something that isn't readable, like ascii-art.
I think this was a suggestion to alter the spec. As such I feel it's not
necessary to consider as such. What I suggested, indeed implemented, was
a way for a client to interpret something that follows as something that
a non-sighted reader would rather not have to endure.
I believe it was Solene that brought up the obvious, that '```' and
'````' are prone to issues. When I read what she wrote, I thought about
using a colon (:) instead, very unobtrusive for a key that could alert
keeping the readability of the raw .gmi file.
Where actual code is concerned, I think that what Sean proposed is
probably the most effective, and still by convention, not any spec
changes, but it "might" add a lot of weight to *some* clients that seek
to provide syntax highlighting.
Where poetry is concerned, I fail to see the significance at all. It's a
block of preformatted text, right? Am I missing something? Coz I fail to
see the significance between prose and poetry where preformatted text is
concerned. It certainly has no significance where accessibility is
concerned, IMO, since non-sighted readers would probably want to listen
to the poems anyway, albeit, with a really messed up cadence ;)
Just imagine yourself, surfing Gemini space, and having to listen to this:
<snip>
.-.
( (
`-'
. ,- To the Moon Alice !
.'.
|o|
.'o'.
|.-.|
' '
( )
)
( )
____
.-'""p 8o""`-.
.-'8888P'Y.`Y[ ' `-.
,']88888b.J8oo_ '`.
,' ,88888888888[" Y`.
/ 8888888888P Y8\
/ Y8888888P' ]88\
: `Y88' P `888:
: Y8.oP '- > Y88:
| `Yb __ `'|
: `'d8888bo. :
: d88888888ooo. ;
\ Y88888888888P /
\ `Y88888888P /
`. d88888P' ,'
`. 888PP' ,'
`-. d8P' ,-' -CJ-
`-.,,_'__,,.-'
</snip>
I picked a format that should be easy to find, with a limited set of
options that, in my opinion, seem to cover the majority of cases with
preforamtted blocks. Again with some examples, only with alt-text and NOT
with my proposal:
```: No text is required at all to let an accessible client opt to skip
this> ____ _ _
| _ \ _ _| |_| |__ ___ _ __
| |_) | | | | _| '_ \ / _ \| ._ \
| __/| |_| | |_| | | | (_) | | | |
|_| \_, |\__|_| |_|\___/|_| |_|
|___/
```
The following is beyond the scope of my immediate concern for agreed
upon convention by the authors of clients to enable user accessibility
for non-sighted readers. I think that here is where what Sean has
proposed comes into its own and demonstrates some real value, and, as he
points out changes nothing in the spec - but it does ask a bit of the
authors of Gemini clients who wish to enrich the presentation of syntax.
``` Python
@app.route('/')
def index[]:
try:
session['num']
except:
session['success'] = False
session['num'] = random.randrager(1,100)
return render_template('index.html')
```
This next example from Sean I want to address in more detail, so I'll do
that following the example.
``` Python
Genus #species common name
-------------------------------------------
Antaresia 4 Children's phythons
Apodora 1 Papaun olive python
Aspidites 2 Sheild pythons
Bothrochilus 1 Bismark ringed python
Liasis 3 water pythons
```
Okay Solene and I discussed something related to the above off list
briefly, and it is really on a different topic altogether, but I might
as well bring it up here because I keep seeing people asking for changes
to the spec to accommodate more markdown features, which is IMO,
problematic.
I mentioned to Solene that I thought it would be nice if more features
of Markdown were supported in clients, but that doesn't mean that it has
any business being in the Gemini specification.
Why? Because Markdown for the most part is perfectly readable even if it
isn't rendered as such (Even pretty much tables with cells, etc.).
So my use case is writing papers like showcased above with Genus and
Species like, **Flabellina iodinea** or **Cordyceps sinensis** or
italicize or underline genus and species. Now, markdown makes that nice
and easy, but most everyone already knows how to interpet "*" or "**" or
"***" or their underbar equivalents and it does nothing to detract from
the readability of the text even if it isn't rendered as bold, or
underlined, or in italics.
The one thing that I would like to see support for in clients, is the
inline preformatted text begin and end markers:
i.e., `$ rm -f /bin/laden`. But absolutely NONE of these things require
nor beg for inclusion into the Gemini spec, yet they *could* be
supported in *some* clients.
I hope that puts those discussions for the expanded use of markdown to
be included in the spec, at least for the next fortnight :)
I think that '@poem', '@art', '@code' and '@data' would be very helpful to
a client program. Adding an additional backtick for "something that isn't
readble" just seems too little.
But anyone arguing for (or against) this, please feel free to use the
above Python examples when making arguments.
Yes, thank you for making those exammples handy :)
> This is consistent with the spirit of gemtext: characters at the
> beginning of a line are the only way to describe semantics.
Indeed.
Solene also mentioned her aprehensions in using a particular language
for such tags, which I thought was very eloquently addressed by
Stephanie below:
<snip>
OK, inspired by my past life as a Perl programmer, I suggest a fully
i18n solution:
```@ (ASCII art)
```$ (Code)
```% (poetry)
```| (data)
</snip>
I really like this too! Notwithstanding my questions as to why poetry
would be relevant, and the only thing I would mention would be that I
don't actually care for the "@" sign, for to me, it usually implies
other meanings, although I get the association it may have for ASCII. I
would prefer rather, something like the colon (:), as it's rather
innocuous where implications are concerned, doesn't stand out like a
ketchup stain on a white shirt when someone is reading a raw .gmi file,
and it will work with ASCII art, ANSI art, or anything else that may
subject the listener to cacophany.
But whatever anyone comes up with between these two types of proposals
I'll be happy to implement when I author my .gmi files.
I feel a sense of urgency, however, for at the very least, addressing
the matter of user accessibility now, in consideration of those who
would listen to the audible delivery of text/gemini.
And for that, I feel that we will actually be best served by those who
actually author Gemini clients, as to their suggestions on how they feel
best in implementing that type of support in their products.
>
> Benefits of this proposal:
>
> - It doesn't break any existing sites; it just adds one feature.
> - It's very simple to implement: parsers scan for a single additional
> backtick
> - Authors can still provide any alt-text they wish without worrying
> about "reserved words" like the proposed tags
Which of the above blocks should be read, and shouldn't be read?
> - It provides *critical* semantic information: whether or not a block of
> preformatted text should be treated as readable text.
Not enough in my opinion.
-spc
All very valid concerns and suggestions. Just let me know soon how to
alter the way in which I author my pages :)
I hope that helps :)
Kindest regards,
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
=> messages/005704.gmi Link to individual message. ## 40. avr (a) geminet.org (avr (a) geminet.org)
On Thu, Feb 25, 2021 at 03:14:43PM -0500, John Cowan wrote:
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?
Of all the proposed solutions, this one seems the most obvious.
The main problem with it is the spec, as it reads:
"Alt text may also be used for computer source code to identify the
programming language which advanced clients may use for syntax highlighting."
which is what a lot of the alternative solutions are trying to accomodate for.
Using the alt-text for source code highlighting sounds like a fun idea, but does it
really belong in the spec? It feels like a remnant of a cool idea that a programmer
in retrospect, it doesn't really belong there.
I think it would be best to drop that line from the spec--which would mean changing it,
but at least it's not extending it--and adopt your proposed solution as a
simple convention
for those who want to make their content easily available for the visually impaired.
=> messages/005705.gmi Link to individual message. ## 41. Bradley D. Thornton (Bradley (a) NorthTech.US)
On 2/26/2021 7:13 AM, Bradley D. Thornton wrote:
Apologies, I need to address one mistake in my last post and add one
thought.
First, the mistake. I forgot to remove the quote marks for Seans
example, in case anyone got confused and would attribute the change to him.
```:
____ _ _
| _ \ _ _| |_| |__ ___ _ __
| |_) | | | | _| '_ \ / _ \| ._ \
| __/| |_| | |_| | | | (_) | | | |
|_| \_, |\__|_| |_|\___/|_| |_|
|___/
```
I'm not suggesting that the above actually be what the authors of
clients should choose to adopt as their "convention", I'm just
clarifying that I edited Sean's example for the purposes of using it as
an example, as he suggested :)
Second, I would prefer not to refer to ASCII art or ANSI art as art at
all for the purposes of user accessibility, but rather, something like
perhaps "Noise". Because that is effectively what we're doing by
treating such preformatted blocks as a comment, filtering out the noise
for those who will be listening audibly to the dictation of a .gmi file.
Besides, .png and .jpg files, and even .gif or video files may
themselves either contain or themselves be artwork.
Beyond any of that, I do think we need to move on the issue of noise
with some expedience.
I hope that helps :)
Kindest regards,
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
=> messages/005706.gmi Link to individual message. ## 42. Devin Prater (r.d.t.prater (a) gmail.com)
Just a quick note to browser devs, you don't have to put the double right
arrow symbol next to links, and indeed, if I arrow unto a link line, I
expect Enter to activate that link. But, with the double right arrow symbol
before that link on the line, it just activates that instead, with no
result. I've taken out the double right arrow of the Elpher client, since
that's configurable, but it isn't in GemiNaut so I can only Tab to the link
then press Enter, or use the screen reader's "next link" command. Oh and a
keyboard command to go to the address bar is always great. :)
Devin Prater
r.d.t.prater at gmail.com
On Fri, Feb 26, 2021 at 9:43 AM Bradley D. Thornton <Bradley at northtech.us>
wrote:
On 2/26/2021 7:13 AM, Bradley D. Thornton wrote:
>
>
Apologies, I need to address one mistake in my last post and add one
thought.
First, the mistake. I forgot to remove the quote marks for Seans
example, in case anyone got confused and would attribute the change to him.
```:
____ _ _
| _ \ _ _| |_| |__ ___ _ __
| |_) | | | | _| '_ \ / _ \| ._ \
| __/| |_| | |_| | | | (_) | | | |
|_| \_, |\__|_| |_|\___/|_| |_|
|___/
```
I'm not suggesting that the above actually be what the authors of
clients should choose to adopt as their "convention", I'm just
clarifying that I edited Sean's example for the purposes of using it as
an example, as he suggested :)
Second, I would prefer not to refer to ASCII art or ANSI art as art at
all for the purposes of user accessibility, but rather, something like
perhaps "Noise". Because that is effectively what we're doing by
treating such preformatted blocks as a comment, filtering out the noise
for those who will be listening audibly to the dictation of a .gmi file.
Besides, .png and .jpg files, and even .gif or video files may
themselves either contain or themselves be artwork.
Beyond any of that, I do think we need to move on the issue of noise
with some expedience.
I hope that helps :)
Kindest regards,
--
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/f6d9
f721/attachment.htm>
=> messages/005712.gmi Link to individual message. ## 43. Baschdel (baschdel (a) disroot.org)
I've just got an Idea for clients which can't easily implement sections
in their document rendering [1].
The preformatted block could be reduced to a special "link" with the
alt-text as label (or a placeholder) that, when activated shows a dialog
window containing the content of the preformatted block. One could then
instruct the screenreader to read the content of that window, if it
starts talking gibberish one can simply close that window.
I don't know how well screenreaders would handle this, so feedback will
be appreciated.
Greetings!
- Baschdel
(Currently rewriting the frontend of my browser to make it more flexible
and hopefully also more accessible)
[1] i.e. clients that use the Gtk TextView (Castor and Dragonstone (my
client))
=> messages/005725.gmi Link to individual message. ## 44. Devin Prater (r.d.t.prater (a) gmail.com)
Yes, this would work well. I'll give Dragonstone a go.
On 2/27/21 5:55 PM, Baschdel wrote:
I've just got an Idea for clients which can't easily implement
sections in their document rendering [1].
The preformatted block could be reduced to a special "link" with the
alt-text as label (or a placeholder) that, when activated shows a
dialog window containing the content of the preformatted block. One
could then instruct the screenreader to read the content of that
window, if it starts talking gibberish one can simply close that window.
I don't know how well screenreaders would handle this, so feedback
will be appreciated.
Greetings!
- Baschdel
(Currently rewriting the frontend of my browser to make it more
flexible and hopefully also more accessible)
[1] i.e. clients that use the Gtk TextView (Castor and Dragonstone (my
client))
=> messages/005726.gmi Link to individual message. ## 45. Devin Prater (r.d.t.prater (a) gmail.com)
Okay, a note on Dragonstone: the text is readable, but seems to be plain
text, so tabbing to what I assume should be links on the "test" page
didn't work. Although, I guess that's all I'd really need to know about
are the links, but if the output could be "webified" by an engine that
Orca knows about, like geko or something to GTK, that'd be all the
better. The only other issue I found while doing a quick run is that the
"settings" button is unlabeled.
On 2/27/21 5:55 PM, Baschdel wrote:
I've just got an Idea for clients which can't easily implement
sections in their document rendering [1].
The preformatted block could be reduced to a special "link" with the
alt-text as label (or a placeholder) that, when activated shows a
dialog window containing the content of the preformatted block. One
could then instruct the screenreader to read the content of that
window, if it starts talking gibberish one can simply close that window.
I don't know how well screenreaders would handle this, so feedback
will be appreciated.
Greetings!
- Baschdel
(Currently rewriting the frontend of my browser to make it more
flexible and hopefully also more accessible)
[1] i.e. clients that use the Gtk TextView (Castor and Dragonstone (my
client))
=> messages/005727.gmi Link to individual message. ## 46. Baschdel (baschdel (a) disroot.org)
On 28.02.21 05:13, Devin Prater wrote:
Okay, a note on Dragonstone: the text is readable, but seems to be plain
text, so tabbing to what I assume should be links on the "test" page
didn't work. Although, I guess that's all I'd really need to know about
are the links, but if the output could be "webified" by an engine that
Orca knows about, like geko or something to GTK, that'd be all the
better. The only other issue I found while doing a quick run is that the
"settings" button is unlabeled.
Apologies for not making it clear that Dragonstone is in it's current
state a horrible mess that only really works when you are a well sighted
mouse or touchscreen user (That doesn't even include myself a lot of the
time), which is the reason I'm giving it a rewrite (because one year
younger me made terrible design decisions)
The settings button unfortunately has never been more than a placeholder
and is always insensitive (it's a kind of reminder for myself, gui
settings will come, promised)
On the popup window: I'll definitely make that one an option in the new
version.
On the links: Can you give Castor a try and tell us how the buttons for
links approach works? (I REALLY want to avoid having to include half a
webbrowser)
(I had that one in the older versions of dragonstone, but I realized
that inserting widgets into text buffers isn't exactly performance
friendly. If that works I'll make it an option in the current version,
although I'd have to limit it to a about a thousand links per page (I
have to add a configuration option anyway, so this will be configurable)
to avoid sites being able to freeze the ui)
I'll announce the rewrite when it is in a presentable state, but please
don't expect anything before September. (School is keeping me busy)
Thanks you for trying it out anyways and giving feedback! ?
- Baschdel
=> messages/005729.gmi Link to individual message. ## 47. Devin Prater (r.d.t.prater (a) gmail.com)
Caster, amusingly, hast the opposite problem. I can tab to links, but
can't read text with the arrow keys.Using Orca's Flat Review, which just
looks at all objects on the currently visible screen (all objects it can
find, that is), I can read the text, but can't tell with that if
something is a heading, a link, and can't scroll either. I'll keep going
down the list of browsers on
gemini://gemini.circumlunar.space/software/
Although I'm skipping terminal browsers for now, as Elpher works fine in
Emacs.
On 2/28/21 5:35 AM, Baschdel wrote:
On 28.02.21 05:13, Devin Prater wrote:
> Okay, a note on Dragonstone: the text is readable, but seems to be plain
> text, so tabbing to what I assume should be links on the "test" page
> didn't work. Although, I guess that's all I'd really need to know about
> are the links, but if the output could be "webified" by an engine that
> Orca knows about, like geko or something to GTK, that'd be all the
> better. The only other issue I found while doing a quick run is that the
> "settings" button is unlabeled.
>
Apologies for not making it clear that Dragonstone is in it's current
state a horrible mess that only really works when you are a well
sighted mouse or touchscreen user (That doesn't even include myself a
lot of the time), which is the reason I'm giving it a rewrite (because
one year younger me made terrible design decisions)
The settings button unfortunately has never been more than a
placeholder and is always insensitive (it's a kind of reminder for
myself, gui settings will come, promised)
On the popup window: I'll definitely make that one an option in the
new version.
On the links: Can you give Castor a try and tell us how the buttons
for links approach works? (I REALLY want to avoid having to include
half a webbrowser)
(I had that one in the older versions of dragonstone, but I realized
that inserting widgets into text buffers isn't exactly performance
friendly. If that works I'll make it an option in the current version,
although I'd have to limit it to a about a thousand links per page (I
have to add a configuration option anyway, so this will be
configurable) to avoid sites being able to freeze the ui)
I'll announce the rewrite when it is in a presentable state, but
please don't expect anything before September. (School is keeping me
busy)
Thanks you for trying it out anyways and giving feedback! ?
- Baschdel
=> messages/005733.gmi Link to individual message. ## 48. Peter Vernigorov (pitr.vern (a) gmail.com)
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.
=> messages/005804.gmi Link to individual message. ## 49. Katarina Eriksson (gmym (a) coopdot.com)
Apparently, I sent this only to John Cowan and not to the list.
On Sunday, February 28, 2021 3:49 AM, Katarina Eriksson <gmym at coopdot.com> wrote:
On Friday, February 26, 2021 3:37 AM, John Cowan cowan at ccil.org wrote:
> On Thu, Feb 25, 2021 at 9:27 PM Nathan Galt mailinglists at ngalt.com wrote:
>
> > .Previously, on this list, we discussed having the alt text be on
the first `and parser hints be on the last`, but I'm not sure anything
came of that particular discussion other than some try-outs in a vacuum.
>
> Well, The Spec also says that alt-text in the closing preformat line
MUST be ignored by clients.
Those are mode toggle switches, not block markers.[1] When the first one
is encountered, it switches to "preformated" mode and the alt-text is an
alternative to the "preformated" text. If there is a second toggle, it
will switch to "gemtext" mode and providing an alternative to that doesn't
make much sense.
[1] Implementing them as foldable blocks might be a good idea, though.
But that is an internal detail in the client.
--
Katarina
Third time writing and trying to send this e-mail. I recently switched
e-mail service and the android app is even worse than Gmail.
=> messages/005805.gmi Link to individual message. ## 50. Devin Prater (r.d.t.prater (a) gmail.com)
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.
=> messages/005812.gmi Link to individual message. ## 51. Peter Vernigorov (pitr.vern (a) gmail.com)
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>
=> messages/005815.gmi Link to individual message. --- => 000754.gmi Previous Thread: [spec] [tech] Companion Specification Proposal for Metadata => 000756.gmi Next Thread: Metadata Without A Proposal