A screen reader can announce controls and focus, but a TV application must label and expose its interface correctly. Operating-system support alone does not guarantee that every player menu is usable. Test essential actions before committing to a particular app. Test the actual path from choosing a programme to controlling playback, using the screen reader the viewer relies on. A device-level accessibility feature cannot compensate for every missing app label or unreachable control, so record the precise task and announcement that fail.
Start with core tasks
Open a category, select a channel and find playback controls. Start with opening a category, locating a known item and selecting play, then find pause, audio and subtitle controls. Listen to what is announced at each step rather than assuming a visible icon has a useful spoken name. Check whether focus order follows a sensible sequence and whether dialogs can be closed. A partially readable home screen does not establish that search, account screens and essential playback actions are equally usable.
Listen for labels
Unlabelled buttons make navigation harder even when focus moves. An announcement such as button without a purpose can leave the viewer unable to distinguish controls. Note the words actually spoken and whether selection changes are announced, especially for captions and audio tracks. Interface screen reading is separate from audio description of the programme, so a narrated film does not demonstrate accessible menus. Where a control lacks a label, describe its visible location as supplementary evidence rather than asking the viewer to memorize an unexplained sequence indefinitely.
Report exact barriers
Name the screen and control rather than only saying inaccessible. Record the device model, app version, screen-reader version or system version, and the exact remote or keyboard actions leading to the barrier. Include expected and actual announcements, keeping account names and private viewing details out of any recording. A reproducible failure at the subtitle menu is more actionable than a general accessibility complaint. If a supported alternative input works, mention it as a temporary route while retaining the report about the original blocked task.
A practical sequence
0 of 4 steps completed on this page.
An example to work through
The system settings read aloud correctly while a player image-only button has no useful spoken name. The play button is announced clearly, but the subtitle icon is announced only as button and the choices cannot be identified. The viewer reports that specific menu and spoken output, showing why successful reading of the main catalogue did not establish accessible caption selection during playback.
Questions about this topic
DoesTalkBack read every app perfectly?
No. App implementation matters. App labels, focus order and exposed control states still determine the usable experience.
Is this the same as audio description?
No. One reads the interface; the other describes programme visuals. Screen reading describes interface elements; audio description supplies relevant visual information within the programme.
