-
Notifications
You must be signed in to change notification settings - Fork 252
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
Update motion-actuation.html #693
Conversation
Changes to improve understanding and readability. The only one which maybe needs scrutiny is my replacement of "indirect" with "incidental"
Hi @mbgower you have removed, in examples, "A user can choose an application setting which turns off Shake to Undo features." That may be fine - I am not quite sure about the implications. Does it mean that content would fail that does not offer another way of undoing actions (even though shake to undo is a system level feature)? Say, you accidentally delete input in a textarea, shake the device, input is restored. Without 'shake to undo' there may be no explicit way to undo that deletion. Would that already be a failure of 2.5.4? I guess not, but maybe we should be clearer still about this aspect (e.g., scoping the SC to motion implemented by content, excluding functionality that is implemented on UA or OS levels). |
i'd say yes, that's the point of 2.5.4? "Functionality that can be operated by device motion or user motion can also be operated by user interface components " i'd also tend to fail under 2.1.1 in this case. |
@patrickhlauke The ability to undo by shaking may just be considered a OS-supplied bonus (I believe there is no equivalent for Android users?) and users in general may not have that option to undo. So taking your line, would that not mandate authors to replicate OS-provided functionality across platforms inside their content to cater for any case where the OS functionality is not available? That seems untenable. |
ah, i thought you meant actual functionality implemented by the page author. the iOS typing and shake-to-undo is a functionality of the user agent. as that's not a functionality of the web content itself, then it's exempted (and i don't believe we need to be explicit about that, since we don't generally concern ourselves with the UA). perhaps the text should mention that it's a "custom shake-to-undo functionality" (implemented using JavaScript in the web content) |
It actually says application setting, not OS setting, so it may have been clear enough. Still I wonder why Mike thought it better to remove this bit. it would probably be better to focus on some motion functionality that is not also implemented on the OS level (in one platform) - such as 'flick to advance to next slide', or similar. |
added "via" as per AWK comment
I removed this because it is not an author solution. If a device does not offer such an application setting, the app would still fail. If the author implements shake to undo, it is the author's job to offer a means of disabling. As well, they would also have to offer another mechanism to undo. |
Changes to improve understanding and readability. The only one which may need scrutiny is my replacement of "indirect" with "incidental"