Decision on CfC: Device Orientation Ac


All responses received on this Call for Consensus were positive.
However, edits to our text were suggested and accepted as friendly
amendments which our Decision Policy allows. This has lead to further
wording edits as reflected in the attached final version.

There being no objections to this CfC, it is consequently agreed to as a
consensus decision of APA with editorial amendments as reflected in the
attached markdown file.

The head of thread for this CfC can be found here:

Janina and Matthew

Janina Sajka writes:
> Colleagues:
> This is a Call for Consensus (CfC) to the Accessible Platform Architectures (APA) Working Group testing for agreement on an Accessibility Considerations addition to the Device and Sensors Working Group's Device Orientation API. The candidate AC section is attached to this email. The API is specified here:
> The review request for this specification is logged here:
> *** Action to Take ***
> This CfC is now open for objection, comment, as well as statements of support via email. Silence will be interpreted as support, though messages of support are certainly welcome.
> If you object to this proposed action, or have comments concerning this proposal, please respond by replying on list to this message no later than 23:59 (Midnight) Boston Time, Wednesday 28 February.
> NOTE: This Call for Consensus is being conducted in accordance with the APA Decision Policy published at:
> -------------------------------------------------------------------------------
> Janina Sajka (she/her/hers)
> Accessibility Consultant
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures
> Linux Foundation Fellow

> # Accessibility Considerations
> DeviceOrientation events provide opportunities for novel forms of input,
> which can open up novel interactions for users. In order to ensure that as
> many people as possible will be able to interact with the experiences you
> build, please consider the following.
> * It's important for alternative means of providing 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 user needs that can arise, which would likely be managed by
> the UA, or underlying Operating System. However, it can be helpful to bear
> these considerations in mind, as they represent ways that your content or
> app may be used.
> * It's important that the user is able to turn off the use of gesture or
> motion-based input - for example: whilst the shake-to-undo feature can
> provide a natural and thoughtful interaction for some, for people with
> tremors, it may present a barrier. This could be managed 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
> elements 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.


Janina Sajka (she/her/hers)
Accessibility Consultant

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures

Linux Foundation Fellow

Received on Monday, 11 March 2024 17:25:50 UTC