The image and its text alternative are separate
An image file does not reliably carry the description entered in a social app's accessibility field. A publisher must preserve the association between the asset and its description, then supply the appropriate destination field. Bluesky's post documentation, for example, places an alt value beside each image reference. Copying only the image or the general caption does not establish that this field arrived.
W3C explains that a text alternative should convey an image's information or function in context. A post caption can explain why a topic matters while the alternative describes what the image shows. Neither automatically replaces the other. For an image containing essential words, make those words available as text. For a complex chart, provide the meaningful information, not just the statement that it is a chart.
Pair every asset with its description
Before publishing an image set, assign a stable label to each file and write its description beside it. This small manifest survives changes in display order better than a loose list of descriptions. If the second image becomes the first, move its description with it. If an image is cropped so its important detail changes, revise the description instead of blindly reusing the old one.
The following examples describe an illustrative bicycle-repair post. They are not accessibility test results. Notice how each description communicates a different image's role rather than repeating the same promotional caption. Your actual wording should reflect the images you own and the surrounding explanation. Do not add imagined details, identity assumptions, or keyword lists to make the description seem more comprehensive.
| Asset | Purpose | Illustrative description |
|---|---|---|
| 01-before.jpg | Identify the problem | Loose brake cable protrudes from the lever housing. |
| 02-adjustment.jpg | Show the action | A hand turns the barrel adjuster beside the brake lever. |
| 03-check.jpg | Show the final check | Brake pads sit clear of the rim while the wheel turns. |
Verify each publishing route rather than assuming portability
Check the platform's current documentation and the tool's actual controls. A destination API can support descriptions without every integration exposing them. Create, schedule, and source-sync flows may also carry different metadata. Use a harmless representative image and inspect the final destination field or accessible presentation. Keep a record of which route you checked and what you observed.
If a description disappears, identify whether it existed in the original, was available to the reader or importer, was present in the saved draft, and reached the destination. That sequence separates a missing source field from a publishing transformation. For a multi-image post, compare every asset, not just the first thumbnail. A successful upload and correct image count are not sufficient accessibility evidence.
Use an honest fallback and fix the recurring cause
When a route cannot deliver the required description, consider native completion or a different supported path. If essential information must also appear in visible text, add it clearly, but do not claim that a caption creates the same per-image accessibility field. The appropriate fallback depends on the image's role and destination controls. Avoid publishing an inaccessible chart merely because the rest of the batch is ready.
After a tool change, account reconnection, or new image format, repeat the relevant check. In Ferryman, verify the route you actually use rather than inferring alt-text transport from platform support alone. Save the source manifest with your original files so corrections do not require reconstructing the descriptions. The goal is that readers receive the image's useful information, whichever interface or assistive technology they use.
Sources & further reading
Written by Ferryman. Sources checked Oct 16, 2026. Platform rules can change; consult the linked documentation for current requirements.