A proposed scheme for parsing preformatted alt text

[Nathan Galt]

> On Sep 10, 2020, at 5:16 PM, easeout at tilde.team wrote:
> 
> On Thu, Sep 10, 2020 at 09:55:34AM -0600, Alex // nytpu wrote:
>>> I strongly recommend against this. The W3C has been trying to get HTML
>>> authors and browser makers to _only_ display, in tooltips, text in
>>> `title` attributes.  Previously, HTML authors would write `alt`
>>> attribute values intending them to be read by sighted HTML readers who
>>> can already see the image.
>> I strongly agree. While I don't view the W3C's recommendations as the
>> gold standard of things gemini should look to emulate (EME anyone?), I
>> agree that if we make the alt text easily visible it will no longer be
>> accessibility text and will turn into a miscellaneous-purpose field.
> 
> Great points. My main goal is to address the fact that the spec
> underdefines the alt text field. I want it to decide on one use such
> that clients could depend on it always being suitable for that use.
> 
> Thanks for pointing out that what we think of as "alt text" in HTML is
> not the same thing as the alternative representation used by screen
> readers. In that light, I don't want Gemini's preformat alt text to be
> machine-readable, nor do I want it to be an HTML alt text style tooltip
> or caption.
> 
> I think it should behave like the "title" attribute. I want Gemini to
> offer accessibility affordances where the nature of plain text does not
> already provide them, and this seems like the right use for that. I
> think it would also be suitable to change the name from "alt text" to
> something like "accessibile description”.

I think you’ve got the terminology backwards. In HTML, `alt` is for people who can’t see the image (didn’t download it, eyes don’t work right, etc.). In that light, renaming it to “accessible description” changes nothing, and “it should behave like the ’title’ attribute” means, as far as I can tell, “it should be accessory information for people who can already see the image”, which is not even _trying_ to be helpful for people who can’t see the image.

Let me show an example where the contents of `alt` and `title` differ wildly:

<img src='conned-eventually.jpeg' alt='Chio telling Link “Ya know, if you keep doing everything everyone asks of you without question, you’re gonna get conned eventually…”' title='Little does Chio know I’ve already met Purah.'>

The alt text describes the image (a screenshot of me playing The Legend of Zelda: Breath of the Wild).

The title text is a joke, hidden behind a tooltip in most browsers, that should make anyone who’s played BotW snicker briefly. (Purah treats Link as an errand-boy for a good portion of the game.)

> 
>>> (You might be thinking “well, what about that Markdown meme where
>>> people write ‘```javascript’ to start off a JavaScript code block, with
>>> the idea that a syntax highlighter will read it and colorize the
>>> output?”
>> The original point of suggesting that it be displayed for all users was
>> to discourage turning text intended for humans into text intended for
>> machines anyways, but I believe an alternate solution other than
>> displaying it for everybody would still be preferable.
> 
> Yep, that is what I meant, to drop machine-readability in favor of human
> readability.
> 
>> Rewriting that portion of the spec to emphasize that it is not to be
>> parsed in any way other than as natural language?  Maybe say that a
>> client *should be able to* completely replace the preformatted block
>> with the contents of the alt text without the document losing
>> significant meaning? That would work for ascii art and short code
>> snippets, but it might not be doable for longer code blocks.
> 
> An accessible description for a long code block seems like a non-goal,
> though, because when code is text, I imagine that makes it accessible to
> a screen reader.

I have a strong prior that most screen readers won’t read code text aloud in ways that would make sense to a (blind) programmer who’s familiar with that sort of code. For example, I would expect that most screen readers won’t read parentheses and single/double quotation marks out loud, and those sorts of punctuation marks tend to be superlatively important in roughly all programming languages.

And then there are blind non-programmers who might stumble across a bit of code, or blind programmers who don’t understand _that_ kind of code and would appreciate some short alternative text explaining what it does (this gives them a better idea of whether they should tough it out and listen to it all or just skip it).

> When considering these details it is helping me to draw a clear line
> between an accessible content description and a caption. I think we want
> the former, not the latter.

For what it’s worth, I’m pro-alt-text. Tightly-bound captions might also be nice (I’d use them if they were in the spec), but they’re much, _much_ less important.