Repository navigation
Should some files provide an alt? #215
Description
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);
}
});
Activity
saschanaz commentedon Oct 22, 2024
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 commentedon Nov 11, 2025
I still don't see it in https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.datapackage?view=winrt-26100
[-]Web Share API images have optional title, but seem to be missing alt.[/-][+]Should some files provide an alt?[/+]marcoscaceres commentedon Nov 12, 2025
Moved issue from Web Share... hypothetically, a file of a particular type (e.g., and
image/*) could have an associated alt representation.annevk commentedon Nov 12, 2025
Is
Filereally 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 commentedon Nov 12, 2025
I'd argue that
Fileisn'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 commentedon Nov 12, 2025
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 commentedon Nov 12, 2025
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 commentedon Nov 13, 2025
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
fileswith the need for multiple alt.To summarize:
I wonder if
altis one of multiple representations for an image.