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
---
Previous in thread (4 of 10): 🗣️ Devin Prater (r.d.t.prater (a) gmail.com)
Next in thread (6 of 10): 🗣️ Solene Rapenne (solene (a) perso.pw)