Accessibility Checklist

[w3cbot]

This is a tracker issue. Only discuss things here if they are a11y group internal meta-discussions about the issue. Contribute to the actual discussion at the following link:

§ w3c/deviceorientation#131

[niklasegger]

TLDR: API/Feature is opt-in which mitigates some concerns, but an accessibility section is still important, as it affects people with motor impairments. Could use WCAG 2.5.1 and WCAG 2.5.2 as inspiration for that.

Longer version:
As far as I understand the permission policy correctly, the API requires the relevant powerful features to be activated by the user. Which in turn mitigates some concerns as it is opt-in.

Nevertheless I think an accessibility section is essential, as this API/feature could lead to challenges and risks for people with motor impairments. As the physical device must be moved/tilted to use it.

In certain scenarios, these features can of course be essential, for example in a game. For functionalities that are not necessarily dependent on this API, such as the use case example with clearing the web form, I think that the WCAG 2.5.1 Pointer Gestures and WCAG 2.5.2 Pointer Cancellation criteria can be used as a guide. In other words, there must be an accessible alternative and maybe it should also be possible to undo these inputs.

[matatk]

Thank you @niklasegger; this is great feedback!

I agree with your feedback, and it chimes with the group discussion - you're right that the WCAG SCs provide inspiration for a solution. I think the WCAG SCs are very specific to their input devices, so would be out of scope here (but a good inspiration, as you said.)

Also relevant to the discussion: specific minutes from APA teleconference on 2024-01-31

Summarising both @niklasegger's comments, and the minutes, we will be asking for an accessibility considerations section (and will offer to help draft it). Here are the various things that we should point out to the developers who are building things with the spec:

• It's important for alternative means of providing the input to be available (this is inspired by WCAG 2.5.1 Pointer Gestures), e.g.

  • For games, supporting a game controller (or keyboard/mouse input).

  • For web apps, providing UI, such as a button, menu command, and/or keyboard shortcut, to perform the feature.

• It's important that users can undo any accidental input - particularly important for people with tremors. (This is inspired by WCAG 2.5.2 Pointer Cancellation.)

There are two further things that are out of scope of things built with the spec, but may be most helpful for developers to understand the context:

• It's also important that the user would be able to turn off the use of this API - e.g. for users with tremors. This could be done by declining permission, or changing a browser or OS setting.

• It's also important that the device's orientation can be locked (per @JaninaSajka) - 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 in the layout, and having the layout shift would break their ability to navigate. Again, this would most likely be at OS level.

Thanks for the input so far. I will make the request to the DAS WG - but any additional feedback is welcome on this thread.

[matatk]

I posted some feedback on the HR spec review request thread (not the accessibility checklist issue, linked from this thread - because the group requested a review).