💾 Archived View for gemi.dev › gemini-mailing-list › 000762.gmi captured on 2024-05-12 at 16:14:43. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Recently there was some discussion regarding the accessiblity of preformatted text lines. This proposal aims to address those concerns by simply clarifying the purpose of alt text. During the discussion John Cowan said: > 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. gemini://gemi.dev/gemini-mailing-list/messages/005633.gmi I agree with John. I believe that a clarification to the specification is the best way to resolve this issue. Alt text should serve one and only one purpose: provide an alternative text representation of preformatted text. If a block of preformatted text does not need an alternative text representation (i.e., it can be read aloud as is), then it should not have any alt text. Section 5.4.3 of the Gemini specification currently states: > Any text following the leading "```" of a preformat toggle line which toggles > preformatted mode on MAY be interpreted by the client as "alt text" pertaining > to the preformatted text lines which follow the toggle line. Use of alt text > is at the client's discretion, and simple clients may ignore it. Alt text is > recommended for ASCII art or similar non-textual content which, for example, > cannot be meaningfully understood when rendered through a screen reader or > usefully indexed by a search engine. Alt text may also be used for computer > source code to identify the programming language which advanced clients may > use for syntax highlighting. I propose that the final sentence be removed, and that MAY be replaced with MUST: > Any text following the leading "```" of a preformat toggle line which toggles > preformatted mode on MUST be interpreted by the client as "alt text" pertaining > to the preformatted text lines which follow the toggle line. Use of alt text > is at the client's discretion, and simple clients may ignore it. Alt text is > recommended for ASCII art or similar non-textual content which, for example, > cannot be meaningfully understood when rendered through a screen reader or > usefully indexed by a search engine. This would mean that should a screen reader encounter a preformatted text block with a non-empty alt text, the alt text would be read aloud and the preformatted block would be skipped. After all, that's what "alternative text" is supposed to mean.
On 28-Feb-2021 15:06, Adnan Maolood wrote: > Section 5.4.3 of the Gemini specification currently states: > >> Any text following the leading "```" of a preformat toggle line which toggles >> preformatted mode on MAY be interpreted by the client as "alt text" pertaining >> to the preformatted text lines which follow the toggle line. Use of alt text >> is at the client's discretion, and simple clients may ignore it. Alt text is >> recommended for ASCII art or similar non-textual content which, for example, >> cannot be meaningfully understood when rendered through a screen reader or >> usefully indexed by a search engine. Alt text may also be used for computer >> source code to identify the programming language which advanced clients may >> use for syntax highlighting. > I propose that the final sentence be removed, and that MAY be replaced > with MUST: 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) The spec does not restrict to a single application or interpretation of the label for these preformatted areas. Both elements are important. It is a reduction in scope to turn the may to a must as you suggest. From an accessibility point of view, you could say that indicating the content type is actually more important to screen readers as they can definitively use that to choose whether to show the content or not. The problem is these are orthogonal uses and the spec has them entangled together. So the solution is to disentangle. I think the proposal to use the opening and closing labels for each purpose (on the other email thread) is the best solution so far. ?- Luke
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. > The spec does not restrict to a single application or interpretation of > the label for these preformatted areas. Both elements are important. > > It is a reduction in scope to turn the may to a must as you suggest. > From an accessibility point of view, you could say that indicating the > content type is actually more important to screen readers as they can > definitively use that to choose whether to show the content or not. Are both elements *really* important? Are there really any content types besides ASCII art that clients would need to decide whether to show or not? - Code can be read as-is. I believe that syntax highlighting is not really necessary. The language used for the code can be inferred by a human from the surrounding text, or the author can write a small sentence underneath each preformatted code block describing the code. - Poems can be read as-is, so should not have any alt text. - Tables probably do not belong in Gemini text. 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.
This is my main issue: screen readers *do not* skip the block. This will need to be dealt with by the client, not the screen reader. On 2/28/21 9:06 AM, Adnan Maolood wrote: > This would mean that should a screen reader encounter a preformatted text > block with a non-empty alt text, the alt text would be read aloud and the > preformatted block would be skipped. After all, that's what "alternative > text" is supposed to mean.
On 28-Feb-2021 15:41, 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. To specify the language used in this context is effectively to identify the type of text. I cannot believe the specification was literally only talking about programming languages in this respect, although that is an example. >> The spec does not restrict to a single application or interpretation of >> the label for these preformatted areas. Both elements are important. >> >> It is a reduction in scope to turn the may to a must as you suggest. >> From an accessibility point of view, you could say that indicating the >> content type is actually more important to screen readers as they can >> definitively use that to choose whether to show the content or not. > Are both elements *really* important? Well both were considered to be valid applications of the preformatted label in the spec. You might as well ask if I send you a document, is it more important to know the media type or the title? > > Are there really any content types besides ASCII art that clients would > need to decide whether to show or not? If I was a non-technical person I might very well want not to see source code, or to have them "behind a button", at the same time I might like to see everyone's ascii art or poetry. These are legitimate preferences to be configured into a client. On the list recently there was a discussion about rendering mathematics in gemini. With an appropriate content label an aware client could display these in an attractive rendered form. > - Code can be read as-is. I believe that syntax highlighting is not > really necessary. The language used for the code can be inferred by a > human from the surrounding text, or the author can write a small > sentence underneath each preformatted code block describing the code. That could equally be true for ascii art. Put some text around it to describe it then use a definitive content type label to indicate what type of text it is? Then use the type label to definitively decide not to show the art to a non visual user. > - Poems can be read as-is, so should not have any alt text. > - Tables probably do not belong in Gemini text. > > 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. The presence of a label on the text area is not definitive of what content it contains, so its absence or existence can't completely determine whether or not it should be rendered. It is an over interpretation of the label's existence. ?- Luke
On Sun, 28 Feb 2021 10:25:25 -0600 Devin Prater <r.d.t.prater at gmail.com>: > This is my main issue: screen readers *do not* skip the block. This will > need to be dealt with by the client, not the screen reader. > > On 2/28/21 9:06 AM, Adnan Maolood wrote: > > This would mean that should a screen reader encounter a preformatted text > > block with a non-empty alt text, the alt text would be read aloud and the > > preformatted block would be skipped. After all, that's what "alternative > > text" is supposed to mean. When using the screen reader, can you tell it to skip n lines? I see something that could be done in clients as an option (not a default) For this kind of block for example: ```this is something some text on multiples lines ``` the client could replace it by a link entry accessing a "virtual" page containing only the text, or opening $PAGER on the content. => verbatim-text-#1 [Virtual page] This is something In case of no alt text this would be seen as => verbatim-text-#10 [Virtual page] No alt text of course, the wording Virtual page is the first thing that came out but I'm pretty sure something better could be found.
No, in most cases. With all GUI and textual screen readers, you can press Down Arrow n times to skip lines, but it's not automatic. Like, you can't do like with Emacs (with Emacspeak giving speech output) and do C-u n C-n to skip lines with other screen readers. On 2/28/21 10:30 AM, Solene Rapenne wrote: > When using the screen reader, can you tell it to skip n lines?
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
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.
On Sunday, February 28, 2021 10:28 PM, Adnan Maolood <me at adnano.co> wrote:
> 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
> :)
> ```
Agreed, though I would like to see a space character between "```" and the
alt text in this case.
> 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!")
> ```
I like the approach of being extra clear on what's to come, even to people
who don't need the description.
If the code isn't considered accessible, it could be marked with a single
word alt text with no whitespace, like this:
This is how it looks like minified:
```javascript
Though, maybe it's better to provide a separate file at that point.
> 3. Clients should allow the user to skip displaying preformatted text.
[...]
I think there are no disagreements here.
--
Katarina
---
Previous Thread: Alt text and media types for preformatted text