Accessibility Checklist

[anssiko]

This issue is a record of the Devices and Sensors Working Group's response to the Accessibility Checklist for the DeviceOrientation Event Specification.

DeviceOrientation Event Specification: Accessibility Considerations

The specification does not have an Accessibility Considerations section. The WG welcomes contributions and suggestions from the APA WG participants for content to such a section, perhaps informed by input provided in the following section.

Accessibility Checklist

The Accessibility Checklist document is structured into the following sections, with top-level conditions reproduced here to facilitate WG review. Those with a checkmark are considered relevant to this specification and will be discussed in more detail in the sections that follow.

• If technology allows visual rendering of content
• If technology provides author control over color
• If technology provides features to accept user input
• If technology provides user interaction features
• If technology defines document semantics
• If technology provides time-based visual media
• If technology provides audio
• If technology allows time limits
• If technology allows text content
• If technology creates objects that don't have an inherent text representation
• If technology provides content fallback mechanisms, whether text or other formats
• If technology provides visual graphics
• If technology provides internationalization support
• If technology defines accessible alternative features
• If technology provides content directly for end-users
• If technology defines an API
• If technology defines a transmission protocol

If technology provides features to accept user input

Using this API, changes in physical orientation and movement of the hosting device trigger events that can be read by a script on the web page and used as user input to, for example, control a game, implement gesture recognition, orient a mapping application's map with reality, or simply scroll the content of the page when the device is tilted. See the use cases section for details.

The hosting device is a hardware-agnostic device type the user interacts with, commonly a smart device, tablet or a laptop. Notably, the "hosting" part refers to the primary computing device and not to peripherals such as keyboard or pointing device connected to the hosting device. Not all hosting devices have sensors that are able to sense the physical orientation and movement of the hosting device and as such web authors are expected to provide alternative input methods as fallback and not rely on this API alone for the core functionality.

The information delivered via events is read only. It is not possible to set the state of these values programmatically from script. However, accessibility tools could in their implementation provide more abstract events (e.g. "turn 90 degrees") by emulating device sensors similarly to browser developer tools. This could help provide a more accessible experience if the user has motor impairment, or her device does not support more fine-grained orientation or motion controls, or for any other reason.

If technology defines an API

This API does not generate any user interface. However, the API provides means for an implementation to request permission from the user to use this API. Depending on an implementation this may surface a permission prompt or other UI element to the user. These standard UI elements for interacting with permissions are expected to be accessible to accessibility tools.

[anssiko]

APA WG proposal for accessibility considerations w3c/a11y-request#71 (comment)

[anssiko]

Closed as completed per w3c/a11y-request#71 (comment)

Thank you again APA WG for your review and contributions.