~caolan

UK

https://caolan.uk

~caolan/tamawiki

Last active 3 years ago
View more

Recent activity

Alt text and media types for preformatted text 1 year, 3 months ago

From Caolan McMahon to ~adnano/gemini

> > One way I think gemini got this right was in using links for images. It
> > requires a textual description of the image, and it's shown to all
> > users. There's no split in the presentation, everyone is treated that
> > same. I like that.
> > 
> > Unfortunately, alt text for preformatted blocks does introduce content
> > only likely to be seen by a minority of users.
> 
> One solution lies within your comment: remove preformatted blocks from 
> text/gemini so that we have to link to resources of text/plain or text/
> whatever. Just like we do with images etc. 
> 
> Probably unpopular but simple, right? Is there a mime type for ascii-art?
> 

Alt text and media types for preformatted text 1 year, 4 months ago

From Caolan McMahon to ~adnano/gemini

> > My suggestion would be to place type information after the opening ```, and
> > alt-text after the closing ```, for the following reasons:
> 
> Existing documents that use alt text as per the current spec will be
> broken. Existing clients which MUST ignore any text following the
> terminating ``` won't be able to access the alt text on new documents
> following this suggestion. Seems like we'd be getting the worst of
> both worlds.

>From a backwards compatibility perspective, yes, I agree. Alt text was allowed after the initial ``` so we are probably stuck with it.

> 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

Alt text and media types for preformatted text 1 year, 4 months ago

From Caolan McMahon to ~adnano/gemini

> i feel it's important that accessibility for the vision-impaired 
> be easier to support in clients than syntax highlighting. More 
> generally, my preference is for gemtext documents to be reasonably 
> accessible by default, rather than requiring special efforts to be 
> made accessible (as on the Web, where accessibility often plays 
> second fiddle to resource-gobbling bling).

On the web, it is considered good practice to use alt text for images, and there is pressure from the web development community in this regard. Unfortunately, most web users don't actually see alt text in normal use. So it's always going to be a bit of a second class citizen.

One way I think gemini got this right was in using links for images. It requires a textual description of the image, and it's shown to all users. There's no split in the presentation, everyone is treated that same. I like that.

Unfortunately, alt text for preformatted blocks does introduce content only likely to be seen by a minority of users. The only way I can see around that would be a practice of repeating any visual content in prose descriptions in the surrounding paragraphs. This gives reinforcing content that everyone can see. Unfortunately, I don't know how practical that would be in all cases.

But if anyone has an idea to make preformatted blocks more accessible without hidden content for the visually impared, and instead using content shared by everyone, I'd be keen to hear it.

Alt text and media types for preformatted text 1 year, 4 months ago

From Caolan McMahon to ~adnano/gemini

> > I like the ordering of content type first and alt text last
> So the sighted people with fancy syntax highlighting get to trivially
> read it line-by-line, but the people writing accessible software have to
> 1) seek forward to find the end of the preformatted text block; 2) read
> the alt text; then, if the user wants to display the preformatted block
> 3) jump backwards to the beginning of the preformatted text block and
> read it; then 4) skip past the last line of the preformatted text block
> so it isn't read again; then 5) continue parsing.

I agree that the most important principle is that a client choosing to implement accessibility features knows what to do with the following content. That's why I'm proposing content type first.

You might prefer to use the more ambiguous optional alt text and ask the user how to present the data each time. I have no idea if that is correct, someone who relies on a screen reader will have to enlighten me. But don't assume my motives. So far as I can tell, our priorities are the same.

Alt text and media types for preformatted text 1 year, 4 months ago

From Caolan McMahon to ~adnano/gemini

> Code highlighting is a good use case for this - but it would also 
> ~sorta allow for putting other content inline if we aren't careful on 
> what's allowed.

To be honest, code highlighting is probably not that important but it's an easy to understand presentation choice that a client might make. It's probably more important that a client implementing accessibility features understands what type of content is in the block so it can read or navigate it appropriately.  E.g. a table or a poem might be handled differently to ascii art.

As for other content inline - I agree. Preformatted text blocks have always been the biggest extensibility risk in my opinion. They were already the most likely place to put custom client features and this makes it very slightly easier. In the end, our best defence is culture and a plethora of popular clients. Keeping things easy to parse is important for that reason, and I believe an argument for either denying extra data for preformatted blocks, having only one type, or keeping them separate, instead of attempting to combine them with new syntax.

> But I think using the opening/closing toggles like this may cause 
> confusion, if you look at the line in isolation, you can't tell what 
> the text following it is. You're supposed to be able to tell how a line 
> would be structured/it's meaning by only looking at the first three 
> lines.

Alt text and media types for preformatted text 1 year, 4 months ago

From Caolan McMahon to ~adnano/gemini

Hello all,

This is in response to the various alt-text / content type suggestions floating around.

I'm uncomfortable with inventing a new syntax to combine these two pieces of data for two reasons. First, new syntax complicates the spec. Second, any ambiguity will reduce the usefulness both to a client.

Ideally, the two would be separate. Most suggestions I've seen so far were to follow the opening ``` of a preformatted block with a mix of this data. However, there is also the option of adding data after the closing ``` marker, keeping the two separate.

My suggestion would be to place type information after the opening ```, and alt-text after the closing ```, for the following reasons:

1. Even for accessibility, I suspect knowing the content type is more practically useful to the client in the majority of existing cases. Most ASCII art is purely decoration, and knowing the content type is text/x-ascii (or similar) upfront is important so the screen reader can simply skip it.
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.
3. Placing the content type after the opening ``` line is familar to markdown authors, which is not a reason in itself, but a welcome bonus nonetheless.
4. Placing the alt text after the closing ```, at the end of the preformatted block has a nice symmetry with links which place the human-friendly text at the end too.

[ANN] UK weather service 1 year, 5 months ago

From Caolan McMahon to ~adnano/gemini

> This is certainly my new favourite way to check the weather

Glad you like it :)

I'm sure the layout could be improved. If anyone has suggestions or wants to email me a gemtext example of what you'd like I'll definitely consider it.

Caolan

[ANN] UK weather service 1 year, 5 months ago

From Caolan McMahon to ~adnano/gemini

Users in the UK might be interested to know I've added weather forecasts to my gemini capsule: 

gemini://caolan.uk/weather/

Let me know if you have any questions or feedback,

Caolan

Appetite for Gemini users mailing list? 1 year, 6 months ago

From Caolan McMahon to ~adnano/gemini

> My personal use cases are covered by announce + user. 
> Specifically, I'd like to read about gemini content, and 
> software/service (e.g GUS) announcements.

Yes, announce + user is what I'd subscribe to. Solderpunk's description of gemini-users is exactly what I had in mind.

Appetite for Gemini users mailing list? 1 year, 6 months ago

From Caolan McMahon to ~adnano/gemini


>I for one think it's a good idea.  I
>know multiple people who have unsubscribed from this list after heavy
>early involvement because it's just become too much to follow.

And, just to be clear, it's not only the volume of messages that prompted by suggestion. I think it would be good to consider what a friendly onboarding looks like for new users and content creators - be that on this list or a separate one.