Assets used in README.org are not accessible

[shindere]

Although it may be possible to get the information provided in the assets in other ways, would it please be possible to provide descriptions for these assets so that they become accessible to visually impaired persons?

Thanks!

[shindere]

Apologies -- not all medias have descriptions and a few descriptions
might be made more precise.

For instance: "Image showing gptel's menu with some of the available
query options.": if an option is readable on the image then it should
appear explicitly in its description. Likewise, if the picture shows the
kind of widget this option is, that, too, should be part of the
description.

One other example: the image used to illustrate the use of
gptel-highlight-mode just has "Image" as an alternative text.

[karthink]

I've updated the descriptions/alt-text of all images in the README. Let me know if there are any that don't make sense to you, and I'll add more context as required.

[shindere]

Thank you! I will look at the changes promptly and provide feedback here.

[shindere]

Overall: I find the changes very nice, thanks! More specificically, I think they give a much better idea to a blind person of what is supposed to happen in Emacs. This makes it possible to more easily figure out whether what is happening in a session is what is announced by the documentation or not. For at least some of the examples, I was wondering whether it would be easier / make sense to provide the files used to get the examples so that the description could refer to them rather than describing their content? That is a completely open question. Mundane: there is an empty alt="" reamining at line 1308 or README.org that should probably be removed as it is redundant with the non-empty alt. Two things that could be further improved: 1. A text like "It features a clickable underlined button" is certainly helpful, as it is always interesting to know how something *looks* on screen, for instance to help a sighted colleague locate it, but if you work on your own such a text is difficult to use: generally blind users do not use pointing devices so it is more helpful to tell them how to activate something through the keyboard or an Emacs command than to tell them it's clickable. 2. Something that is maybe out of scope here: Screenshot of gptel's context inspection buffer. It displays marked deletions (highlighted in green) in a .gitignore file The question here is: will the marked deletions be identifiable by an other way than being highlighted in green? They should, and if they are not that is the part which is beyond the present comment. And if they are, this non-color based way of being highlighted should be preferred in an alt description, I think. Maybe sotheing like lines starting with a minus sign?

[karthink]

For at least some of the examples, I was wondering whether it would be easier /
make sense to provide the files used to get the examples so that the description
could refer to them rather than describing their content? That is a completely
open question.

I don't understand what you mean here.

[shindere]

karthink (2026/09/08 21:02 -0700):

karthink left a comment (karthink/gptel#1511) > For at least some of the examples, I was wondering whether it would be easier / > make sense to provide the files used to get the examples so that the description > could refer to them rather than describing their content? That is a completely > open question. I don't understand what you mean here.

Sorry, let me try to explain again. Each buffer which is shown on an image oculd be represented by a text filein the repository, whichcould be referrenced to by the alternative text. What this would lose is the placement on screen of the windows in which tue buffers are displayed, and also the status lines. But the placement is may be not that important and the status lines could be described or also copied as text.