easeout at tilde.team easeout at tilde.team
Fri Sep 11 01:16:31 BST 2020
- - - - - - - - - - - - - - - - - - -
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 specunderdefines the alt text field. I want it to decide on one use suchthat 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 isnot the same thing as the alternative representation used by screenreaders. In that light, I don't want Gemini's preformat alt text to bemachine-readable, nor do I want it to be an HTML alt text style tooltipor caption.
I think it should behave like the "title" attribute. I want Gemini tooffer accessibility affordances where the nature of plain text does notalready provide them, and this seems like the right use for that. Ithink it would also be suitable to change the name from "alt text" tosomething 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 humanreadability.
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 toa screen reader.
When considering these details it is helping me to draw a clear linebetween an accessible content description and a caption. I think we wantthe former, not the latter.