A clear accessibility-track report identifies the programme and the observable problem. It does not require the viewer to explain a diagnosis or send private account secrets. Give the responsible platform enough detail to distinguish the item, track and result, then keep the case reference for follow-up.
The goal is a usable description of the media problem. A short precise report is often easier to investigate than a broad statement that accessibility does not work.
Identify the exact item
Name the title, season and episode where relevant, plus the edition or viewing route that distinguishes it. Similar titles and different versions can otherwise lead support to inspect the wrong material. Include the observation date rather than a later file-edit date.
State the selected track label exactly as shown, including its language and any SDH, CC or audio-description wording. Do not substitute a broader category if the actual label is available. The receiving team needs to know what you selected, not what you hoped the app would supply.
Describe the symptom as an observation
Useful categories include a track not listed, a listed track not selectable, selected text not appearing or content that seems unrelated to the programme. If timing or readability is the issue, describe the narrow result without assigning an unverified cause.
For a hypothetical report, you might say that the named caption track was selected in a particular episode but no text appeared during the checked dialogue section. That does not claim every episode is affected. It gives support an identifiable task to investigate.
Use a small example and protect privacy
Where a scene reference helps, provide a concise location or short description through the genuine reporting route. Avoid copying substantial dialogue or uploading the programme itself. Inspect screenshots for usernames, private source addresses, payment details and unrelated household information before sharing them.
You can state the required feature without personal medical information. The report concerns the programme’s available and delivered track. If a support form asks for information that seems unrelated, consider whether a functional description can answer the question more appropriately.
Keep the result and limits
Save the request, case reference and actual response. If you try a suggested action, record the resulting observation rather than marking it successful automatically. A referral to another team is progress in routing, not proof that the track has been corrected.
If a later check works, add a dated update and identify the edition tested. Keep the earlier report as context. The finished record should say which issue was observed, what changed and what remains untested, so a narrow improvement is not inflated into a promise about every title or future session.
Useful answers
Do I need to disclose a disability to report missing captions?
A practical report can describe the required feature and observable problem without medical detail.
What is more useful than saying subtitles are broken?
Name the exact item, selected track label and stage that failed, then describe a concise observed example through genuine support.