W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

Re: Vibration API: making feature detection possible

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>
Message-ID: <49406920-B07E-4C56-AD5C-3A1148D9827C@intel.com>
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.


Received on Thursday, 17 October 2013 14:03:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC