A proposed scheme for parsing preformatted alt text

[easeout at tilde.team]

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

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

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.