A useful accessibility report states the task, device, app version, assistive technology and exact barrier. Describe what should happen and what actually happens, without exposing credentials. A repeatable report is more actionable than a broad claim that an app is inaccessible. Describe the smallest task that fails and what the viewer expected to happen. Include the active input method and assistive technology, because a button may look correct while lacking a spoken label, a reachable focus position or a usable switch-scanning target.
Name the control
Unlabelled subtitle button is clearer than screen problem. Identify the screen, control and state as specifically as possible: for example, the subtitle button during playback is announced only as button, or focus cannot leave the audio dialog. State the expected action and actual result separately. A report that says the app is inaccessible gives little guidance on reproduction. A concise task-level description makes it easier to distinguish missing labels, visual contrast problems, focus traps and content availability issues.
Include the input method
Remote, keyboard, screen reader and switch can reveal different issues. Record the device model, system and app versions, assistive feature and supported input used. Add the starting screen and shortest sequence of remote presses, keyboard keys or scanning actions leading to failure. Mention whether another input works, but keep the original barrier clear. A mouse workaround does not erase a remote-navigation defect, and a successful spoken-menu announcement on the home screen does not establish that every later playback control is exposed correctly.
Preserve privacy
Crop account keys and private programme URLs from evidence. Review screenshots and recordings for account names, credentials, signed media addresses and private viewing details before sharing. A screenshot can document a faint focus border but cannot capture the screen reader's exact words by itself. Where useful, provide a written transcription of those announcements or a safe short recording using nonprivate content. Keep evidence limited to the reported barrier so support receives a concrete reproduction without unnecessary personal information or unrelated logs.
A practical sequence
0 of 4 steps completed on this page.
An example to work through
With the screen reader on, focus reaches a button but announces no label, preventing independent activation. A report states that opening the audio menu with the remote moves focus to an unnamed button and back does not close the dialog. Device and app versions plus that short sequence give the developer a concrete navigation and labeling problem to reproduce without exposing account credentials.
Questions about this topic
Does a screenshot prove spoken output?
A text description or safe recording may be needed. Describe the actual announcement or provide a privacy-checked recording if appropriate.
Should passwords be included?
No. Support can investigate a reproducible interface barrier without receiving secrets or private source addresses.
