[spec] Clarify purpose of alt-text

[Adnan Maolood]

Replying here as I never received the original email.

On Sun Feb 28, 2021 at 19:54 GMT, Bradley D. Thornton wrote:
> 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.

I think the following conventions can be adopted instead:

1. Authors of Gemini text are STRONGLY encouraged to add alt text to
ASCII art and other inacessible preformatted text to prevent it from
being read aloud by screen readers. For example:

```ASCII art of a smiley face 
:)
```

2. Code, poems, and other accessible text SHOULD NOT use alt text and
instead prefer to place any descriptive text above or below the
preformatted text. For example:

Here is a code snippet demonstrating how to use print:
```
print("Hello, world!")
```

3. Clients should allow the user to skip displaying preformatted text.
Preformatted text with a non-empty alt text should be considered
inaccessible and should not be displayed. Clients can also assume that
any preformatted text without alt-text is safe to display, but might
want to allow the user to skip those as well on a case-by-case basis.

This should be easy for gemtext authors and client authors alike.

> > 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).

I think that in this case the alt-text would probably be better off on
its own line. Alternative text is meant to provide an alternative
representation for imagery and ASCII art, not for textual content. Users
could still choose to skip the preformatted text if they desire. For
example:

Server log:
```
GET /
GET /about.gmi
(more entries...)
```

The client could allow the user to skip displaying the preformatted
text. However, since there is no alt text the preformatted text should
be considered accessible, unlike ASCII art.

I believe that this is the simplest and most elegant approach.