Automatic previews can compete with screen-reader speech, create distraction and transfer data before a viewer chooses content. Use supported autoplay controls and pause options. Muting a preview changes sound, but does not necessarily stop motion or network transfer. Inspect preview sound and movement as separate options, then check whether each choice persists after reopening the app. Muting may stop competing audio while video continues to animate and download, so choose the supported behavior that addresses the viewer's actual access or data concern.
Separate sound and motion
Each may have its own setting. Find the app's preview-audio control and its separate autoplay or motion control where available. Muting a trailer can make screen-reader speech easier to hear, but the moving images may still distract or be uncomfortable. Conversely, reduced interface animation may leave preview audio enabled. Record which setting affects which behavior and avoid assuming one switch solves both. There is no need to keep replaying an uncomfortable preview to establish that the app lacks a suitable stop option.
Keep control visible
A viewer should be able to stop optional movement. Check that pause, stop or back remains reachable with the viewer's remote, keyboard or assistive input. A preview that starts merely because a card receives focus can interfere with discovering the next control, particularly if sound competes with announcements. Where autoplay can be disabled, confirm the catalogue stays usable afterwards and the preference persists for the intended profile. If no control exists, report the exact trigger and missing exit path rather than treating the optional preview as necessary programme playback.
Respect data limits
Preview downloads can matter on a capped connection. A silent video can still fetch and decode media, so mute is not a reliable data-saving control. Prefer a documented preview-disable setting when avoiding optional transfers is the goal. If checking usage, compare the device's ordinary data statistics carefully and account for other app activity rather than attributing every byte to the preview. Keep the main programme quality preference separate, since disabling browsing previews need not imply that the viewer wants a lower-quality chosen film.
A practical sequence
0 of 4 steps completed on this page.
An example to work through
A silent preview still moves behind text until autoplay is stopped separately. The viewer mutes previews and screen-reader announcements become easier to hear, but cards still launch moving video. Turning off the separate preview-playback option addresses the remaining movement and optional transfer, illustrating why muted autoplay and disabled autoplay are different supported choices.
Questions about this topic
Does mute stop all data?
Not necessarily. Video can continue downloading and playing even when its soundtrack is silent.
Does reduced motion always stop previews?
App behaviour varies. Check the actual app's preview control instead of assuming the system preference disables every video.
