Motion actuation errata from issue 727 #733
Conversation
Adjusting the exception and little tweak to the understanding doc.
alastc
changed the title
| <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.
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.
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.
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>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> |
There was a problem hiding this comment.
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)
|
Think the understanding doc needs a more thorough look, as I feel it still talks about the "accessibility supported" aspect in the wrong place. but the change to the normative wording of the SC looks good to me per the other conversation. |
alastc
added
ErratumRaised
Adjusting the exception and little tweak to the understanding doc, based on 727.
Closes #727