Proposed Guideline 2.6

2.6 [Proposed New MOBILE Success Criteria] Device manipulation: When device manipulation gestures are provided, touch operable alternative control options are available. (Level AA)

Proposed new Success Criteria on Device Manipulation

2.6.1 [initial proposal] Device manipulation: When device manipulation gestures are provided, a mechanism is available to operate these functions via touch, except where the underlying function requires input that depends on the path or pressure of the user's movement and not just the endpoints or touch location (Level AA)

Note: see also separate keyboard requirements in 2.1.1

2.6.1 [Revised proposal 2016-06-02] Device manipulation: When device manipulation gestures are provided, a mechanism is available to operate these functions via touch, except where the underlying function requires input that cannot be provided through the touch interface, e.g. step count data, barometric pressure. (Level AA)

Use cases

Shake to undo. A user with a tablet attached to a wheelchair needs a way to undo that does not involve shaking.
(exception) A step counting app or GPS app would not need an alternative input because this data does not come directly from the user, it is integral to the device.

2.6.1.[Proposed text for Understanding] Intent of this Success Criterion

The following needs a re-write, it is not accurate to the final discussion:

While device operating system is responsible for providing alternatives for using the device buttons and gestures (e.g. shaking, holding, proximity, touch, voice, walking, looking at, angle of holding, etc.), when the content makes use of these gestures in a customized manner not recognized by the operating system, then touch or keyboard alternatives are provided. For example, a shaking motion to undo or cancel may be unavailable to a person whose mobile device is secured to a wheelchair.

This also means Functions that rely on pressure sensitivity can be operated without touch sensitivity.

We expect that at some point much of this alternative functionality will be provided by platforms and user agents, so the term "a mechanism is available" allows for authors to depend on user agents for this requirement if and when these features are available.

[Proposed change to "device manipulation"]

Device manipulation

Moving or controlling the device with hands, body or machine. Device manipulation includes other methods of controlling input to the mobile device outside of using the touch screen. This includes: pressing a physical button on the device, shaking, holding, proximity, touch, walking, angle of holding, input via the accelerometer, <add>force of touch</add> etc. Gestures to the camera and voice input to the microphone are addressed separately.

[Proposed change to "device manipulation" 2016-06-02]

Device manipulation

Moving or controlling the device with hands, body or machine. Device manipulation includes other methods of controlling input to the mobile device outside of using the touch screen. This includes: pressing a physical button on the device, shaking, holding, proximity, walking, angle of holding, input via the accelerometer. Gestures to the camera and voice input to the microphone are addressed separately.

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)

Techniques and Failures for Success Criterion 2.4.1

...
...
...

Techniques

The main technique is <aria-live>, and also all of the aria-describedby techniques on the activating button in the case of advance notification.

Comments

xxxx

Jonathan Comment

I agree with David -- SC 2.1.1 already requires keyboard access and we should look to the language in SC 2.1.1. "Without requiring specific path, pressure, or movement for input, except where the underlying function requires input that depends on the path or pressure of the user's movement and not just the endpoints or touch location." end Jonathan's comment

xxxx

xxx

Jxxxxx

xxxxx

xxxx

-xxx

boneyard

xxx