Re: Mouse Lock

I recently saw what appeared to be the AG group complaining that the
html WG didn't care to specify Accessibility bits even though W3
policy requires considering both internationalization and
accessibility.

I know that we like to innovate and let everyone else backfill the
missing pieces later, but perhaps that isn't a wonderful approach.

On the topic of devices without keyboards, I picked up a MeeGo 1.2
tablet in May. It has no keyboard, and no useful edges. It doesn't
have a right click feature, and it's perfectly reasonable for a web
application to demand to detect gestures and long presses. It has one
real button: Power - which turns the device completely off, after
which it takes an incredibly long time to boot. Not to mention that a
user might not appreciate losing any other unsaved data. It does have
rotation detection (which barely works), again, something which web
applications are free to want to handle themselves. It also has single
sensor which is incredibly quirky and easy to misplace or overlook
which barely functions for task switching. You could claim that it's
sufficient as a way out, but it makes me uncomfortable. Plus there's
no way for a UI to explain to the user how to press it; it isn't
usefully labeled.

On 6/23/11, Charles Pritchard <chuck@jumis.com> wrote:
> timeless,
>
> I agree, it'd be nice to know. I'd really like to see this put toward
> the "AG" (Accessibility Guidelines)
> people, as they're the ones who follow this kind of things.
>
> It's absolutely the case that a user needs an ability to escape from the
> mouse lock context,
> and to have one which lies outside of any processing handled by the
> untrusted scripting environment.
> The *AG practices are always the first to document these needs.
>
> Requiring keyboard for something that locks a mouse is not acceptable;
> a user must be able to release their pointer device without requiring
> a keyboard. The same applies for keyboard locks.
>
> Assistive technologies (AT) have their place in this, and can give some
> leeway to the user agent (UA),
> as long as the UA provides enough semantics to allow the AT to handle
> this kind of work.
>
> Again, these issues are always brought up by AG documents.
>
> I'll give you two examples for pointer device escape:
> 1) "Right click"/context menu; always works.
> 2) "Click and hold"; X number of seconds could pop up a context menu.
> 3) "extreme coordinate and hold"; x seconds on an extreme coordinate
> pops up a menu.
>
> On the extreme-coordinate; an input device which may only signal changes
> in x/y positioning
> may still be used to activate UA menus.
>
> Developers are by all practical purposes, required by existing standards
> and technologies,
> to leave space on the edges of the screen. Though this is mostly related
> to "safe areas"
> on televisions, the principle applies beyond that, and is de facto
> required by existing
> full screen semantics [wherein the top extremes create a dialog to escape].
>
> So, by luck of history; extreme coordinates are encouraged and in
> practice, required
> as a means of escaping mouse lock.
>
> There are certainly cases where extreme coordinates could be useful to
> an application.
> Those corner cases will have to be thought about, by those implementing
> such apps.
>
> All the best,
>
> -Charles
>
> On 6/23/2011 6:29 PM, timeless wrote:
>> And what if the device in question is just a touchscreen with no
>> keyboard, mouse or hardware buttons?
>>
>> On 6/20/11, Tab Atkins Jr.<jackalmage@gmail.com>  wrote:
>>> On Mon, Jun 20, 2011 at 3:03 PM, Olli Pettay<Olli.Pettay@helsinki.fi>
>>> wrote:
>>>> On 06/21/2011 12:25 AM, Tab Atkins Jr. wrote:
>>>>> The use-case is non-fullscreen games and similar, where you'd prefer
>>>>> to lock the mouse as soon as the user clicks into the game.  Minecraft
>>>>> is the first example that pops into my head that works like this -
>>>>> it's windowed, and mouselocks you as soon as you click at it.
>>>> And how would user unlock when some evil sites locks the mouse?
>>>> Could you give some concrete example about
>>>> " It's probably also useful to instruct the user how to release the
>>>> lock."
>>> I'm assuming that the browser reserves some logical key (like Esc) for
>>> releasing things like this, and communicates this in the overlay
>>> message.
>

-- 
Sent from my mobile device

Received on Friday, 24 June 2011 06:51:51 UTC