-
Notifications
You must be signed in to change notification settings - Fork 281
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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> | ||
<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> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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"> | ||
|
There was a problem hiding this comment.
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)