A screen reader is assistive software — examples include NVDA, JAWS, and VoiceOver — that intercepts the accessibility tree of an operating system and browser and converts it into synthesised speech or refreshable Braille output, allowing blind and low-vision users to navigate and interact with digital content entirely without relying on sight. For a learning video platform to be screen-reader accessible, every UI element the player exposes — play/pause, volume, chapter list, caption toggle, speed control — must carry a correct ARIA role, label, and state so the screen reader can announce it accurately. WCAG 2.1 AA Success Criterion 4.1.2 (Name, Role, Value) and 1.3.1 (Info and Relationships) are the relevant requirements. A video player that uses only custom CSS and divs without ARIA attributes will be completely opaque to a screen reader; the learner will hear nothing useful. Screen readers also consume captions indirectly: they cannot read a closed-caption track from the video itself, so the platform must expose the caption text in the DOM or provide a linked transcript. The interaction between screen readers and web players is browser- and screen-reader-version-sensitive, meaning testing must be done with actual assistive technology on the target browsers rather than only running automated audits. Supporting screen readers is often the most complex accessibility work on a video platform and should be planned from the start rather than retrofitted.
