💾 Archived View for rawtext.club › ~sloum › geminilist › 005808.gmi captured on 2024-02-05 at 11:06:48. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Mon Mar 1 13:04:16 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 itand additionally allow an author to give me the gist of its content.
Read me
or
and I simultaneously have an indicator of whether I can comprehend thecontent and a description of it in case I can not. Then I canconsciously navigate past it or dive into it with my client. Theproblem with accessibility for now, from what I understand, is thatmost clients don't have the navigational tools necessary to allow this,and screen readers will happily burst out long sequences of nonsense ifthat'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, furtherobjections being with the assumptions underlying the definition of thesupposed problem with the spec as-is, but first and foremost that itsuggests a breaking change that is likely to hurt accessibility when abreaking change isn't at all necessary in the first place.
See my suggestion at the end of the mail for how this can beimplemented 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 theblock content contain alt text and type information) creates a problem:if the type information is after the content, the client can't know inadvance how to e.g. highlight source code. This problem doesn't existwith the spec in its current form. By saying that the type informationshould then be first, you propose to have solved that problem.
In one mail you have both created and solved a problem, and you listhaving solved the problem you've created as an advantage of the approachyour suggestion. In that sense it's a solution to a problem of its ownmaking.
---
My suggestion: if for whatever reason you want to include machinereadable content information, do it on the alt text line as you alreadyMAY according to the current spec. Do this in a manner that's bothunambiguously separate from alt text to the computer and sensible asnatural plain text and unlikely to appear to mean anything other thanthe machine interpretations, e.g. "(MIME: text/x-art)". Define thisformat in a companion spec.
It doesn't immediately invalidate any existing pages, it's gracefullyforwards- and backwards compatible and it's already specified to anextent. Clients that don't want to deal with this time waster canignore it, and people who are interested can decide on the color oftheir bikeshed (maybe it should be "[MIME: ...]"?!) without constantlypushing for completely unnecessary breaking spec changes.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210301/0a8c7cca/attachment.sig>