Short answer: Review the final rendered post, not only the copy document. Put the essential launch message in readable post text, describe meaningful information in each attached image, provide an appropriate text path for video information, and check that the destination repeats the promise accessibly. Ask the product owner to verify facts and the publisher to inspect the actual scheduled version. If a reader needs to see a graphic or hear audio to understand the offer, revise the post before it goes into the queue.
A launch post often combines a short claim, product screenshot, graphic, video, link card and destination page. Each part can carry information that the others omit. The question for this review is simple: can someone understand what is available, why it matters and what to do next without relying on one sensory route? This worksheet applies to a single X announcement near its publishing deadline. It does not replace an accessibility audit of the product or website.
Start with the message, then inspect the media
Write the post’s essential proposition in one sentence: what was launched, who can use it and what the link offers. Compare that sentence with the visible post text. If the sentence exists only inside a graphic, move it into the post or destination. A reader may never open the image, and an image description is not a substitute for a clear public message.
Next list every media item in the scheduled post. Record what information each item adds. A screenshot might show where a new feature appears. A diagram might explain a process. A decorative background might add no new information. Those need different descriptions. The W3C WAI image decision tree helps distinguish informative, functional, text-bearing and decorative images. Use it as a review aid, then write for the actual reader and context rather than copying a generic alt-text formula.
If the asset itself has not passed factual review, resolve that first. Our screenshot selection worksheet covers whether a product image accurately represents what users can access. An accurate screenshot can still be inaccessible when its meaningful contents are missing from the post and description.
Add descriptions where they carry real information
X’s image-description instructions explain how to add a description to each image in the X composer. They also distinguish image descriptions from video: the image field cannot be added to a video. Check the composer in the account and workflow your team actually uses. Do not assume that a description stored in a creative brief automatically transfers into a scheduled post.
For an informative screenshot, identify the feature, the relevant state and the one or two details a reader needs. Avoid narrating every button. Avoid repeating the entire post verbatim. A good description supplies visual context that the text lacks. For a graphic that contains a deadline or access rule, place that fact in the visible post or linked page as well. The description can explain the graphic’s layout, but it should not become the sole public record of a condition.
Consider a hypothetical example: an invented company, Northstar, is announcing a reporting view. The visible post says, “Our reporting view is available for eligible workspace accounts. See the setup steps.” The attached screenshot shows a left navigation item marked “Reports” and a panel grouping approved post links by campaign. A weak description is “Screenshot of our dashboard.” A more useful one is: “Northstar workspace with Reports selected in the left navigation; the campaign panel lists approved post links beneath each campaign name.” The product owner must still confirm that this view matches the current release. This is sample copy, not evidence from a Nowix client.
If a second image is only a colored launch background with the same product name already in the post, avoid inventing functional details to make its description longer. If a second image shows an important step, describe that step separately. Review multi-image posts item by item; one generic description does not explain four different panels.
Use a media and message decision table
The following is a hypothetical review record, not a measured client result. It shows how a launch owner can turn an accessibility concern into a specific edit and approval.
| Final post element | Review finding | Required edit | Owner and release gate |
|---|---|---|---|
| Visible post text | “Available now” appears only in the graphic | State verified availability and access conditions in the post or destination | Product owner confirms availability |
| Product screenshot | Description says only “new dashboard” | Describe the relevant Reports navigation and campaign grouping | Product owner checks the depicted version; publisher checks the attached image |
| Launch graphic | Small text includes a signup condition | Move the condition into readable text; simplify or replace the graphic | Copy owner checks parity with the destination |
| Video clip | Spoken instruction has no text path | Add suitable captions and a concise text explanation of the action | Media owner checks playback and text; publisher checks final upload |
| Link destination | Post promises setup steps but page opens on a generic home screen | Link to the correct page or revise the call to action | Site owner checks the logged-out path |
The table is a release gate, not a score. A post should not pass because four of five rows are green when the remaining row contains the only signup condition. Mark the specific dependency, assign an owner and inspect the revised version. If a video cannot be made understandable in time, a clear text post with a verified destination may be a better launch asset than an unexplained clip.
Read the post in the order a reader encounters it
Open the final composer preview. Read the visible text without opening the media. Does it state the central claim and the next action? Then inspect each image description. Does it add information a nonvisual reader needs without contradicting the image? Finally follow the link in a logged-out session and compare its headline, availability and call to action with the X post.
Pay attention to abbreviated product names and unexplained jargon. A launch team knows its internal labels; a first-time reader does not. Write the first reference clearly, and use a short label only after its meaning is established. Keep hashtags and mentions purposeful. If a sequence of them interrupts the sentence, move them to the end or remove those that add no discovery or context.
For video, review what the viewer must hear or see to follow the explanation. The X image-description field is not a video alternative. If the clip relies on spoken steps, provide captions or a text explanation appropriate to that clip and verify the uploaded version. If important information appears only as on-screen text, make that information available through the post or linked page. The release owner should check the actual player rather than relying on a caption file name in a folder.
Keep a compact approval record
Copy this short record into the launch document before the scheduling handoff:
Post and slot: Account, target time, final text and destination URL.
Essential message: One sentence stating availability, audience and next action.
Image review: Each image, purpose, final description and factual reviewer.
Video review: Captions or text route, playback result and media reviewer.
Destination review: Logged-out path, matching promise and page owner.
Final composer check: Publisher, account, media fields, preview and confirmation time.
Unresolved gate: Exact issue, owner and hold decision.
A document approval is useful only if the scheduled artifact matches it. Reopen the queued post after edits, especially when a tool imports text and media separately. If the final preview differs from the approved record, correct the queue or hold the slot. Keep the difference visible so the next reviewer knows which version was cleared.
For help writing and preparing an X launch announcement, work directly with Knowix on an X campaign. Bring the approved product facts, intended audience, draft post, media and destination. Knowix can help shape the message and publishing review with your team; the product owner remains responsible for confirming what the product actually does. The enquiry form below sends your brief directly to Knowix.
Frequently asked questions
Does every image in an X launch post need a description?
Review each image separately. Describe information needed to understand the post; a purely decorative image may need only a brief treatment, while a product screenshot needs its meaningful detail conveyed.
Can image alt text replace a caption in the post?
No. Keep the main product message and call to action in the visible post. Use the image description to convey important visual information that the visible copy does not already explain.
What if the launch graphic contains important text?
Move the essential offer, availability or instruction into the visible post or destination, then describe any remaining information in the image description. Do not make a graphic the only route to the message.
Can the image-description field describe a video?
No. X's image-description instructions say that image descriptions cannot be added to videos. Review video captions and a suitable text explanation separately.
Who approves the accessibility review before scheduling?
The content owner checks the message, the product owner verifies factual details, and the publishing owner confirms the final rendered post and media fields in the actual X composer.