- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 17 Oct 2013 14:01:03 +0000
- To: Nicholas Doty <npdoty@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>
- CC: Peter Beverloo <beverloo@google.com>, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "mvanouwerkerk@chromium.org" <mvanouwerkerk@chromium.org>
On Oct 15, 2013, at 6:25 AM, Nicholas Doty <npdoty@w3.org> wrote: >> Is there a strong reason to need to know whether or not vibration is enabled, when asking for vibration with the expectation for best effort may be good enough? >> >> What is the use case for the change? If vibration is not possible what would be reasonable fallbacks (flash the screen a la emacs)? >> >> Being able to provide alternative behavior when vibration is used as a form of haptic feedback. > > For at least some of those fallback cases, the browser would likely be in a better position to provide alternative feedback than the web application. For example, "visual beep" is an option in some operating systems or terminal environments as a system-wide setting. When I change preferences in my Mac OS Accessibility panel, beeps are registered by applications in the same way, but presented to me differently; not every application on my machine has to check the alert audio status and do something visual in response. Personally I agree with Nicholas. It would be better to let the UA handle the fallback. Clever UAs can use alternative means such as flash a visual indicator in chrome when vibrate() is called, or play a sound etc. knowing the user's accessibility preferences. Thanks, -Anssi
Received on Thursday, 17 October 2013 14:03:19 UTC