Motion actuation (2.5.4) question on exception

[alastc]

Is the ‘supported interface’ exception of Motion Actuation supposed to apply to disabling motion actuation?

To snip the SC text to this bit:

...responding to the motion can be disabled to prevent accidental actuation, except when: The motion is used to operate functionality through an accessibility supported interface;

What would an accessibility supported interface for disabling motion actuation be? Presumably that's an operating system thing? In which case wouldn't that come under accessibility supported?

Or is it (in this scenario) simply that the getting to and applying the setting is accessibility supported?

I think an little explanation of that in the understanding would be helpful.

[patrickhlauke]

From memory when this was discussed at the time, the accessibility supported interface bit doesn't relate to the "can be disabled" part, but rather (combining it with the start of the SC) it means (with some editorialising)

Functionality can be operated by device motion or user motion, and the motion used to operate this is also available through an accessibility supported interface

i.e. some kind of (not motion / motion simulating) generally OS level extra interface. e.g. some kind of on-screen "device rotation simulation" or something. admit though that this is very vague and confusing, and should be expanded in understanding.

[jake-abma]

That's also how I interpret / remember it

[patrickhlauke]

this could probably do with a bit more editorial clarification (ideally, if that's possible, in the normative language itself, which seems to kind of have lost its meaning ... not a good sign if it takes guessing/remembering/interpretation to work out what it actually means in real terms)

[alastc]

So currently I read the exceptions applying to both the "others methods" bit, and the "disable the motion" bit.

Would this be more accurate to the intent?

Functionality that can be operated by device motion or user motion can also be operated by user interface components, unless the motion is used to operate functionality through an accessibility supported interface. Responding to the motion can be disabled to prevent accidental actuation.

Exception: The motion is essential for the function.

I.e. the accessibility-supported interface applies to the first part, and the essential exception applies to both.

So where there is motion features it must:

• Have buttons or an accessibility supported equivelent, and
• be able to turn it off,
• except where it is essential.

[patrickhlauke]

i think one of the problems is that this SC tries to say/do two separate things.

Functionality that can be operated by device motion or user motion can also be operated by user interface components, except when the user agent/platform already provide an accessibility supported interface that provides an alternative (non-motion related) way to simulate device motion (as these interfaces serve the same purpose, without needing additional interface components). Responding to motion can also be disabled to prevent accidental actuation, except where the motion is essential for the function and doing so would invalidate the activity.

(overly verbose, but to get the point across about the supported interface)

[edit: to be clear, in essence yes, this says the same as alastair's rewrite, but in that the sentence " unless the motion is used to operate functionality through an accessibility supported interface" still seems to put the cart in the front of the horse and makes little sense)]

[alastc]

Perhaps more simply this then?

Functionality that can be operated by device motion or user motion can also be operated by user interface components or another accessibility supported interface.

Leaving the accessibility supported aspect to the understanding doc...

[patrickhlauke]

yup, that works too for me. so in full:

Functionality that can be operated by device motion or user motion can also be operated by user interface components or another accessibility supported interface, and responding to the motion can be disabled to prevent accidental actuation, except when: Essential The motion is essential for the function and doing so would invalidate the activity.

(so the exception for essential applies to both the "there's an alternative interface component/accessibility supported interface" and "can be disabled") and the requirement of the SC is both about having a non-motion way to trigger stuff AND being able to turn it off.

this also raises the question (probably to be explored in the understanding): does a system/OS/UA level setting of "turn off/don't expose device motion" or similar count as a way to disable this for web content? is this like a "mechanism is available" type thing, where it's not necessarily the content itself that needs to provide this? i'd assume yes, if it's widespread/available... same way the question can also be posed about system/OS/UA level alternative control interfaces, I guess...

[mbgower]

@patrickhlauke said

does a system/OS/UA level setting of "turn off/don't expose device motion" or similar count as a way to disable this for web content? is this like a "mechanism is available" type thing, where it's not necessarily the content itself that needs to provide this? i'd assume yes, if it's widespread/available... same way the question can also be posed about system/OS/UA level alternative control interfaces, I guess...

I think the answer has to be 'no' at the moment. For instance, there is widespread existence of OS-level affordances for multi-touch operation through a single touch, yet these are not allowed as a workaround for Pointer Gestures.

[mbgower]

I think this issue stems from a misreading of the SC text. The wording talks about motion, and the exception is about that motion. The second phrase in the SC -- the ability to disable the motion response -- is previcated on the motion existing. So the Supported Interface exception is about the motion. You'd really have to get yourselves in a knot to suggest otherwise.

If folks are succeeding in knot tying, I suggest that the whole Supported Interface exception was added after the formation of the SC text, and if that exception is causing issues, we should consider removing it as a possible solution. When in doubt, take it out. We don't have any similar language in 2.1.1 Keyboard, for instance.

[patrickhlauke]

So the Supported Interface exception is about the motion. You'd really have to get yourselves in a knot to suggest otherwise.

authors trying to find a loophole, and/or auditors trying their hardest to fail something they don't like, are both groups known to delight in knot tying...so if taking the rope away altogether helps clarify this, i'd be all for it.

[steverep]

I'm guilty of writing that exception. Here's my answer...

Is the ‘supported interface’ exception of Motion Actuation supposed to apply to disabling motion actuation?

Yes, absolutely. That exception came about as a means to give exception to motion associated with operating a keyboard, touch screen, assistive technology hardware, etc. Your fingers and physical keys all move to operate them. These would all be considered accessibility supported interfaces. The exception was written generically not only to encompass those interfaces mentioned, but also as a means of future proofing. If you don't apply it to the disabling requirement, then you'd be requiring web content to provide a means to disable a keyboard, which is clearly not desired or even possible.

The understanding for this SC currently has the following sentence in a note:

It also does not cover incidental motion associated with operating a keyboard, pointer, or assistive technology.

This is incorrect and should be removed and replaced with a detailed explanation of the exception.

[patrickhlauke]

@steverep that exception is, from what i remember, meant to mean, in essence "we're talking about interfaces that react to motion. this doesn't mean the motion that a finger makes to press a key, or move a mouse, or whatever...but actual JS or whatever that reacts to motion from motion sensors" otherwise it could be misread that any motion (i.e. moving a mouse, typing on a keyboard) must also be turn-offable (essentially meaning that a site must offer an option that says "don't react to mouse interactions, as they were caused by a motion of the user's hand to move the mouse", "don't react to keyboard presses, as those were caused by the user's fingers pressing a key", i.e. nonsense)

[steverep]

@patrickhlauke, are you agreeing that the exception needs to apply to both the UI component alternative and the disabling of the motion response?

"we're talking about interfaces that react to motion. this doesn't mean the motion that a finger makes to press a key, or move a mouse, or whatever...but actual JS or whatever that reacts to motion from motion sensors"

That's basically right but way too simply put for a testable criterion. It gets complicated quick unless you separate the hardware from the software, i.e. separate the sensor from the interface. When you do that, there's really no such thing as a "motion sensor", but various types of sensors can be used to indicate motion through analysis of the input.

[fstrr]

@alastc Hey. What do you want to do with this issue? It was last updated almost five years ago.