matatk
commented
6 months ago Hi @anssiko, thank you for your review request, and for the accessibility checklist info.
We discussed this in an APA call recently; we think that there are some accessibility considerations, and that a section on them would be a helpful addition to your spec. We'd be happy to help you in drafting an accessibility considerations section, and look forward to working with you again. Below is a summary of our thoughts.
Would you like us to file either one combined issue in your spec's repo for all of these, or a separate issue for each part?
Here are the main things we would ask developers who are building things with the spec to consider:
-
It's important for alternative means of providing the input to be available, so that people who can't make the required gestures have another way to interact - examples may include people with dexterity-related disabilities, or people who use eye gaze, or head-tracking input.
-
For games, consider supporting either game controller, keyboard or mouse input in addition.
-
For web apps, consider providing UI, such as a button, menu command, and/or keyboard shortcut, to perform the function.
-
-
It's important that users can undo any accidental input - this may be particularly relevant for people with tremors.
There are two further things that are out of scope of things built with the spec, but it could be helpful for developers to understand why these can present barriers to people (possibly a wider range of people than they were expecting):
-
It's important that the user is able to turn off the use of this type of input - e.g. for users with tremors, the shake-to-undo gesture use case is very cool, but may not accessible for some. This could be done by declining permission, or more likely by changing a browser or OS setting.
-
It's also important that the device's orientation can be locked - a primary use case being someone who is interacting with a touch device, such as a phone, non-visually. They may have built up 'muscle memory' as to where things are on the screen in a given orientation, and having the layout shift would break their ability to navigate. Again, this would most likely be done at OS level.
I'm not sure if this fits within scope (it sounds like it is possible to query the current orientation, as well as to be notified when it changes), but it may be worth noting that web content must work (i.e. be functionally equivalent) regardless of the orientation of the device - that is intended to support the use of devices that may be mounted, e.g. in a fixed position on a wheelchair or somewhere else such that the user doesn't need to hold the device in order to interact with it.
anssiko
name of spec to be reviewed: DeviceOrientation Event Specification
URL of spec: https://www.w3.org/TR/orientation-event/
What and when is your next expected transition? A new CR Snapshot expected in March 2024
What has changed since any previous review? See https://www.w3.org/TR/orientation-event/#changes
Please point to the results of your own self-review https://github.com/w3c/deviceorientation/issues/131
Where and how to file issues arising? https://github.com/w3c/deviceorientation/issues
Pointer to any explainer for the spec? https://w3c.github.io/motion-sensors/
Other comments:
This spec initially reached CR in August 2016 (history) and was retired in 2017 due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the changes section.
These changes since the previous CR Snapshot from 2016 align the specification with widely available implementations, improve interoperability including testability, and add new features for enhanced privacy protections.
The Accessibility Checklist responses expand on a few areas that may benefit from your comment and review prior to our expected publication. Feedback on other aspects is also welcome.
Thank you for your accessibility review!