search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.09k stars 242 forks source link

2.5.4 understanding - suggestion to remove the "user gestures towards device" angle #1464

Open patrickhlauke opened 3 years ago

patrickhlauke commented 3 years ago

Currently, https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html talks of situations where a user "gestures towards the device".

This aspect is handwaved in the understanding, and isn't sufficiently explained ... what is detecting the actual gesturing? is the webpage taking a feed from the camera? is it using near-field sensors or similar? particularly the camera aspect seems to open this up to lots of potential misinterpretation (see https://github.com/w3c/wcag/issues/1120 / https://github.com/w3c/wcag/issues/1404). additionally, there really don't seem to be many websites/apps doing this sort of thing (eye tracking? movement tracking?)

intentional gesturing by the user

A user can gesture towards the device to navigate content. Controls are also available to navigate.

As the topic is a much larger one (i.e. offering an alternative, which is covered conceptually anyway by at least 2.1.1 Keyboard?), and related but not directly about "motion" per se, I'd suggest removing this aspect from the understanding document/intent of the SC. instead, focus the SC on just movement of the device itself.

patrickhlauke commented 3 years ago

i.e. make the focus, essentially, that the user may not be able to move the device, or may not want to trigger actions as a result of moving the device. and not the fact that user may not be able to move in front of the device's camera.

patrickhlauke commented 3 years ago

Just to get a sense here ... is it worth me trying to do a proposed PR for this? Is there some rough agreement that yes, this is a problem that needs clearing up?

patrickhlauke commented 3 years ago

... ok, i'll take the silence here as a resounding "sure patrick, make a PR to add to your pile ... https://github.com/w3c/wcag/pulls/patrickhlauke ..."

i'll craft something for discussion

detlevhfischer commented 3 years ago

@patrickhlauke

This aspect is handwaved in the understanding, and isn't sufficiently explained ... what is detecting the actual gesturing? is the webpage taking a feed from the camera? is it using near-field sensors or similar?

I am not sure why we should remove this aspect. The SC text clearly covers "Functionality that can be operated by device motion or user motion". WCAG has (not always successfully) tried to be techology-neutral, so the point that it is not spelled out in which way a gesture is captured (camera, other sensors) is not a weakness in my view. If some author would implement a navigation that only works by gesturing would it not be good to require alternative ways for that function? The other case I know of (a 360 degrees surround view where you can access controls placed on that view only by a circular movement of the device) would also be covered by the user motion aspect.

It get's tricky with the cases discussed elsewhere #1404 when the device needs to be moved in a certain position so the camera can capture some input (such as a QR code). But I think this can be separated from intentional gesturing (e.g. for flipping pages) or moving (surround view) to trigger functionality.

patrickhlauke commented 3 years ago

I'd say it would be easier to define two separate SCs (one for device motion, one for motion of the user that gets detected) as it would allow for both SCs to be clearer and more focused. because otherwise, we end up exactly with then having to write out weird exceptions for things that don't quite fall in either camp, or both camps ("but the user has to move both the device, AND move themselves, so to position the camera correctly").

patrickhlauke commented 3 years ago

and it could open up a section/path for other aspects that are currently not covered, like sound/voice control activation (which would then be much closer to video camera type control). but i guess it's all a bit too late now...

detlevhfischer commented 3 years ago

Well, the thing is there is now ONE SC for both aspects. Also, it is not the only SC where you discover weird edge cases that need disambiguation and where people may differ if and how they apply? I don't think that problem would simply go away if we split into device motion / user motion. Since there is a lot of work in completing 2.2 I suggest this is not a priority issue? In the meantime, we could add to the understanding doc to clarify edge cases.

patrickhlauke commented 3 years ago

well, nothing is a priority with 2.2 in mind. we're left with lots of ambiguity and half-cooked aspects in 2.1 (and even 2.0) but i guess we'll just carry on moving forward then...