Adnan Maolood me at adnano.co
Sun Feb 28 15:41:56 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 forcomputer source code, not for identifying the type of text. So thiswould 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 wouldneed 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 forthe above examples. It is much simpler to treat the presence of alt-textas an indicator that the preformatted text is not accessible.