Evaluating current state of a screen reader in JavaScript

最后都变了- 提交于 2019-12-04 09:08:42

TL;DR What you are looking for does not exist in the browser

Sound like you are developing a game, If that is true, then what you could do is completely take over the announcements that are happening - essentially implementing your own screen reader. This could be achieved by implementing an application region with a virtual "cursor" on the controls manipulated by the keyboard. This calendar widget shows how this can be achieved for both keyboard and gesture control.

http://dylanb.github.io/datepicker/datepicker.html

Audio output could be implemented through your own audio pipeline. If you have the ability to play audio, then writing this should be reasonably trivial but mixing choices and priorities might be the hard part.

You should not only be announcing the controls a user moves to when they move to different controls, but you should also have an "audio description" track that describes what is happening in the animations if these are important.

How you mix the sounds depends on what is most important at any given time and whether there is any "real-time" component to the user's interactions with the game.

You have to read audio control part of the WCAG (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html)

In fact, what you want is quite the opposite of what a people with disabilities would want.

What is needed is to be able to stop the audio in your application, and to start it again on demand.

What I would do is giving a control to pause the audio in your application, giving the user the ability to know that your application want to tell him something with a little beep (<3s) when audio mode is turned off.

Screenreaders are not fully integrated with browsers, so it's quite difficult to find a better solution if you want to have full support of accessibility devices.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!