Alt text and media types for preformatted text

[Philip Linde]

On Mon, 01 Mar 2021 10:12:18 +0000
"Caolan McMahon" <caolan at caolan.uk> wrote:

> > How is the type more useful for accessibility than a general
> > description of its content? Would knowing in an art gallery whether
> > you're standing in front of an oil painting or an aquarelle be more
> > useful than knowing what the painting depicts?
> 
> No, but knowing whether the picture contained text or art would tell you whether to use assistive technology to read it or describe it.

Similarly, describing it would tell me whether to read it or skip it
and additionally allow an author to give me the gist of its content.

Read me

```C source code

or

```ASCII art depicting sleeping, happy cat

and I simultaneously have an indicator of whether I can comprehend the
content and a description of it in case I can not. Then I can
consciously navigate past it or dive into it with my client. The
problem with accessibility for now, from what I understand, is that
most clients don't have the navigational tools necessary to allow this,
and screen readers will happily burst out long sequences of nonsense if
that's what's presented to them. This is orthogonal.

> It seems most the disagreement here is whether the client should automatically make some sensible choices for the user (content type first), or the user should process the alt text and make their own call (alt text first)?

Most of my disagreement is with the breaking spec change, further
objections being with the assumptions underlying the definition of the
supposed problem with the spec as-is, but first and foremost that it
suggests a breaking change that is likely to hurt accessibility when a
breaking change isn't at all necessary in the first place.

See my suggestion at the end of the mail for how this can be
implemented without breaking the spec.

> > > 2. Knowing the content type upfront would allow clients to present streaming
> > > data correctly using appropriate colours and escape codes for code
> > > highlighting, for example.
> > 
> > A solution to a problem of its own making.
> 
> Sorry, I don't follow this point.

What you've suggested here (different lines before and after the
block content contain alt text and type information) creates a problem:
if the type information is after the content, the client can't know in
advance how to e.g. highlight source code. This problem doesn't exist
with the spec in its current form. By saying that the type information
should then be first, you propose to have solved that problem.

In one mail you have both created and solved a problem, and you list
having solved the problem you've created as an advantage of the approach
your suggestion. In that sense it's a solution to a problem of its own
making.

---

My suggestion: if for whatever reason you want to include machine
readable content information, do it on the alt text line as you already
MAY according to the current spec. Do this in a manner that's both
unambiguously separate from alt text to the computer and sensible as
natural plain text and unlikely to appear to mean anything other than
the machine interpretations, e.g. "(MIME: text/x-art)". Define this
format in a companion spec.

It doesn't immediately invalidate any existing pages, it's gracefully
forwards- and backwards compatible and it's already specified to an
extent. Clients that don't want to deal with this time waster can
ignore it, and people who are interested can decide on the color of
their bikeshed (maybe it should be "[MIME: ...]"?!) without constantly
pushing for completely unnecessary breaking spec changes.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210301/0a8c7cca/attachment.sig>