(Eventually, when browsers catch up, this should not be needed.)Īs far as general accessibility goes, WCAG 2.0 ( Web Content Accessibility Guidelines) recommends that any audio that plays automatically for more than 3 seconds should have an accessible means to pause or stop the audio.
I've seen some pages that add HTML5-based controls plus javascript after the audio tag so they can provide their own UI to ensure that keyboard or screenreader users can play/stop the audio as needed. DOM, MSAA) that screenreaders do, so any technique that "detects a screenreader" will likely detect these also - so you cannot assume that it means that the user is fully blind and using only speech.Īs things currently stand, the audio tag is currently not universally accessible, different browsers have different levels of accessibility support - see HTML5 Accessibility and scroll down to audio for more details of current support.
Additionally, other types of accessibility tools - such as content highlighters and voice input apps - use the same techniques and APIs (eg. Note that not all screenreader users use text-to-speech many use braille output. It's best to concentrate on writing good clean HTML5 in the first place. Even if you get it right for one group of screenreader users, you may get it wrong for another group.
You should probably not try to do anything special even if you could detect that a screenreader is running.
0 kommentar(er)
