Should some files provide an alt?

[cookiecrook]

Web Share API images have optional title, but seem to be missing alt.

shareButton.addEventListener("click", async () => {
 const file = new File(data, "some.png", { type: "image/png" });
 try {
 await navigator.share({
 title: "Example File",
 files: [file],
 alt: "Marcos??? 🧐" // accessible text alternative for the image, equivalent to HTML alt attr
 });
 } catch (err) {
 console.error("Share failed:", err.message);
 }
});

[saschanaz]

One would probably want alt description for each file. And a bigger issue is whether the OS sharing system supports alt or not (I don't see any support on Windows for example)

[saschanaz]

I still don't see it in https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.datapackage?view=winrt-26100

[marcoscaceres]

Moved issue from Web Share... hypothetically, a file of a particular type (e.g., and image/*) could have an associated alt representation.

[annevk]

Is File really the right place for that? OS platforms don't store replacement text for files to my knowledge so I don't think we should add that here.

Not saying that it doesn't make sense to add that in certain contexts, but I don't think this is the right API layer.

[mkruisselbrink]

I'd argue that File isn't really a representation of a OS file, rather it is a bunch of bytes with a name and content type. So from that point of view it seems reasonable that an "alt" representation could be another attribute of a File object. But I guess I can see the point that perhaps this should be on the web share side, where it would have to support passing in a pair of "file, alt text" where currently it just uses a file.

[annevk]

For instance, for <input type=file>, drag & drop, or IDB, this wouldn't make sense. I can certainly be convinced that it makes sense in certain contexts, but it seems those could build on this lower-level building block just as well?

[asutherland]

Currently the File/Blob fields roughly correspond to specific (HTTP) headers you might find on the roughly analogous Response (single-use) type. I'm not aware of any standardized HTTP headers for alternate text right now. Which I think makes sense because usually the appropriate alternate text for something like an image depends on the context in which it is being used. The literal contents of the image are not necessarily what the image represents in context and good alt text can help provide that context, even to those who can view the image but may need assistance with cultural context.

If the intent is literally to provide a description of the contents of an image, it would also be good to understand how the inherent metadata formats of the file payload come into play. Like, is this something EXIF should handle for images?

[karlcow]

Another similar case is Copy/Paste.
The clipboard API has the possibility of having multiple representations in the DataTransfer for ONE object.
https://html.spec.whatwg.org/multipage/dnd.html#dom-datatransfer-items

For example, copying an image collect the image data, and the URL in Safari (which creates webcompat issues, but that's another questions).

The WebShare API is slightly different
https://w3c.github.io/web-share/#sharedata-dictionary

How to reconcile the multiple files with the need for multiple alt.

To summarize:

• Clipboard API: One thing with multiple representations.
• WebShare: One Context with multiple simplistic things.

I wonder if alt is one of multiple representations for an image.