A product video often puts its most important information into a tiny visual change: a request changes status, a button becomes available, or a result appears in a panel. If the explanation is just "and there you go," someone who cannot see that change misses the point of the scene.
I'd plan how the information will be available before recording or animating the video. Captions are part of that work, but they don't describe a visual result that nobody says aloud. The player and the page around it matter too. Here's a practical production workflow, not a claim that following a checklist guarantees accessibility or compliance.
List what someone needs to learn from each scene
Beside each planned scene, write the information it conveys. Separate the essential content from decoration. A moving background may add atmosphere, while a change from "pending" to "approved" explains what the product did. The second needs an equivalent explanation for someone who cannot see it.
W3C's media guidance describes visual information as including the on-screen content needed to understand the video. Its description guidance covers ways to make that information available, including integrating it into the main audio. Use that distinction while planning, rather than trying to narrate every decorative detail.
Write narration that explains the result
For a hypothetical approval demo, "the manager approves the request, and its status changes to approved" communicates more than "click here, and you're done." It also gives the editor a clear reason to hold on the result instead of cutting immediately to the next scene.
You don't need to name every pointer movement. Explain the action and the meaningful consequence, using the same terms as the product. Avoid referring only to position or color, such as "the green item over there," when the item has a name or status you can say.
W3C discusses integrated description as a way to include essential visual information in the original production. Where that is not enough, evaluate the other description options for the video and its publishing environment. Leave room in the edit for the explanation rather than speeding up the voice to fit.
Plan a written version that preserves the useful information
A transcript of speech alone may still omit the result if the narration never describes it. While reviewing your written version, check that the reader can follow the same meaningful sequence: starting state, action, and outcome. Identify relevant visual information clearly instead of silently passing it off as spoken dialogue.
Keep the written explanation easy to find next to the player. For a complex walkthrough, it can help to link the relevant product documentation as well. That lets someone inspect a detail at their own pace rather than scrubbing repeatedly through the video to catch a label.
Choose the player before promising an experience
An accessible media file can still be difficult to use inside a poorly designed player. W3C recommends considering existing players with accessibility support rather than assuming a custom player is easy to get right. Its guidance includes keyboard operation and accessible control labels among the features to evaluate.
For your publishing destination, check what the actual embed supports. If your plan needs a description track, captions, or an adjacent transcript, make sure the player and page can deliver those assets. Do this before the final edit, when it is still straightforward to adjust the production approach.
Review the controls using a keyboard
On the published page or a faithful preview, put the mouse aside and move through the interface using the keyboard. Check that you can reach the player, identify which control has focus, start and pause playback, and move on to the rest of the page. If a menu opens, check that you can operate it and leave it.
Also review control names with appropriate assistive technology rather than assuming an icon is self-explanatory. A control that looks like a familiar play symbol still needs to communicate its purpose. Keep a record of any problem, the browser and player used, and the exact action that failed so the person fixing it can reproduce it.
Check the information without relying on one sense
Listen without watching and note any moment where the meaning depends on an unseen visual. Then watch without sound to check the silent viewing experience and caption coverage. These passes catch different problems, so one does not substitute for the other.
Inspect labels, charts, and state changes at the size the video occupies on the page. Use words or other cues alongside color when it carries meaning, and avoid placing essential text under controls or captions. If a scene changes before the explanation is understandable, revise its timing or reduce what it asks the viewer to follow.
Give accessibility work an owner in the production brief
Add the required deliverables to the brief alongside the video itself: reviewed captions, the chosen description approach, a written version where needed, and the player checks. Assign someone to verify the final uploaded assets, because the export folder and the public page can easily end up with different versions.
Keep accessibility review part of later updates too. A rewritten scene may introduce visual information absent from the narration, while a new embed may change the controls. These practical checks are a starting point for finding problems; where you need a formal assessment, evaluate the complete experience against the applicable requirements rather than treating a finished video as proof.