[Clients] Gemini and accessibility regarding preformatted code blocks
Bradley D. Thornton
Bradley at NorthTech.US
Fri Feb 26 15:13:32 GMT 2021
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
*some* authors of clients could key off of in the text, who are wanting
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
*some* clients to not deliver what is contained in the block, while
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:
. ,- To the Moon Alice !
.-'8888P'Y.`Y[ ' `-.
,' ,88888888888[" Y`.
/ 8888888888P Y8\
/ Y8888888P' ]88\
: `Y88' P `888:
: Y8.oP '- > Y88:
| `Yb __ `'|
: `'d8888bo. :
: d88888888ooo. ;
\ Y88888888888P /
\ `Y88888888P /
`. d88888P' ,'
`. 888PP' ,'
`-. d8P' ,-' -CJ-
> 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
> def index:
> 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,
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
**Pleurotus ostreatus** - Scientific convention is such that one should
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.
Solene also mentioned her aprehensions in using a particular language
for such tags, which I thought was very eloquently addressed by
OK, inspired by my past life as a Perl programmer, I suggest a fully
```@ (ASCII art)
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
>> - 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.
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 :)
Bradley D. Thornton
Manager Network Services
More information about the Gemini