Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Motion actuation errata from issue 727 #733

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 2 additions & 12 deletions guidelines/sc/21/motion-actuation.html
Original file line number Diff line number Diff line change
@@ -4,18 +4,8 @@ <h4>Motion Actuation</h4>

<p class="conformance-level">A</p>

<p class="change">New</p>

<p><a>Functionality</a> that can be operated by device motion or user motion can also be operated by <a>user interface components</a> and responding to the motion can be disabled to prevent accidental actuation, except when:</p>

<dl>

<dt>Supported Interface</dt>
<dd>The motion is used to operate functionality through an <a>accessibility supported</a> interface;</dd>

<dt>Essential</dt>
<dd>The motion is <a>essential</a> for the function and doing so would invalidate the activity.</dd>
<p><a>Functionality</a> that can be operated by device motion or user motion can also be operated by <a>user interface components</a> or another accessibility supported interface, and responding to the motion can be disabled to prevent accidental actuation.</p>

</dl>
<p>Exception: The motion is essential for the function.</p>

</section>
8 changes: 4 additions & 4 deletions understanding/21/motion-actuation.html
Original file line number Diff line number Diff line change
@@ -13,10 +13,10 @@ <h1><strong>Motion Actuation</strong>
<section id="intent">
<h2>Intent of this Success Criterion</h2>
<p>The intent of this success criterion is to ensure that functions that are triggered by moving a device (for example, shaking or tilting) or by gesturing towards the device (so that sensors like a camera can pick up and interpret the gesturing), can also be operated by more conventional user interface components, unless the motion is essential for the function or not using motions or gestures would invalidate the activity.</p>
<p class="note">This criterion concerns input through sensors which respond directly to motions such as gesturing towards, tilting or shaking a device. It does not cover the movement of users through space as registered by geolocation sensors or beacons, or events observed by the device other than intentional gesturing by the user. It also does not cover indirect motion associated with operating a keyboard, pointer, or assistive technology.</p>
<p>Devices often have sensors that can act as inputs, such as accelerometer and gyroscope sensors on a phone or tablet device. These sensors can allow the user to control something by simply changing the orientation or moving the device in particular ways. In other situations, web content can interpret user gestures via the camera or other sensors to actuate functions. For example, shaking the device might issue an "Undo" command, or a gentle hand wave might be used to move forward or backward in a sequence of pages. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments. Functionality must be implemented in a way that other or additional means of activation are available.</p>
<p>In addition, some users may accidentally activate sensors due to tremors or other motor impairments. The user must have the ability to turn off motion actuation to prevent such accidental triggering of functions. Applications may be able to meet this requirement by supporting operating system settings which allow the user to disable motion detection at the system level.</p>
<p>Some applications are specifically created to use device sensor data. Examples of content that are exempt from this requirement include a pedometer that relies on device motion to count steps.</p>
<p class="note">This criterion concerns input through sensors which respond directly to motions such as gesturing towards, tilting or shaking a device. It does not cover the movement of users through space as registered by geolocation sensors or beacons, or events observed by the device other than intentional gesturing by the user. It also does not cover indirect motion associated with operating a keyboard, pointer, or assistive technology.</p>
<p>Devices often have sensors that can act as inputs, such as accelerometer and gyroscope sensors on a phone or tablet device. These sensors can allow the user to control something by simply changing the orientation or moving the device in particular ways. In other situations, web content can interpret user gestures via the camera or other sensors to actuate functions. For example, shaking the device might issue an "Undo" command, or a gentle hand wave might be used to move forward or backward in a sequence of pages. Some users with disabilities are not able to operate these device sensors (either not at all, or not precisely enough) because the device is on a fixed mount (perhaps a wheelchair) or due to motor impairments. Functionality must be implemented in a way that other or additional means of activation are available.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably more the part where the concept of having an alternative "accessibility supported" interface is more relevant (e.g. where the OS or UA offers an alternative way of triggering/simulating the "sensor"/"motion" data, so the author doesn't perhaps necessarily need to provide their own controls)

<p>In addition, some users may accidentally activate sensors due to tremors or other motor impairments. The user must have the ability to turn off motion actuation to prevent such accidental triggering of functions. Applications may be able to meet this requirement by using an <a href="../conformance.html#accessibility-support">accessibility supported</a> operating system settings which allows the user to disable motion detection.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not convinced that the "accessibility supported" thing is relevant to this part, in reference to OS settings. it's outside of the scope of WCAG to determine whether or not the OS setting is accessibility supported or not, surely?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't an OS setting like reduce-motion fit into this? I'm not saying that querry is useful here, but it is an example of an OS system setting that could be used in a similar way. If there were a similar query to prevent the detection of motion, that could work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't an OS setting like reduce-motion fit into this?

As noted in the original issue, we have not normally allowed OS-level features to serve as a workaround for author-implemented content. For example, authors are not allowed to point to iOS or Android touch assist features as a means of overcoming the requirements of Pointer Gestures. The exception I can think of to this is the user agent zoom feature to meet Resize, which is specifically called out in that SC as allowed.

<p>Some applications are specifically created to use device sensor data. Examples of content that are exempt from this requirement include a pedometer that relies on device motion to count steps.</p>


<section id="benefits">