[spec] Clarify purpose of alt-text

[Bradley D. Thornton]

On 2/28/2021 7:41 AM, Adnan Maolood wrote:
> On Sun Feb 28, 2021 at 10:20 AM EST, Luke Emmet wrote:
>> I disagree - at present the spec lends equal weight to the two possible
>> interpretations of the label of the preformatted text areas
>>
>> - they may be interpreted as an alternative label for screen reader
>> (an accessibility label since ascii art is meaningless to non-visual
>> users)
>> - they may be used for text type identification (to convey the type of
>> content shown, for syntax highlighting or possibly more useful semantic
>> purposes, for example a client may choose not to render ascii art at
>> all)
> 
> Currently the specification only allows for specifying the language for
> computer source code, not for identifying the type of text. So this
> would mean expanding the scope of the specification, not restricting it.
> I am not really in favor of this.

Neither of the two current basic discussions on how to handle this
advocate for any change in the spec - nor should they. There's no reason
to consider it for such, especially when both general concepts offer a
resolution that does not suggest any changes in the spec.

My original suggestion was for a 'convention' that the authors of
clients could find consensus with that will enable the non-sighted
reader to configure that client so as not to render content in between
the preformatted text area of a .gmi file.

That remains my concern. The rest may be worthwhile, or not, but in
either case they involve no changes to the spec.

Whether:

```:

```

or:

```@

```

or:

preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
tag       = '@art' / '@code' / '@data' / '@poem'

None of these involve any mention (and again, nor should they) of a
change in the spec.

This entire discussion evolves around what *some* clients *may*
incorporate (by convention) in the form of a configurable option of
their software so that a block of preformatted text can be opted out
from being rendered in the Gemini browser.

In the first example a single, innocuous character can be keyed upon to
signal that *if* a client has incorporated an opt-out for displaying
blocks of preformatted text for the purposes of user accessability, it
won't display that block of preformatted text to the reader.

It doesn't get in the way of reading raw gemtext, it is hardly noticable
if  you are, and it means nothing but part of the comment that follows
the opening markdown tag, such that it is.

The second example is simply a different character, but part of a more
comprehensive suggestion to accommodate much more than what was my
initial concern for user accessability. That too, is  something that
*may* or may not be adopted by authors of gemini clients.

The third example provides the same as the second suggested solution,
but with a somewhat different approach that may offer more (and I dread
using  this word but I guess I must) extensibility.

Absolutely NONE of the suggestions above have anything at all to do with
a channge in the spec. They do, however, require two things:

1.) Authors of gemini clients will need to decide how they are going to
address this and either alone or with the participation of others on
this list come to a consensus as to how "they" best feel it can be
integrated into Gemini clients, while maintaining the simplicity that
Solderpunk has established is one of the paradigms of Project Gemini.

2.) People who author .gmi files will need to incorporate the
methodology proscribed by the authors of Gemini clients *if* they wish
to participate in making sure that the pages they author assist in the
aim to deliver Gemini content to the non-sighted readers of this world,
and dare I say, given the context of what Gemini is, it stands to reason
that this number will be significant.

Providing what I've just said above. Two things *should* be considered.

1.) the method should be easy to implement in a client, in any language

2.) the method *must* be stupid simple for people like me so that I can
accommodate such user accessibility when authoring my .gmi files.

If you write gemlogs, then I think you prolly agree wholeheartedly with
that second point.



> 
> Are there really any content types besides ASCII art that clients would
> need to decide whether to show or not?

Yes. And they are myriad. Consider log dumps, interminable parts lists
or inventory sheets, perhaps even Microsoft EULAs (because as we all
know, if you're a living breathing organism, you're already
non-compliant with their licenses).

There are a thousand use cases where it might be obvious to the
*Authors* of .gmi files that what they're about to  publish in those
blocks are quite simply, tl;dr.

> 
> In my opinion designating the content type is not really necessary for
> the above examples. It is much simpler to treat the presence of alt-text
> as an indicator that the preformatted text is not accessible.
> 

I'm thinking that what you just suggested is a topic for another
discussion. A discussion where the authors of Gemini clients incorporate
a quick and easy way for the reader to change configurations and refresh
the page they're viewing, in case the reader wants to actually be
presented with what is contained within the preformatted text block.

Example: a non-sighted person wants to install a daemon, but they're a
seasoned sysadmin, so they really don't want to be bothered with all of
the syntax noise of many particular parts  of a tutorial or HowTo on
pulling, compiling and installing the software, most can already write a
server block in Nginx in their sleep - so that would be noise to render
that audibly (I would think), but when they get to the page where the
config.exs file is they may actually want to listen to all of that.

I dunno, even sighted folks skip the parts of code in tuts that they
don't need to bother with.

In any case, that's a 'feature' that the authors of some clients *may*
choose to offer the people that use their software - and as far as the
reader goes, that's really irrespective of whether there's Alt text or
white space following the markdown tag  (Yes, text would be nice, huh?).

So, basically, if you are wondering how many pages Stephanie's LUPA says
are currently in Gemini space, the anser at this moment is 113,310; with
forty something new sites being discovered in the past day or so.

That number's not getting smaller. it's getting much bigger, much faster
 everyday, and at this very moment, that's a lot of .gmi files that
content publishers *may* try to take the opportunity to paste in the
teensy little change to their pages in service to their fellow humans.

So with that in mind, I would suggest that *time is of the essence*, so
that those authoring new pages can get on board with whatever solution
is settled upon (if they choose to do so).

I hope that helps :)

Kindest regards,


-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268